Ardusimple simpleRTK2B+heading configuration - Is it really works with 4.1-beta7?

Based on the following guide Ardusimple simpleRTK2B+heading configuration should be working with the latest beta of the Ardurover:

Although I have managed to setup the two modules and connect it with my Pixhauk4 I can’t get the correct YAW. In fact I noticed that I still get compass from Pixhawk (I rotated without change the position of the two GPS antennas and the value of the YAW changes, which is not the expected behavior).

Here are the parameters I changed based on the above guide:

GPS_POS1_X,-1.25 * *This value must contain the distance in meters between antennas.

Could anyone confirm that in his own implementation he has managed to make it work?


Thanks for giving the beta a try.

The GPS-for-yaw with ArduSimple does seem to be working well and there is an active discussion going on here about it.

I think we need to improve our documentation a bit still and that’s on my to-do list.

1 Like

Randy, I started typing a reply to @Iannis to say how well the Ardusimple configuration works, but then realized he is specifically asking about the Ardusimple daughter board and SimpleRTK2B configuration. I decided I would just be guessing to some extent. I looked over the document he references and it appears that the daughter board (Moving Base) has no connection to the FC, and hence they have GPS_TYPE=0. Among other unknowns
to me, I am not sure if Ardupilot kicks in the GPS Yaw feature with that setting.


Like Kenny, I have no experience with this configuration, but I have been following some of the discussions about it.

I find the GPS_PRIMARY=1 parameter very curious. I think that should be GPS_PRIMARY=2 since GPS_TYPE=0.

Also, the following settings have been proven more reliable than 10Hz updates when using GPS-for-yaw:

Lastly, you cannot confirm or refute the existence of valid GPS yaw by using the flight controller’s fused yaw value on its own. Depending on the state of other sensors (internal compass, accelerometers, etc), it is ENTIRELY expected behavior for the EKF to output a yaw/heading value that changes with motion, even when GPS yaw is not available.

Instead, open the MAVLink inspector (Ctrl-F, then click on the MAVLink Inspector button), and find GPS2_RAW. The yaw value displayed there is the one you need to monitor. If it’s 0 or 65535, GPS yaw is in an error state. Otherwise, it displays heading in degrees * 100.


Thank you for your reply and time to help me. I opened the MAVLink inspector and noticed that the relevant yaw value of the GPS2_RAW is 65535 so I guess we are in an error state.

In addition to Yuri’s points, I am suspicious of the statement in the Ardusimple doc “GPS_POS1_X,-1.25 * *This value must contain the distance in meters between antennas.” The heading that the rover GPS reports to the FC is the heading toward the MB (or it might be the heading from the MB to the rover GPS, I can’t remember). The point being that this heading is NOT the heading of the mower unless you have the GPS antennas aligned along the X axis of the mower. That is not required since the GPS_POS parameters for both 1 and 2 GPSes are used by Ardupilot to translate the reported heading from the rover GPS to the true heading of the mower. So, I wonder if you should set GPS_TYPE to 17, and enter all 6 GPS_POS parameters. The antenna locations should be measured from the center of rotation of the vehicle. Ardupilot, as of a couple of updates ago, I believe, gets position from the MB and heading from the rover, but if the RTK status of the MB is not good, it will instead use the position from the rover GPS. (I will not promise I have this right, but this is my understanding). So, maybe Ardupilot will do the same failover to everything coming from the rover GPS in a case like yours where the MB is not connected.

A lot of conjecture on my part here. This is why I hesitated to comment, so take my thoughts with a grain of salt!

EDIT: You will get 65535 if the GPS_POS parameters are way off from reality.