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.
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
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.
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?
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.
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
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.
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.
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.
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.
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.
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 .
Fix-and-hold GPS AR mode
GLONASS AR mode off
Correction Input Serial UART 38400 RTCM3
Basemode - OFF
Correction input - OFF
Position output -OFF
All subtle parameter changes exactly per tutorial
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 .