Mission Planner-3DR radio Failing - How To?

On the app looking different - just make sure you’ve updated to the latest version

But ja again - could someone who has it all working maybe just post screen shots of their config for all pages for both rover and base and mission planner GPS inject screen?

Would super helpful in eliminating whatever the 1 random setting I have wrong is!

You will need to tell ardupilot to inject to your GPS, to do so change the GPS_INJECT_TO parameter in mission Planner.
reach has at least four known bugs that mess up integration with ardupilot. I already corrected them, on my public github repository but Emlid has not merged the fixes yet, so reach does not integrate that well with ardupilot:

  • hdop is messed up so dual GPS does not work (although recommended by Emlid)
  • horizontal and vertical accuracy information is also messed up (again affects dual GPS)
  • speed accuracy information is missing
  • Ground course calculation is bogus wrong signal and 90deg offset, (EKF will get confused merging the information with a compass)
  • GPS timestamps are messed up in versions prior to reach 2.5.2

On Monday if I get some time I can post screenshots, but like I said, even when you inject data, it still does not work correctly until those bugs get solved. Apply pressure on Emlid, maybe then they will merge the fixes, and it will start to work like advertised.

@r4space i fixed the app.

@Amilcar_Lucas
So this means that the RTK GPS wont work with Ardupilot as it is.

If dual GPS is not working, can the system work with only the emlid module as primary GPS? How can i inject the base correction then?

Also does this affects the compass operation?

On dual GPS with GPS_AUTO_SWITCH == 1 it gets very confused with the compass and does strange stuff, for me it started oscillating on the yaw axis, whenever switching GPS. It also almost never uses reach because it compares the hdop from the standard GPS with the vdop of reach (bug explained above), and ends up almost only using the standard GPS because vdop its typically bigger than hdop.

With GPS_AUTO_SWITCH == 2 (GPS Blending) then it uses Reach but blends in the other GPS because Reach stops delivering accuracy information as soon as it gets a RTK fix. So when reach is fully locked the autopilot actually thinks that the solution quality degrades and starts giving more weight to the other GPS, again a reach bug.
This method did conceal/diminish the yaw oscillation caused be the ground course calculation bug.

Missing speed accuracy information also makes it harder for the autopilot to blend the two GPSs. It would be nice to see it implemented. The ERB driver in the Ardupilot code already flags it as valid although it is not. But that will stop being a bug as soon as Emlid implements it on the reach side :slight_smile:

When using reach as primary and single GPS source (against Emlid recommendation) should work, but the EKF will get confused by the buggy hdop/vdop and missing accuracy information, and give too much weight to the IMU and too less to the GPS corrections. I must admit I did not try this combination. I only tested the two other ones above.

Try it out, and tell us how it goes :slight_smile:

1 Like

This is crazy, uh would you (or Emlid) like to comment/advise - I’ve already lost a week to fighting with this, how likely is it that I’m actually going to get this to work or do I cut my losses and go looking at a different solution?

Recommendations? Here+ or Piksi?

Welcome to the club. :frowning: How much time do you tink I’ve wasted debuging the issue and correcting the code ?
And waiting for Emlid to react ?

If you want to fix it. try these out :




According to Emlid this is how you compile it:

And this is my struggle to get a one liner simple fix into the source code:

I hope they improve (Emlid), but until now, they’re just slow and buggy.

3 Likes

Hello,

Did you try connecting two Reach units with a radio link without ArduPilot? This will confirm you have everything setup correctly outside of Mission Planner configuration.

The ArduPilot tutorial has the screenshots of the settings for both base and rover. What’s wrong with them?

We appreciate the pull requests with your fixes, but can’t merge and release them immediately after you push. The team working on Reach is right now focused on other issues and features, but that does not mean we are ignoring your work. Those fixes will be properly tested and released in the coming weeks.

Not sure yet what’s wrong, we followed the instructions exactly hence assuming we must have done something wrong in some of the settings that are not discussed in the instructions…

Again, it works fine via wifi but not via 3DR radios

It’s OK that you can not release. I have now fixed the makefile and can therefore compile and install my patches on the Edison.

I also warned the rest of the Ardupilot developers about the bugs in the code, so they will not have to go through the same pains I had.

I will continue to work on integrating Reach into Ardupilot … but it would be nice if you guys helped me out. Please provide speed accuracy information, the next time your team works on the ERB protocol. I’m not getting paid to do this :slight_smile:

