Rover 4.0 + Ardusimple = GPS Yaw debugging

ArduRover Rover 4.0
41

@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.

3 Likes
42

Please link video, its inspirational.

43

Video here: https://www.youtube.com/watch?v=NjaIKyrInpg

2 Likes
45

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

46

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.

47

@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

48

@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

49

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

50

@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 :slight_smile:

Good luck, and Happy Holidays!

51

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.

52

Thanks Todd,
any chance you can send the config file?

53

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…

1 Like
54

I’ve opened a feature request specifically to get heading working on the ardusimple heading kit with one output.

55

Everything I remember about how to get the heading work in ArduCopter is:

  1. Enable the REPOLNED in the the Rover module using U-center
  2. Make sure that Base module output the RTCM v3 message
  3. Let the Ardupilot “Autoconfig” at the first time and later on, disable the “Autoconfig” in parameter list
  4. Recheck 2 GPS module to make sure whether or not the Ardupilot has done something different than previous steps (1 and 2)
  5. Configure and follow this wiki https://ardupilot.org/copter/docs/common-gps-for-yaw.html
    It just works when Base is in 3D fixed and Rover is in rtkFixed

1928×686

Hope this helps

56

@bigboy061293
Is that with simplertk2heading kit or two separate GPS boards?

57

@francismolloy, that’s correct. I used 3 identical simpleRTK2B boards. The Lite boards are actually slightly more expensive, and they have the added complication of needing a USB serial board if you want to debug more thoroughly. However, I don’t see why they wouldn’t work just as well. All you really need is an F9P breakout board with access to at least one serial connection and a good antenna.

58

@Yuri_Rage
Thanks Yuri
I will give it another go with a 3rd simpleRTKB board instead of the lite. board,
Is there a picture somewhere in your posts how you wired them? I olny have one radio available for corrections.
Once I get it working on these I’ll try again with the lite board.
Cheers

59

@francismolloy I used 2 F9P modules. UART1 of them is going to Serial 3 and 4 of Ardupilot.

60

@Yuri_Rage
Yuri
Did you configure the boards as base and rover from the Ardusimple configuration files? If not what configs did you use on each board, the corrections are not passing through with the radio on the moving base.

61

Thanks for all the support on this forum.
I have gotten the yaw messages from two ardusimple boards with wires connecting Uarts and transferring RTCM corrections.
I now see yaw numbers below 65535 all the time in inspector.
Only thing weird now is that the heading is 90 degrees off, I’ve tried correcting in many of the parameters but haven’t been successful in aligning it. In fact it doesn’t matter if I set the dimensions from x to y. I think this is because the GPS configs send the yaw and position to GPS2. but there is no way to correct for the yaw.

1 Like