Reach + Pixhawk integration flight tests

Hi Egor,

Thanks very much, will update :slight_smile:

Did some flying with the system now - able to get consistent float on the ground and in the the air, fix intermittent. Precision RTL works fine. However I was experiencing issues once I increased the range - flying out to about 300m away on an auto grid (8m/s) I lost float and had a few interesting moments as the system switched back and forth between the two GPS single solutions (other unit is a cheap and cheerful Neo M8N ebay purchase). Unsure whether the issue is the 3DR radio link, poor gps signal from one or the other of the stations or something else. I did notice that GPS2 was reporting an HDOP around 1 even when Reachview was showing float, whereas the M8N usually reports around 0.6-0.8, not sure how the APM code handles GPS switching but a couple of times the machine seemed to be jumping back and forth between 2 GPS solutions about 4-5m apart. Reach was only in single at that point I believe.

Very happy with results using RTKpost to determine an accurate base station position, I was able to obtain a +/- 5mm solution using the OSNet historic rinex data from a station just over 10km away.

I did also have a few range issues with my taranis - I’d like to disable the wifi on the rover unit to eliminate it as a possible source of interference, I assume if I disable the wifi through reachview it will switch back on if I reboot the Reach?

It would also be really good to have some way of checking the quality of the rover solution through the mavlink connection if possible at some point…

anyway, great work so far, and really good to see updates coming through so quickly. Hope to narrow down the issues I am having with RTK navigation with a bit more flying time, but any suggestions welcome - it would be very interesting to have a few more details of your test setup (antenna positions, ground planes, etc) if possible?





There is an ongoing work on improving the handling of multiple sensors in the APM, maybe it will be ready for the next release.

Could you please try the dynamics option we have added in version 0.3.1? It helps to mitigate the jumps that may occur when bad conditions happen and improve the smoothness of the track in general.

You are correct about the WiFi, it will turn back on after reboot.

On our testing copter we have an antenna placed on the ~200mm ground plane located on a stand with height of ~300mm. Base station antenna is usually located on a similar ground plane on a 2m tripod.

1 Like

You can configure Mission Planner to show custom parameters on the dashboard. Reach’s fix status will is stored in gpsstatus2. 3 - single, 4 - float, 5 - fix.

1 Like

Thanks very much, will give the new mode a try. 70mmx70mm copper laminated ground plane did not give enough singal, have replaced with a 200mm disc of aluminium, should hopefully help as well.

I have been using the gps2 status to monitor the quality of the solution, but it would be good to see the sat signal strengths to have a better idea of the quality of float solution.

thanks very much for the great support.

So had some much better behaviour today - new ground plane (200mm aluminium disc) on rover helped a lot, tripod for GCS antenna/ground plane not so great, so will make another 200mm disc for the base.

No sure whether it was the new dynamics option or the improved signal on the rover but there was a dramatic improvement in flight performance, very stable and performed numerous RTL precise landings, also full auto grid for a map - signal dropped out enough to cause a few GPS switches, which were handled well. Will try and improve the quality of the radio link and base ground plane next.

Unfortunately there were no reference observations in the logs from today’s flying so cannot post process to see how performance was - any idea why they might be missing?

Is there a mavlink status message which indicates which gps is in use as primary system at a given moment?



1 Like

Hey @Charlie_Robinson

How have your recent flights been with the Reach integration? Hints and tips? Etc. I’ll be starting up the same path in a week or so.

Austin M

Hi there,

I haven’t had that much time to work on the use of the Reach for navigation. I got the system up and running, and can demonstrate reasonable precision RTL and so on, but I have a number of slight issues with the installation and setup which at the moment make using it for auto missions less than ideal. You can watch a video of 3 RTL and landings with the RTK system in use, but I was only getting float rather than fix solution. Still a lot better than a regular GPS though.

Issues I will have to work through to get the system reliable enough to be useful for navigation in auto missions:

  1. Ensuring the perfomance of the primary nav GPS - at the moment, I think due to the size and position of the Reach ground plane relative to the generic ebay M8N unit, I am getting degraded performance from this unit. I think the M8N is getting confused by multipath signals from the ground plane possibly. raising it up to the height of the ground plane ought to help.

  2. Improving the quality of the Sik radio link - I am certainly not getting enough range from the connection to provide solid float/fix solutions throughout a 15-20 minute mapping mission. Switching in and out of float, and switching between GPS systems mid mission can be somewhat alarming, and leads to less than ideal coverage from the images collected.

  3. Improving the signal strength and SNR of the Reach GPS signal. I’m not sure whether it is my less than ideal ground planes, insufficient view of sky, RF interference from the copter power systems or some other issue. Either way, in real time mode I struggle to get locked on to enough sats for a fix. Often the base and rover units will have 4 or 5 sats in the green, but they are not always the same ones. Numerous possibilities here, but I think improving the ground plane ought to help. So far I have tried:

70mmx80mm thin plastic with copper foil tape laminating both sides - Better than no ground plane, but not by much.

approx 200mm diamter 1mm think aluminium discs - Cut by hand so less than perfect circles, and slightly different sizes, so the tuning frequencies and so on may be slightly different? Currently using one on the rover and one on the ground station, best results so far with them. Surprisingly little difference in signal between the one mounted 4cm from the PDB and directly above the FC and associated electronics and the one mounted on a tripod well away from sources of RF interference.

100mm diameter aluminium disc - seemed to work OK on the ground station but was a few dB down on the 200mm disc when used on the rover. Made this after seeing the Tallysman recomendation on another thread to not exceed 100mm or so. Was hoping this would work on the rover as not so much of an issue for the other GPS.

