Reach integration with Pixhawk Issues

rrr6399 · December 5, 2016, 9:51pm

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

ardupilot/ardupilot/blob/master/libraries/AP_GPS/AP_GPS.cpp#L508


      
          
          
bool AP_GPS::vertical_accuracy(uint8_t instance, float &vacc) const
          {
              if (state[instance].have_vertical_accuracy) {
                  vacc = state[instance].vertical_accuracy;
                  return true;
              }
              return false;
          }
          
          

          
/**
             convert GPS week and milliseconds to unix epoch in milliseconds
           */
          uint64_t AP_GPS::istate_time_to_epoch_ms(uint16_t gps_week, uint32_t gps_ms)
          {
              uint64_t fix_time_ms = UNIX_OFFSET_MSEC + gps_week * AP_MSEC_PER_WEEK + gps_ms;
              return fix_time_ms;
          }
          
          
/**

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!

igor.vereninov · December 6, 2016, 8:42am

Hi Rob,

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
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.

rrr6399 · December 6, 2016, 3:36pm

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

rrr6399 · December 12, 2016, 5:33am

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.

rrr6399 · December 13, 2016, 5:31am

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.)

rrr6399 · December 22, 2016, 8:17pm

I submitted this bug report to the Ardupilot project:

github.com/ArduPilot/ardupilot

GPS_Type inconsistent with MAVLINK GPS_FIX_TYPE regarding RTK and does not differentiate between RTK FLOAT and RTK FIX

opened 08:11PM - 22 Dec 16 UTC

closed 09:45PM - 25 Jan 17 UTC

rrr6399

Enhancement GPS

#### Issue details I've been working with the Emlid Reach recently and noticed …that when it gets a RTK FLOAT FIX, its being reported as a DGPS fix instead. It appears that the AP_GPS.h code does not differentiate between RTK FLOAT and RTK FIXED: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_GPS/AP_GPS.h#L76 ``` enum GPS_Status { NO_GPS = 0, ///< No GPS connected/detected NO_FIX = 1, ///< Receiving valid GPS messages but no lock GPS_OK_FIX_2D = 2, ///< Receiving valid messages and 2D lock GPS_OK_FIX_3D = 3, ///< Receiving valid messages and 3D lock GPS_OK_FIX_3D_DGPS = 4, ///< Receiving valid messages and 3D lock with differential improvements GPS_OK_FIX_3D_RTK = 5, ///< Receiving valid messages and 3D lock, with relative-positioning improvements }; ``` Here's the MAVLINK definitions: ``` <enum name="GPS_FIX_TYPE"> <description>Type of GPS fix</description> <entry value="0" name="GPS_FIX_TYPE_NO_GPS"> <description>No GPS connected</description> </entry> <entry value="1" name="GPS_FIX_TYPE_NO_FIX"> <description>No position information, GPS is connected</description> </entry> <entry value="2" name="GPS_FIX_TYPE_2D_FIX"> <description>2D position</description> </entry> <entry value="3" name="GPS_FIX_TYPE_3D_FIX"> <description>3D position</description> </entry> <entry value="4" name="GPS_FIX_TYPE_DGPS"> <description>DGPS/SBAS aided 3D position</description> </entry> <entry value="5" name="GPS_FIX_TYPE_RTK_FLOAT"> <description>RTK float, 3D position</description> </entry> <entry value="6" name="GPS_FIX_TYPE_RTK_FIXED"> <description>RTK Fixed, 3D position</description> </entry> <entry value="7" name="GPS_FIX_TYPE_STATIC"> <description>Static fixed, typically used for base stations</description> </entry> </enum> ``` The reason it matters is that the logic used to pick the best GPS is based on the GPS status value. The RTK Float solution will not be used compared to the DGPS solution of the platform's primary GPS (Neo M7) even though it is more accurate even if it has less satellites. https://github.com/ardupilot/ardupilot/blob/master/libraries/AP_GPS/AP_GPS.cpp#L516 Please add the RTK FIXED status and differentiate between DGPS, RTK FLOAT and RTK FIX so that the accurate fix type will be reported to the user and that the GPS selection logic will be improved. #### Version 3.4 and later #### Platform [x ] All [ ] AntennaTracker [ ] Copter [ ] Plane [ ] Rover #### Hardware type Pixhawk and Emlid Reachh

coby · February 6, 2017, 4:08pm

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.

github.com/ArduPilot/ardupilot

Rebased M8P

ArduPilot:master ← WickedShell:wickedshell/rebase-ublox-pvt

opened 02:00AM - 05 Jan 17 UTC

WickedShell

+244 -65

This is a rebased updated version of #4151 it fixes up the reported fix types to… the ground station. Due to a series of unfortuante events I haven't been able to validate a lot of this yet, although it looks good on paper. Currently flagged as needs rework, as the first time we decide we want a PVT message instead of using the normal collection we shouldn't report those fields as configured until they have been disabled. Requires flight testing on both a normal non RTK as well as a RTK system. The optimal time delay when using PVT might be slightly different on a M8 as well, although I'd actually be surprised if it was significant. GCS changes are flagged as aircraft will now be reporting fix types >4 which was not something they had to manage before.

coby · February 6, 2017, 4:14pm

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

github.com/ArduPilot/ardupilot

Add EKF support for multiple GPS receivers

ArduPilot:master ← priseborough:pr-gpsBlending

opened 04:02AM - 30 Jan 17 UTC

priseborough

+723 -79

**Problem** The existing logic used to switch between GPS receivers can cause… large unpredictable jumps in EKF position if dual GPs receivers are fitted and GPS_AUTO_SWITCH is set to 1. **Solution** Extend the GPS_AUTO_SWITCH to type 2 which is a soft switching/blending method using a weighted average of physical receivers to create a third 'virtual' GPS where: 1) The method is scaleable to more than 2 GPS receivers 2) A 'blended' location and velocity is calculated using a weighted average of the two receivers 3) Weights are calculated using the ratio of reported error variances. 4) A filtered location offset correction is calculated for each receiver relative to the 'blended' location and used to correct the output from each receiver. 5) If less than 2 GPS units are available the first GPS instance detected will be used. 6) If there is not enough error reporting to support calculation of the blending weights, the first receiver with the equal highest solution status value will be used . This can happen if one of the two receivers does not provide a position or speed accuracy. The existing hard switch logic has been left untouched and is selected with GPS_AUTO_SWITCH = 1 the same as before. Logging has been updated to to log the blended GPS instance if it is being calculated. **Status** This is a draft for comment. it has had limited flight and bench testing. **TODO** Improve the legacy hard switch logic to use solution status and reported accuracy (if available) rather than number of satellites. Using the number of satellites doesn't work as a metric where there are mixed receiver models (eg GPS+GLONASS and GPS only). Bench testing of various GPS failure modes - signal fade, loss of physical connection.

wkf94025 · September 1, 2017, 3:58pm

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

igor.vereninov · September 4, 2017, 1:55pm

Hi Kelly,

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

wkf94025 · September 4, 2017, 2:32pm

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

Amilcar_Lucas · September 4, 2017, 5:14pm

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

wkf94025 · September 4, 2017, 6:01pm

If you mean there are no guarantees in DIY RC, I learned that thousands of dollars ago, dozens of crashes ago. 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

rrr6399 · September 4, 2017, 8:42pm

@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.

Amilcar_Lucas · September 4, 2017, 11:08pm

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

rrr6399 · October 23, 2017, 3:24am

Did your Ardupilot patches ever get merged?

Amilcar_Lucas · October 23, 2017, 9:45am

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 ( WickedShell · GitHub ) on the big one.

The pull request is here:

rrr6399 · October 23, 2017, 1:55pm

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.

Amilcar_Lucas · November 1, 2017, 2:33pm

Ardupilot patches are now merged in master.

rrr6399 · November 1, 2017, 2:56pm

Hooray! Thanks for your tenacity!