So 1 problem down:

BAUD rate for radios MUST be 57600 and NOT the 34800 in tutorials, for operation with v2 3DR radios.

Obviously, you do need the radios to be configured to be on the same baud rate. But, we’ll fix the screenshots, so that they have matching radio configurations.

Of course, was not setting them to different rates (and I don’t remember them being different in screenshots) but given that reach uses its own protocol it was not too surprising to think emlid might require a different baud (to the 57600 we all normally use for 3DR radios).

All of which is simply to point out to anyone following this thread in the future: For 3DR radios connected to Reach’s use the normal 57600.

Not sure what 34800 is for but nether it nor any other baud work with the 3DR radios and Reach

What I meant was that Radios also need to be configured to use a certain baud rate. There is no standard for them being 57600 by default. Since the value can be changed, that is not really something you can rely on, so their settings should be checked as well.

We will add this info to the docs.

1 Like

Hi, In my current setup i use Reach gps as primary gps. From the original GPS unit (the one that came with pixhawk i use only the compass)

I made some ground tests with this and it is working. I will get it into the air in the next few days and see what happens. From what i observed the corrections are sent from the base to the drone and the static position is accurate. I did some movements and i didn’t found any problems.

I am not sure why Reach does not recommend this. I somebody have more information why please share it. One downside is that you need 2 radio modules if you want to have telemetry and base corrections for the gps. But from the other hand you eliminate bunch of elements that can fail or at least bring a big delay to the system. We have the Mission Planner connected to the base through WiFi, then the mission planner sends the corrections, the pixhawk takes it, inject them in the primary gps and then we should have the more accurate position.

Regards

1 Like

One of the problems with Reach is that the reported ground course (heading) is wrong. That means that your GPS heading and your compass heading will not match. I’m not sure if the EKF will be happy with that. The good news is that I fixed that, the bad news is that your are going to have to recompile the Reach source code in order to integrate the fix into your system.


and

I’m interested in your flight findings with reach as main and only GPS, please post them.

I do not get this one, you can get both shared telemetry and injection with a single pair of 3DR radios. Are you saying that you need two pairs for this ??? Then you probably did not configured your system right.

1 Like

I am not using GPS correction injection through Mission Planner, that was my point. From the
https://docs.emlid.com/reach/ardupilot-integration/
(Reach supports a number of ways to accept base corrections, including the popular in UAV area serial radios. However, having a separate radio link for base corrections only is highly ineffective.), i use the “ineffective” way
I am using one pair of radios for direct communication (correction) between the base and the rover GPS. The other i use as standard telemetry radio (i.e. pixhawk to mission planner), i hope this clarify things.

What do you mean by GPS heading, is this calculated value from reach? Why would this be included in the EKF it is calculated after all. And we have the compass for that purpose which would be more accurate in showing orientation that the GPS heading.

Yes it is calculated by reach.

Because that is what the EKF does, it uses redundant measurements( multiple compass, multiple GPS headings) and finds a most probalble heading. Maybee you should google EKF to find out more about it.

Again why use a single sensor when you have a lot of sensors and a EKF algorithm ???
Did ypou understand what EFK is ?

Exactly, measurements, and GPS heading is not a measurement. I know perfectly what EKF is and how it works, and you could of course include calculated GPS heading in the orientation estimation. I didn’t know that pixhawk does that. From what i know EKF in paxhawk uses IMU data and the compass to calculate the orientation and improve GPS accuracy. But again this is my assumption.

I will test my configuration in the air and see how it behaves.

Dear sir , have you solved your problems ?
here is my setting up . hope can help you .
i am also stucked here . cant get fix , no matter what i do . cost me about 1month
but i can get corrections from base .

Rover:
RTK settings:
kinematic mode
Fix-and-hold GPS AR mode
GLONASS AR mode off

Correction Input
Serial
UART
38400
RTCM3

Position output
Serial
UART
38400
ERB

Basemode - OFF

Base:
Correction input - OFF
Position output -OFF
Base mode
TCP
Server
localhost
9000

Mission Planner:
All subtle parameter changes exactly per tutorial
Inject GPS:
TCP client
Port 9000

here is what i have done , i have 2 reach units
one as base , the other as rover .

base connect to pc , telemetry connect to pc too .

setting as you can see above .

the other setting about mission planner &pxihawk &telemetry , please see this for your reference .
https://docs.emlid.com/reach/ardupilot-integration/