Reach integration with Pixhawk Issues

I had a couple of questions in regards to using the Reach as a secondary GPS on the Pixhawk:

1.) It appears that the logic in the Ardupilot firmware to switch GPSes is based solely on the number of satellites


I’m using a Neo 7M GPS as my primary, which appears to always have more satellites (and lower HDOP) than the Reach so the Reach would never be used for navigation. I’m I understanding the logic correctly? Shouldn’t the logic be using estimated error or at least DOP as a metric instead?

2.) I’ve noticed a few of meters of vertical drift with the base station and the Rover sitting stationary on the ground. The Rover tends to jump to a new altitude and remain fairly steady (<0.5 m or so). Is this expected? What input data or configuration parameters would impact the vertical accuracy?

Thanks!

Hi Rob,

  1. A few lines higher you can see the ArduPilot changes primary instances depending on lock status. If you have a higher lock status (RTK Float or RTK Fix) Pixhawk will use Reach instead of 7M. Satellite based selection logic is only activated if both GPS instanced report same lock status.
    https://github.com/ardupilot/ardupilot/blob/master/libraries/AP_GPS/AP_GPS.cpp#L500

  2. It is hard to tell from the description. Best option would be to check out raw data logs with RTKPLOT and post-processing with RTKPOST.

1 Like

Nice. I didn’t know there was a new GPS status for RTK. That helps a lot!

I noticed that RTK Float has a GPS status of 4 when it should be 5 and RTK Fix has a GPS status of 5 when it should be 6. This will prevent the RTK from being used since the Neo M7 has a GPS status of 4 (DGPS) and usually has more satellites. Also, the Neo M7 seems to have more accurate single fixes than the Reach’s single fix for some reason.

Also, it appears that Reach GPS uses the WGS84 datum reference and the Neo m7 uses the AMSL (WGS84+EGM96) data reference. Is that your understanding? Is there a configuration option for the Reach to use AMSL or would that have to be done on the Pixhawk?

I’m seeing about a 35m difference between the two altitudes and if I chose to let the Arducopter software use the GPS for altitude rather than the barometer, I wonder if it’ll get confused when it picks the current most accurate GPS. (I haven’t looked to see if the code keeps the takeoff altitude for all connected GPS’s to use as a reference.)

I submitted this bug report to the Ardupilot project:

Just trying to close the loop on this for others interested. Looks like this was merged with a few other GNSS driver issues about 12 days ago. Nice job Rob.

1 Like

This is also related and could be a very nice add.

I am setting up a Pixhawk 2.1, Arduplane 2.8, Reach RTK GPS, Sony RX100 with Tuffwing hotshoe cable, and SeagullUAV Map2 for manual and automated triggering of the Sony. Brian at Tuffwing suggested navigating off a non-Reach GPS, which I am happy to do. I just wanted to search the Reach community forum and see if in fact that’s what most Reach-based mapping pilots are doing. Is anyone using the Reach GPS as their sole GPS? Appreciate any guidance on the setup, parameters, etc. If I am going with a non-RTK GPS (MN8, etc.) then why integrate the Reach RTK GPS with the Pixhawk/Arduplane at all? If it’s primary purpose is to give accurate geotagging timestamped with Sony shutter firing, is there any reason to integrate it with Pixhawk? I like the ideal of logging its parameters (HDOP, # sats, lock status, etc.), in the MP logging, and comparing to the MN8 performance, but that’s more of a science project if you will than added value in flight ops. Open to input from others who have blazed this trail ahead of me.

Kelly

Hi Kelly,

You are absolutely right, there is no need to integrate with Pixhawk for picture georeferencing, only with the camera.

Thanks Igor. Is there a plan for the Reach RTK GPS air unit to be the sole GPS unit on an Ardupilot / Pixhawk aircraft, for reliable navigation in addition to its role in precise mapping?

Kelly

You can do that today already. But it is your responsability

If you mean there are no guarantees in DIY RC, I learned that thousands of dollars ago, dozens of crashes ago. :grin: Let me ask the question a different way: I have ordered a $20 M8N GPS + compass off Goodlucksell/eBay, and will use that for navigation. Unless I get a lemon, by all RCG accounts, and by my own experience with ublox-based L1 GPS products, it will work fine for nav of my ArduPlane/Pixhawk2.1 based MyTwinDream aircraft. Will the Reach RTK unit function just as well? Or is it less reliable for basic navigation? Or does using it for navigation get in the way of its precise time-stamping of GPS data for post-processing geotag data? It seems I can run both GPS units side by side, log both, and eventually get data on both, but curious if there are known problems before I venture there. If I don’t need to pack the M8N, it’s just one more device (needing RF-clear space on the aircraft) and one more cable that I can get rid of.

Kelly

1 Like

@Amilcar_Lucas Have your RTKLib and Ardupilot patches been merged yet? Has the issue with DOP not being sent for non RTK fixes been fixed in the production release? If not, the bird won’t arm unless it’s a RTK Float or Fixed Fix.

Of course, the compass is not plumbed either as far as I know so a separate compass will be required for the Pixhawk.

I’ve used the Reach as a secondary GPS for altitude and position reference purposes, but not for navigation yet. It looks like Arducopter 3.5 has much better logic for using the most accurate GPS for navigation although I haven’t tried it yet.

Good point Rob,
Without a compass it won’t work.

My Emlid patches have been merged in 2.7.4.
But my ArduPilot patches are still not merged

Did your Ardupilot patches ever get merged?

No, not yet, most Mavlink patches are merged and some or the Ardupilot changes are also merged, but I’m still waiting for the approval of Michael ( https://github.com/WickedShell ) on the big one.

The pull request is here:

OK. I’ll post a comment. If they want people to contribute patches to Ardupilot project they need to be more pro-active about merging them or rejecting them.

Ardupilot patches are now merged in master.

2 Likes

Hooray! Thanks for your tenacity!