Detailed problem description. How does observed behavior differ from the expected one?
Your step by step actions.
Picture of the setup and connection scheme.
Specify the exact make and model of the hardware you are integrating.
I am putting together an autonomous boat using ArduRover. I am using a Pixhawk 2.4.8 as the flight controller. The online docs recommend using your Reach as the secondary GPS. I find this surprising, using a rather expensive Reach as a secondary unit and (probably) much cheaper gps as the primary! What’s the reasoning behind this? I plan on using a second Reach to send RTK corrections to the boat.
Can I use onboard Reach as my primary GPS without any secondary? If so, how does this impact installation? Do I still need to connect the Reach to the pixhawk’s serial port?
The ardurover FW provides more information over mavlink telemetry on the RTK GPS status of the second unit than it does of the first.
Besides that It can either blend the two or switch between them, so the first unit is not more important than the second unit.
But yes, you can save money by removing the cheaper unit. Just connect reach to the serial 3 port (GPS).
If you do not connect reach to the serial port… how do you expect it to work? your question is strange. Please reformulate.
To clarify the last part of my question. If I only use the Reach (as the primary) should I still connect to Serial 4/5 or should I use the port labelled GPS (which I now guess is also a serial port)?
If I did add a cheaper (UBlox ?) GPS as the primary and I blend the two, how does the software decide which is the more accurate? The Reach has RTK corrections from the base station so it should be the more accurate solution (or I want my money back! )
Right now, the Reach will report NSATS=0 and DOP=0 if it is not receiving measurements from the base. This means that it will fail GPS prearm checks described here: http://ardupilot.org/copter/docs/parameters.html#ek2-gps-check-gps-preflight-check
if it isn’t being used in RTK mode or if the base station measurements stop for whatever reason.
I imagine there are GPS FS checks during flight as well that rely on NSATS and DOP being reasonable values (not zero). I haven’t verified this yet though.
If the Reach would report the correct value for NSATS and DOP for 3D Fixes (non-RTK), I would have more confidence that it could be used as the primary GPS.
Another issue is that the Reach’s compass isn’t exposed so you’ll have to provide an external compass or use the compass from the non-Reach secondary GPS.
@emlid, @egor.fedorov, @dmitriy.ershov , @igorvereninov Are there any near term plans to update the ERB driver to send the nsats and DOP values even when the GPS is not receiving measurements from the base?
We have the issue added to our tracker. I can’t give an exact timeline, but I’ll give this issue a push and it will be included into one of the dev updates.
@egor.fedorov, I tried out the latest beta version of the Reach firmware and I still see the behavior where nsats=0 and DOP=0 when there are no base measurements being sent to the rover. Do you have a target date for getting that fixed? This bug prevents people from using the Reach as a primary GPS on the Pixhawk.
Last weekend I was trying to find the range from a pair HobbyKing SIK radio 433MHz with Immersion RC antennas and using a Reach as a second GPS. Another Reach is the base connected via wifi to the laptop running Mission Planner. The mission is a straight 700m run, turn right for 30m and return. During the mission I never lost the telemetry signal, but in the last part the drone tried to reach home about 100m behind the take-off point.
Analyzing the logs, I found that about 500m the GPS Injection stopped and the first GPS, a M8N, assumed, a normal behavior. But in the return path, about 400m from home, the GPS injection resumed and the reach went crazy, jumped for the position that the injection stopped, after a few seconds returned to the drone position, but with a wrong coordinates, like it had lost a 100m.
I had to take command to return the drone, and after landing I stopped the drone, started it again and made a short flight, but the Reach insists that the home point is a 100m behind.
After a power off and on the things returned to normal, but I had lost confidence in using a Reach in the drone unless you have a very good radio.
@ginodouglas I imagine the Reach only had a Floating Fix when the base measurements resumed. Which version of Arducopter are you using? Ideally, the Pixhawk would only switch to the secondary GPS if the actual accuracy was better than the primary GPS. The original logic was pretty simple and just used GPS status and number of satellites. A lot of work has been done in the 3.6 (beta) releases of Arducopter related to picking the best GPS and blending the two. (They recommended using the same GPS for primary and secondary though.) I’ll take a look at the 3.6 logic to see if they are looking at the predicted accuracy of the RTK fix. The safer approach may be to only use a Fixed Fix since the solution is guaranteed to be accurate.
Rob, I am using 3.5.7, the last stable version, and the overall configuration is the one recommended in the Reach docs, meaning I am using best GPS not blending. The first GPS is a cheap, very cheap, M8N that has always few sats then Reach. When the injection stopped Reach went in DGPS mode but continued to be the best GPS. Here is a zip file with dataflash and telemetry logs:
It appears that the ERB problem not sending number of sats and HDOP happens until the correction starts, after that even without it the information is ok.
Gino, it looks like the Reach never had a stable Fixed Fix. Nonetheless, when the measurements resumed, there was a discontinuity in longitude and latitude while it resumed the RTK solution:
I looked at 3.6 and it appears that it still uses nsats and gps status as the metric to decide to switch to the secondary GPS. It’d probably be better to use an accuracy metric sent by the GPS to decide.
)