Ardupilot - Copter shaking and spiraling when using Reach RTK

Reach Module / M+ / M2 Hardware integration
1

We are using a Reach RTK gps as a secondary GPS input to ArduCopter for positioning purposes on an Erle Brain 3.

We plugged in the primary GPS by USB using a ftdi (tested separately and working perfectly) and the Reach by UART.

Ardupilot confirms that it has two GPS, an Ublox one and an ERB one, both with a fix, and we saw on the Reach rover’s web interface that it had a fix before takeoff and during the flight.

The problem is that when using the Reach as a secondary GPS in LOITER mode the copter keeps shaking on all axes (roll, pitch and yaw), and starts moving erratically, in the shape of a spiral.

This problem doesn’t occur when in STABILIZE mode or in LOITER mode using only the primary GPS, but it does occur when using the two GPS at the same time or even using the Reach alone.

We read the entire docs several times and followed it to the letter, and the entire forum once.

Firmware image and ReachView version: v2.5.3-r0
ArduCopter version: 3.4.6

2

I also had issues with this, and described them along with the fixes here:
https://community.emlid.com/t/mission-planner-3dr-radio-failing-how-to

3

Thank you a lot, for this information and your work on the lib !

I am in the process of compiling your version of the RTKLIB at the next to last commit (22ee01a Fix make install paths) of your IAV branch.

If I understood correctly, I need to only compile the rtkrcv by running make in the app/rtkrck/gcc folder, adding a -march=atom to the CFLAGS variable in app/rtkrcv/gcc/makefile for compatibility with the Edison, and then replace the rtkrcv binary on the Edison by the one in ./app/rtkrcv/gcc/rtkrcv, am I right ?

4

I think so … but I’m compiling my stuff on the natively reach. But yes cross-compile should be fine as well.

Edit:
I had to add:
#include <sys/select.h>
to the src\rtklib.h file in order to be able to compile it in cygwin64.

Does it work for you without it ?

5

My main system is a Linux so I did my cross-compiling directly from it and could successfully execute the newly compiled binary on the Edison.

I tested your patches in flight and unfortunately it did not fix anything for me.

I did recompile the rtkrcv binary and replaced the one on the drone’s Edison with it, to have exactly the same behaviour as described above.

I tested various configurations as well:

  • like before, using the two GPS with everything configured as advised in the docs
  • Setting the output protocol of the drone’s Reach to NMEA
  • using the Reach as only and primary GPS with NMEA output

All of these setups led to the same erratic behaviour.

The predominant symptom in each flight was the drone describing large and increasing spirals that lead to a crash.

6

I’ve updated the instructions here.

You will have to recompile ardupilot code as well.

DO NOT USE NMEA, keep it at ERB.

Set up like described here: GPS Blending (aka Dual GPS) — Copter documentation

7

Oh, I wasn’t aware that there were Ardupilot patches to add as well, as it was no mentioned in the topic that you directed me to.

So, your patches on the rtkrcv will not work without the Ardupilot patches ? Or is it because I am using ArduCopter 3.4.6 ?

Or is it the fact that I was using a side 3DR radios link (one on the base via UART, one on the rover via USB) that made it go nuts ?

What are all the steps that one should take to have a working system ?

8

I just did 4 flights today with perfect RTK GPS fix troughout the entire flights. ALL the steps are detailed in the post that I already told you about. To get this fixed faster, complain to Emlid, once they start testing and using these fixes in their official release it will get even better.

But of course: if your copter shakes and spirals with only the normal GPS then your problem has nothing to do with the secondary Emlid reach GPS

9

@deb0ch There is really no need to recompile anything. The spiraling issue should not be related to the Reach integration, as other users would be getting it as well. Maybe there is an issue with the Erle Brain setup?

A flight log could be helpful to diagnose the cause of your issue.

11

With only the normal GPS as primary the LOITER is perfectly smooth. In STABILIZE the flight is perfect as well.

What version of Ardupilot are you guys using ? I am using 3.4.6, in which ERB is supported.

What version do you guys recommend ?

Note that we are using a wifi udp link to transfer telemetry between the drone and the GCS. We could also not setup the base corrections injection with Mission Planner (followed the docs very carefully, Mission Planner was displaying the right things but the ReachRover just wasn’t receving anything), so we are sending the ReachBase corrections using 3DR radios between the two reaches directly.

Here is the log with the spirals, and the crash at the end:

16.BIN (1.9 MB)

12

Arducopter 3.4 can only hard switch between 2 GPSs. If the diffrence in position/altitude between the two GPSs is really big then the ArduCopter code thinks that the copter “jumped” and tries to correct that …

Arducoter 3.5 adds a blending algorithm where the two GPS positions get blendend for a period of 10 seconds. This allows the copter to gradually move the position between one GPS and the other avoiding jumps and instability.

But due to a bug in Emlid this blending algorithm does NOT work, accurracy information is not sent in some cases and the Arducopter GPS blending algorithm relies on that to do the decisions. This has been reported to Emlid a long time ago and I fixed it in a pull request already. That is why I told you to use my code. Is it clear now ?

By using a side channel for RTK injection, you do not loose any functionality that I described. I’ll update the docs now.