Hello
I replaced compass to moving base, and used NMEA type message as GPS source.
also follow the ek3 setup, to disable Compass, set ek3_ahrs as GPS_YAW… etc.
so far I already have good flight result without Compass. thanks to the Ardupilot team
before take off, it’s important to make sure AHRS is ready, so I verified by checking NMEA $GPHDT, to see the Yaw weather it have same value or net. if not I need to reboot flight board.
is possible to add GPS_YAW on Mission planner Quick window?
If you go to the help tab and do a beta update, gpsyaw will be selectable. However, I have yet to see it work correctly - it always seems to display a zero value even when the MAVLink message GPS2_RAW.yaw is valid.
I have a minor amount of experience building Mission Planner from source and will look into it a little, but perhaps @Michael_Oborne can provide a solution faster than I will.
UPDATE:
I have found part of the problem with the beta gpsyaw display value. In CurrentState.cs around line 2800, the gpsyaw value comes from the GPS_RAW_INT.yaw message rather than GPS2_RAW.yaw.
I can probably create a pull request and fix it unless Michael beats me to it.
(He beat me to it…as I was making the changes in my own fork of the code, I saw he made a new commit entitled CurrentState: add gpsyaw2 - I expect we’ll see a reply when the new version goes live)
thanks a lot, it works.
in my case, GPS yaw value source from NMEA > GPHDT,
what’s “moving base” module you using?
Ah, very good! You didn’t even need the software revision I was talking about.
I hadn’t considered that some configurations actually do populate the MAVLink GPS_RAW_INT.yaw value.
I use Zed-F9Ps from ArduSimple in a moving baseline configuration where GPS2 is the rover. In my case, I actually do need the software revision to view the gpsyaw2 value.
For those following this thread, the latest Mission Planner beta (build 1.3.7940.1610) includes gpsyaw2 as a selection for the Quick tab.
Thanks much to Michael for the nearly instantaneous response!
Hello,
I have GPS for yaw working on my copter, and I have a version of Mission Planner built that includes the CurrentState: add gpsyaw2 commit. However gpsyaw and gpsyaw2 still report 0 and -1 respectively. Is there something I need to turn on in ArduCopter to get the gpsyaw messages to go out to MissionPlanner? Or a specific version of ArduCopter (Im using 4.1.0-stable).
What GPS modules are you using?
Oh sorry, thats important: Im using ArduSimple’s simpleRTK3B Heading.
I should think you’d see it as gpsyaw. What does GPS_RAW_INT.yaw report via MAVLink inspector?
With the RTK3B reporting heading (confirmed by connecting to it via usb), and MissionPlanner reporting a correct heading and small EKF compass variance, the MavLink Inspector lists a zero for yaw under the GPS_RAW_INT header.
Then your configuration is incorrect, and the AHRS heading value is not coming from the GPS. Have you followed the instructions here?
Yes, I followed the ArduSimple instructions for RTK3B Heading. I can see the heading reported in the Mosaic web interface. That heading matches the heading of the EKF (after it settles and EKF compass variance is low).
I’m unclear how the AHRS heading value is not coming from the GPS. The internal compass is disabled (the hardware) and all three compass_useN are set to 0. You think somehow the internal compass from the Cube is still being used for heading anyway? I guess I can take a magnet near it and find out for sure.
Double check your settings and parameters. If GPS_RAW_INT.yaw is unpopulated or 0, the autopilot isn’t getting GPS heading from the SimpleRTK3B.
Post a copy of your parameters.
First off, params attached.
X8_GPS_heading_AS_RTK3B_AC_v4p1p0.param (17.8 KB)
Second, I ran a couple of tests:
with USB connected to the Cube, I do see yaw in GPS_RAW_INT. (It also then shows up under status gpsyaw). This insinuates it is using GPS yaw at least when the USB is connected?
now connected via radio, I detached the gps constellation from the cube. I then rotated the GPS constellation without altering the cube’s position. The heading slowly skews towards the heading of the GPS constellation, not the heading of the cube.
with attached parameter configuration, I waved a small magnet in front of the cube and the heading does not waver.
changing parameters to enable the internal magnetometer and discount the heading info of the RTK3B, waving a magnet near the cube results in large (~60deg) deviations of reported heading (as well as a lot of compass variance and other errors).
Is there any other way to check that the arducopter software is using the RTK heading besides a downstream message in Mission Planner?
Ok, I think there’s a logical answer!
Your troubleshooting seems to confirm that the GPS module and autopilot are configured to work correctly together.
It’s the telemetry protocol that is causing problems. It looks like you’re using SERIAL1 for radio telemetry, and the protocol is MAVLink1, which doesn’t support GPS heading messages. Try using MAVLink2 by setting SERIAL1_PROTOCOL=2.
Note: the telemetry protocol won’t affect the yaw source, it will simply fail to report GPS heading to the GCS when set to MAVLink1. The AHRS heading and associated HUD value in Mission Planner will still reflect correctly.
That was it!
Thank you so much for the help.
