A lot of fun, Monsieur Poirier !
1 Like
That’s not sending a position to the GPS to give it a head start. That’s just enabling/disabling the use of SBAS, and forcing a regional system vs automatically determining which regional system to use.
Forcing the SBAS system to a specific region is not going to make it recover from a dead battery faster. The GPS will acquire sats without any SBAS at all. SBAS doesn’t make it aquire sats faster. It enhances the position accuracy of the ones you already have.
Starting up an M8N with a dead battery is what it is. There is no way to cheat it into working faster. The solution to the long start up time is to have a battery on the GPS that isn’t dead. I hate to keep saying this, but with hacked knock-off cut rate GPS units like this one, you get what you pay for quite often.
1 Like
Doesn’t AGPS aid the startup by uploading Almanac Ephmeris (costelation position orbits) at boot time?
That would allow to push the data into the GPS instead of the GPS having to retain it in memory. Is this correct?
1 Like
Retaining almanac somewhere and uploading it to GPS at boot would definitely help some, since its validity is a couple of days, and takes longer to get it from sats. Ephemeris is less important, as it’s valid for a couple of hours only.
But all this stuff, and the work involved is beat by a $2 lithium button cell.
3 Likes
I believe the functionality of U-Blox AssistNow is being cited:
https://www.u-blox.com/en/solution/services/assistnow
AssistNow Autonomous is a best-guess approximation of the constellation modeled from the periodic nature of the satellite orbits and does help a bit with acquisition during cold boot. Does not require any external data, just a config flag on the GPS.
AssistNow Online grabs data from the U-Blox servers based upon what satellites are visible at time of request. I’ve yet to be able to use this in-field, no comment on effectiveness.
AssistNow Offline can supplement Online & Autonomous by downloading differential files that can be cached for a number of days in advance of the download request, with accuracy/effectiveness of the differential files decreasing as the date increases from the point of download. This I have used, and liked.
All of these combined should lead to super fast fixes, especially in tough conditions, and especially when the constellation has changed significantly while the GPS was offline (days between collections, survey sites in vastly different geographic locations, etc.)
All of these services are freely usable for U-Blox cusomters provided a SLA is not needed.
Hi,
Regarding the PreArm: Internal errors (0x400) - had a similar setup - 2 X UAVCAN GPS (mRo Location One).
attaching a log & a tlog - used GPS_AUTO_SWITCH = 2 (Blend)
Seems that the error comes up when the 2nd GPS gets a 3D FIX
Adding some more info:
When testing with one Here2 module and one mRo Location one the PreArm doesn’t come up.
When changing GPS_AUTO_SWITCH = 1 (UseBest) the PreArm doesn’t come up as well.
1 Like
OK, thanks for that. So from a quick look at the logs it seems like both GPSs are UAVCAN GPSs and as you say there is this “Internal Error 0x400” which is for “constrained NaN”. I’ve added this to our Copter-4.0 issues list so we don’t forget about it. I’ll see if I can recreate it with a couple of Here CAN GPSs.
2 Likes
In our setup it could not be recreated with Here CAN GPS. Even with one Here and one LocationOne. Only happened when both GPSs were LocationOne.
Is the “internal error” sticky or is it cleared periodically ?
the only line of code I could find in GPS blending code that uses constrain operation is this:
float min_alpha = constrain_float(_omega_lpf * 0.001f * (float)(state[i].last_gps_time_ms - _last_time_updated[i]), 0.0f, 1.0f);
No clear how it could ever get a NaN parameter …
@VadimZ, @RomanD (I guess you guys work together or just coincidentally have the same issue?)
I had a chat with @pkocmoud from mRo and @tridge and we wonder if perhaps the two CAN GPSs are both using the same NodeID. Apparently they will come from the factory with the same ID so one of them needs to be changed manually.
Changing the NodeID is done using Mission Planner and SLCAN. We’ve got a discussion here and a wiki page on SLCAN here.
By the way, the firmware on these GPSs is apparently AP_Periphs and the upcoming version will support “dynamic node allocation” which will mean manually setting the NodeID won’t be necessary anymore.
One way or the other we shouldn’t have an “Internal Error 0x400” as the way users are warned of this issue so we need some better error handling and wiki documentation.
P.S. the internal errors are recorded in variables that are cleared when the vehicle is rebooted.
EDIT: we think we’ve reproduced an issue with the dynamic node allocation when more than one LocationOne GPS is used.
We’re not able to reproduce the “internal error 0x400” issue sadly. It’s possible (although perhaps it’s wishful thinking) that we’ve somehow resolved the issue between Copter-4.0.0 (which is what @RomanD’s log shows) and Copter-4.0.2 (the version we tested with).
Could you upgrade to Cotper-4.0.2 (stable) and see if the problem is resolved or not? It probably isn’t but testing will reduce the number of possible causes of the issue.
i meet message “internal error 0x400”
could you check the log?
@rmackay9,
We’ll try to check the issue with V4.0.2 and verify if the error still comes up.
Regarding the NodeID - both units are already set to allocate the NodeId dynamically and we’ve double checked that they had different NodeId’s.
1 Like
@rmackay9
regarding you recommendation to use dynamic node allocation: won’t it play havoc with compass calibration ? It seems calibration is indexed by device ID which for CAN device includes node ID. So without consistency guarantees for CAN ID allocation between boots, compass calibration would not be found.
Edit: I see now there’s a mechanism that attempts to re-issue ID based on CPU unique ID. However we’re investigating an occasional “Compass not calibrated” when multiple CAN compass devices are present. So that’s the leading theory so far.
Edit 2: Indeed there is a problem with assigning IDs to CAN compasses. However it is not where I originally thought - the problem also happens with static IDs. On some boots the IDs are switched between the two compass devices: Compass 1 gets the node ID of Compass 2 and vice versa, messing up the calibration.
Edit 3: There is indeed a race condition in CAN compasses initialization, and their ordering is timing-dependent.
Edit 4: https://github.com/ArduPilot/ardupilot/pull/12629 is referring to this problem exactly: “Compass_UAVCAN driver is modified to reorder the detected devices, so that the compass with larger node id is sent for registration first”. Without this fix, multiple CAN compasses can not be used. Hopefully this PR makes it into 4.0 soon.
Thanks for confirming the “internal error 0x400” issue still occurs on. We’re going to come up with a more detailed message that tells us where the “constrain NaN” is coming from so we can figure out how to fix it. I suspect this will take us a few days to come up with but it’s on our to-do list so it won’t be forgotten.
1 Like
Would it make more sense to statically assign a node ID? That way you know which is which?
@smartdave - I know which one is which, the issue seems to be internal on how the AP is handling the allocation (I’ve reported 2 different issues that might be related to the same core issue, not sure though…)
I have multiple CAN gps’s, so if you want me to test anything for you I can.
Just to see if I see it as well