Hi Chris
I managed to get the system working in default ardusimple configuration.
One thing I think was key was to check the GPA.delta in the logs. Mine was up at 1000 or 1 second.
That was a good clue, so I configured first the rover to send RCTM at 10hz and then the MB to send GPS updates at 10 HZ.
once I had good RTK fix, I got heading straight away and repeatedly.
@graham_new great. Would you mind sending me your gps config files and your ardurover logfile? Just to confirm this is with the 2 GPSs in the “piggyback” configuration?
Hi Chris
I am using this on a copter.
GPS are in piggy back.
I think what solved my issue was to increase the gps rate to 10HZ. First must change it on the LITE baord, then on the classic board.
It is important for both modules to be configured to the same rate. The timing between observations and receiving corrections is critical for MB. It is also for this reason that the communication link between the two units is fast enough. Above 5Hz with the standard setup I see frequent drop outs in the RELPOSNED heading. I have managed a stable 10Hz using the latest firmware, a direct connection for corrections at 921kbps and using only the minimum required msm4 messages. Lately however, I have been experimenting with leaving both F9P modules set up for stand alone rtk and calculating the heading from the positions. This seems to work well and the advantage is that I can now get rtk positrons at up to 40Hz (GPS only, 25Hz with 3 constellations excluding Glonass ). The accuracy of the heading seems to be about half that of a proper MB setup but since we have large vehicles, this is not a problem. I see ~0.5deg total variation using a 1.3m separation (baseline)
@jimovonz thanks for the update. Have you built a custom version of ardurover with code that determines heading based on the two GPS positions?
I have wondered whether I will eventually want another receiver onboard for when one receiver loses rtk fix.
@Christopher_Milner - yes I have customised the code to determine heading based on the relative positions reported by the two on board gnss. I have tested this in SITL, on the bench and briefly on a vehicle. I am hoping to get time tomorrow on a vehicle to more fully test both this and the high precision location code during full autonomous running (Chasing better accuracy).
@rmackay9 recently reached out to me after I posted a YouTube video of a zero turn mower using GPS yaw with Rover 4.1.0, a Cube Orange, and ArduSimple SimpleRTK2B F9P boards (fixed base, moving base, and rover). This thread seems an appropriate continuation of that brief comment exchange. I’m not sure I should post the video link here, since I don’t want to seem as if I’m just shilling for video views.
Here’s what I’ve learned after many hours of experimentation with parameters and settings:
I spent HOURS rebooting and tweaking parameters with Rover 4.0.0 and never achieved any real measure of success with GPS yaw. Rover 4.1.0-dev as of July 2020 seems to have improved things quite a bit. I did not dig into the code changes to determine why, but I cannot recommend GPS yaw under the 4.0.0 stable release based on my observations. The 4.1.0-dev branch works great for me at present.
The moving base and rover F9Ps must be connected directly to one another via their UART2 ports (what seems to be called “piggybacking” above), with GPS_DRV_OPTIONS=1 set. Attempting passthrough RTK from one to the other through the Pixhawk always fails for me.
While disabling GPS_AUTO_CONFIG makes for a faster initialization sequence, EKF3 never sees the config data it wants, and the sequence hangs, as described above. I always keep this enabled.
GPS_RATE_MS for both GPSs needs to be 100ms. Anything faster is glitchy, and anything slower results in bad GPS signal warnings (at least on the Cube Orange as well as an older fmuv3 board that I used until somewhat recently).
I have yet to achieve a solution to repeated nuisance warnings of “Bad Compass Health” when disabling all compasses. I always keep the internal compass enabled, which does seem to help with occasional GPS yaw failures when satellites drop from view or other brief (and as yet unexplained) errors occur with GPS yaw. I rarely see more than a fraction of a second of 65,535 on GPS2_RAW with my current setup, but it does occasionally/momentarily fail to achieve a solution.
@rmackay9 - I sent you the log file you requested via email, but perhaps it went to your junk mail. I’d rather not post full log files to the public forum in the interest of privacy, but I’m willing to share as much info as I can otherwise.
Please link video, its inspirational.
Hi All
I have an issue and wondering if anyone has any advice:
Running Arducopter 4.0.4 with ardusimple for heading.
Because Compass_enabled = 0 and compass_use = 0, I get PRE ARM COMPASS NOT HEALTHY errors and I cannot arm. (unless I force are through mission planner)
Is there any way around this?
I have tried enabling compass 1 and 2 (the 2 x internal on the cube) but then I get a constant BAD COMPASS HEALTH message on the HUD.
PreARM check for compass is DISABLED, but still it stops the copter from arming.
Any ideas?
Thanks so much
Good day @Christopher_Milner I’m checking in to see if you got this to work. I’ve been toying with this for two weeks now, learning a lot. But seems I can’t get close enough to for actual success running a rover (tracked skid steer vehicle) with the ardusimple heading RTK kit with additional base. Everything checks out in u-center. but the minute I hook up to the Pixhawk and cubepurple on a mini carrier, Ardupilot changes the configs and the boards stop receiving RTCM corrections.
Also I have no idea how to confirm that heading Repolned messages are coming in. Theimu takes over when moving the unit around.
Finally I enabled autoconfig in order to get going, but I still get “EKF3 waiting for GPS config data”
GPS1 gets reconfigured at 460800bps, and GPS2 is undetected. I have them both plugged into Arupilot carrier on GPS 1(ardusimplite- the moving base) and GPS 2 (ardusimiple - rover)
Not sure where to go from here. any advice?
Have a great holiday week.
@Yuri_Rage Sounds like you are going at this with full ardusimple boards instead of the rtklite on top of the second classic board. Seems like the support for this heading kit from Ardusimple is not great for the Ardupilot platform. The lite board is marginally cheaper, I might get a third classic board and connect the Uart 2’s with hard wire and see what happens
@francismolloy I’m not using the ardusimple boards but they are fundamentally equivalent to the Ublox F9P dev boards I’m using when I disable the internal radio. If your second GPS unit is not being configured then I suggest you start there. Verify that the serial connection is functioning properly by swapping the cable between GPS units and serial ports. Both Ports 1 and 2 of both GPSs will be reconfigured to 460800bps, so the only way to get static ground station RTCM into the pair is through Mavlink2. Also, cross connecting Serial 2 between the GPSs seems to work better than routing it back through the FMU.
Hopefully that gets both GPSs autoconfiguring. At that point you should start getting heading information. With Mission Planner up, press CTRL+F to load the temp window, and select MAVlink Inspector. Drill down to GPS2. You will see a YAW value there for GPS2. If it is above zero and below 65536, then you are seeing GPS Yaw. If it is 0, then you are NOT getting Yaw. If it is 65535 then you are configured for Yaw and will have heading information as soon as the GPS locks support the calculation.
-Todd
Thanks Todd,
The second GPS (moving base) gets Uart 1 and 2 as well as power from the xbee connector on top of the first, and the rover expects RTCM corrections here.
it’s a battle of configs… pixhawk needs one thing and ardusimple needs another
i’ll keep at it, thanks for the tip in finding the Yaw messages. They are coming in on GPS1
@francismolloy Yaw corrections should be coming in on GPS2. Have a look at your configuration settings. Both serial ports have to be set as protocol 5 under Serial configuration. The first GPS port should have GPS Type set to 17 and the second serial port set to 18. Set GPS_DRV_OPTIONS=1 and GPS_INJECT_TO=127. All together, that should configure the second GPS to send yaw that would be seen in GPS2.raw.yaw in the Inspector. With this configuration and without injected RTCM from a Static Base, the first GPS will see a 3D DGPS fix and the second GPS will see a RTK Fixed fix (from the GPS1 RTCM3 corrections). When you add static base corrections over Mavlink, the first GPS will go to RTK Fixed as well, and your yaw corrections will start becoming useful. I have not been able to get a yaw below 65535 without static base corrections, but I can’t say that is always true.
As I understand it the ardusimple ‘stacked’ configuration should just work with the appropriate settings in the pixhawk under Rover 4.1.0. That was the configuration I copied to make my F9P dev boards work 
Good luck, and Happy Holidays!
I had two problems that prevented me from getting both GPS from working. First was a bad serial cable. The second was bad settings on the F9P. I did a factory settings reset and reinstalled the GPSes without any further settings and they started working. Also make sure you have 1.13 firmware on the GPS. To be clear, I haven’t received good yaw numbers yet, but I think that’s because I need to fix the GPS antenna positions in ardupilot.
Thanks Todd,
any chance you can send the config file?
I do not have this working yet. I set it aside a few months back hoping that someone would figure it out in the meanwhile…
I’ve opened a feature request specifically to get heading working on the ardusimple heading kit with one output.
Everything I remember about how to get the heading work in ArduCopter is:
Hope this helps
