Can someone advise. I’ve followed the tutorials meticulously, have the latest/beta version of everything and can get a fix through mission planner via tcp but can’t get the corrections to come through via 3DR radio
Setup is (when working via TCP):
Rover: RTK settings:
Fix-and-hold GPS AR mode
GLONASS AR mode off
IP of base
Basemode - OFF
Base: Correction input - OFF Position output -OFF Base mode
All subtle parameter changes exactly per tutorial
Again, corrections get through and fix is obtained
When we change to corrections coming in via 3DR radio the only thing we change is Rover: Correction Input
And we still see input in mission planner but in rover view there are no corrections visible and no fix
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.