In principle the system works well, but I would like to get the above issues resolved - I’m aware that my current setup is less than ideal, should be starting a new build soon that will be designed around the use of the Reach, but need a bit more data first.

The basic APM setup is working, but there are a lot of parameters for GPS systems which I think will need to be retuned to make optimal use of the precision of the system.

Finally I’m not sure that having two entirely different GPS systems on baord is a good idea. The M8N in particular often reports a very low HDOP (0.6) and 17-18 satellites, but the Reach unit is clearly giving a more solid solution, even in single mode. I’m not sure how the code handles switching between units under those circumstances, but I think this could be the source of some of the strange behaviour I have seen.

Using the system in single mode just for logging position for mapping and post processing the logs to use for geotagging works very well though!

Be very interested in other user reports and descriptions of their setups…couple of pictures of things as they currently are below.


quick update, I have moved my primary GPS to a stand, and switched from the alumimium ground plaes to a pair of CDs laminated with copper tape - much lighter, and much better performance. I think possibly the fact that the ground planes are much more similar than the previous sets may be helping. With the aluminium ones I often felt when using RTK navigation that the 2 Reach units were getting strong signal on different sats, which resulted in low rates of fix/float. Now seem to be getting much stronger signal and much better correlation of different satellite signal strengths between the units, also possibly better GLONAS reception…either way, a really noticeable performance boost. Tip o’ the hat to @TB_RTK and the poor man’s solution :wink:

1 Like

Haha, nice one :heart_eyes:

1 Like

@Charlie_Robinson Very nice! Can you share some of the RINEX logs from your flights?

1 Like

Yep, no problem - I have been trying to extend the baseline a bit deriving a base station position using a static reach module and corrections from another OSNet station, this time 14km away. Then using the logs from the static reach to process corrections from the unit in the air.

Watching the reachview signal strength I was getting 6-8 satellites in the green on the static module, and with over 2 1/2 hours of logs was hoping to get a really solid fix. This is where I wish there was some better documentation on the RTKPost settings - I got an ok result but I’m sure it could be better.

What I did find puzzling was the low ratio of fix:float when I ran the rover logs through RTKpost using the static reach logs as the base (coordinates derived from the OSnet observations). The best I was able to achieve was about a 20:80 split - I would expect to be able to get a really solid fix with such a short baseline, and with what seems to be good signal.

Did try some RTK navigation on the same day but had similar problems - seemed to be plenty of signal strength but no fix, only float, and lots of dropouts in the corrections. I have not got to the bottom of that but I am assuming the 3DR radio is the weak link here. Will have a bit of time to experiment further with real time corrections later in the week.

Still climbing the steep part of the learning curve with the system :slight_smile:

link to logs here:

Included is the log from the static unit, the log from the flying unit, the OSNet 16o file and the IGS clk and sp3 rapid products. Very grateful for any pointers :slight_smile:

1 Like


I have very limited experience with the Reach modules but I tested one module linked with the MNCORS (Minnesota CORS correction system) and found that a bigger antenna made a big difference.

I tested a TW2405 and the Reach’s Kit antenna and had a continuous fix for 6 hours using a TW2405 antenna even though the number of green satellites was not much different. I did notice though that I did get more satellites in the green that were GPS satellites. Using the Kit antenna in the same location on the ground I had only a few short occasions that I had a fix while trying for four days. I used the same large ground plane with both antennas. My location was 25 meters from a very large metal building which should have caused some reception problems.

I hope to get the Reach working with a mulicopter flight controller that’s similar to the Pixhawk.

I have a number of RFD 900mhz radio that I’m testing now and I’m finding that they are more consistent than the 3Dr radios but they still slow down their data rate as you increase the distance between them. I’m currently testing the RFD 900 micro in the copter and the RFD 900 standard radio connected to the ground station.

It will be a while till I have the Reach connected to the FC.


Hi Larry,

thanks - I’ve looked into other antennas but not been able to narrow down the choice much. I’m keeping an eye on the forums, hopefully a consensus on the options will emerge in time :slight_smile:


I know. I’m thinking that the TW3710 will be a good choice if we get the ability to use the Galileo satellites soon.


@Charlie_Robinson you did a really great job at integration!

I have processed the base against OSnet files and got its position. I think that it requires so much time because RINEX is with 30 seconds interval. I then processed your copter logs and they are almost perfect!



If you had a camera with hotshoe connected to Reach you could have geotagged the pictures with great accuracy.

@igor.vereninov - that’s a much better solution that I was able to get from RTKpost - would you mind sharing the settings you used for the processing? I’m still in the very very early stages of working out what some (most!) of the options do…

I do have the KAP logs for the flight, should have an accurate geolocation file for all the images once I can get the processing correct. Hotshoe camera and integration is next on the list though…

1 Like

My setting are

  • Kinematic
  • Combined Filter
  • Elevation mask 5
  • Rec Dynamics ON
  • Glonass AR ON
  • GPS AR Fix and Hold
  • Time start 14:03 to crop bad data in the beginning
  • Base position Lat/Lon/Height 51.012279530 -0.783315760 138.8215

My bad, I have made a mistake when processing the static files and used the averaged position for the OSNET base. Should have used RINEX Head position.

I will not post the solution because of the mistake, but you should be able to follow the same steps just fine.

Would you mind if I use data from this flight to create a small tutorial?

1 Like

No problem, help yourself :slight_smile:

1 Like

This is the kind of deviation you get when you set base position as average instead of exact position from the RINEX header.


@Charlie_Robinson The tutorial is now available in the docs and I have sent you the resulting pos files in an email.

1 Like