How to pass it on

Last June we had help to install the driver: (https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_GPS/AP_GPS_NMEA.cpp)

to include the GPHDT sentence from our GPS Compass (Hemisphere V103). And it has worked fine apart from the fact that it is not being registered as a compass in ArduPilot.

Here it is in my back garden showing a YAW of 89.66, and the HDT message from the V103 says 89.79 and 89.96 so that is only minor differences. See the images here: https://drive.google.com/drive/folders/1JBcYNLrUGkxz3B5xXilkwony0HbonoFl?usp=sharing

So, how do we pass it on, so that it is shown on the HW ID list as a compass ? Is it maybe an amendment to the driver, that is needed ?

@bok555,

Yes, I think we would need a NMEA compass driver written in ArduPilot to consume the message. Once a developer did that they could send a Pull-Request to ArduPilot to have it included in the main code so that it would appear for everyone in the next major release.

I’m ought to be able to develop the code. I know the GPS-compass, but I do not know the Architecture of ArduPilot.
Can direct me to some How-To’s or a piece of code to addapt?

@rmackay9, @Knaldgas, @tridge

I think you are right that such an NMEA Compass will benefit the community. My application is to do hydrographic surveys fx in harbors, where a magnetic compass can have troubles close to harbor walls etc. I know a commercial developer of USV’s https://www.unmannedsurveysolutions.com/ who use ArduPilot and a magnetic compass and admit, that they operate in manual mode close to bridges etc.

Can you possibly propose someone, who can help us with this ? @Knaldgas and I know the GPS Compass, and @Knaldgas can develop the code, but is not familiar with the ArduPilot framework.

Do I understand it correctly, that most of the work is done in the AP_GPS_NMEA.cpp driver ?

We have some information here on writing drivers. Coincidentally we had some discussion during the developer conference about integrating a NMEA compass. One issue may be that the sensor may report an earth-frame heading instead of a full 3D vector. If this is the case it will be more difficult to integrate because the EKF expects a 3D vector.

Thank you. I’m waiting on a response from Hemisphere, and will report back as soon as I hear from them.

@rmackay9
On these GPS compasses the heading is derived from a position solution between the Primary and Secondary Antennas. The data is referenced to the WGS-84 datum and the heading value/s may be output inside a choice of NMEA and Binary messages.

So, you are right this type of instruments does indeed report an earth-frame heading.

Nevertheless, I still think the community would benefit from such a NMEA Compass Driver for the reasons described above.

Just some context for this discussion:
https://github.com/ArduPilot/ardupilot/pull/7215 is where support for the Hemisphere yaw-from-gps was added.
I guess the relevant thing is that the driver feeds yaw to the ekf via the gps driver, not the compass driver.
Another thing is that the measured yaw from the gps, and calculated yaw estimate output by the ekf aren’t going to be exactly the same.
If the driver is working, what problem has this caused?

@james_pattison
Yes, the driver works fine. The problem is that the YAW is not registered as a compass in ArduPilot.

1 Like

hi Bo,
If it is giving the HDT message and also the rest of the normal GPS position messages then it should work already, and just needs the setting to tell the EKF to use an external yaw source. If you set the following:

  • AHRS_EKF_TYPE=3
  • EK3_ENABLE=1
  • EK3_MAG_CAL=5

then it should give the yaw from the GPS into EKF3.
If this device only gives HDT and not position and velocity messages then we’ll need to do it differently.
Cheers, Tridge

@tridge @Knaldgas
We have tried that extensively. Without knowing precisely what goes on, and based on the things we have discussed in this string, I wouldn’t be surprised if the EKF does not accept the yaw from HDT maybe because that is an earth-frame heading instead of a full 3D vector.

And as I said, I have tried it extensively. I got through Speed and Throttle tuning Ok, as well as the ACRO_TURN_RATE, but I never got any sense out of Steering Rate PID Tuning. I can see now that I should have focused on the alarms: “Bad AHRS”, “Bad Gyro Health” and “Bad compass variance”. The kayak would not steer a straight line, it threw the rudder from port to starboard and back while I tried a full variety of settings… see the attached image from my test harbor…

The device gives all the messages needed, GGA, VTG, ZDA, RMC, HDT and ROT at 20 Hz, the accuracy of the GPS compass is < 0.30° rms, which is what is needed for a professional hydrographic survey.

So, how do we proceed from here ?

Best regards
Bo

next step is to link to some logs for us to have a look at!

Here is the link to my GoogleDrive:
https://drive.google.com/drive/folders/1JkiFCh_CMbyP9wfeZDtxxIXepYSeQ30B?usp=sharing

@bok555 I had a look at the log you sent me a link to. The key issue is shown in this graph of GPS yaw:


you can see that the GPS yaw keeps oscillating between what is probably the correct value (around 30 degrees for this part of the log) and a value of zero.
To work out why this is happening we will need a capture of the NMEA traffic between the flight controller and the GPS. Then I can feed that capture into SITL and try to work out what it is about the data the GPS is sending that is causing the yaw to reset to zero once a second.
Cheers, Tridge

So shall I make a txt file of what comes out of the GPS for fx 30 seconds - will that be OK ? And what is SITL ?

@tridge @Knaldgas
I have uploaded a txt file with 6 minutes GPS output. It was recorded from a UDP link that is used as input to Hypack (Hydrographic Survey software). The BBB board that is running ArduPilot is fed with a serial link directly from the GPS.

I had a looked at the file and saw, to my surprise, that there is only 5 updates per second. Surprised because the GPS has been set to output 20 times per second. I sincerely hope that that is the case for the direct serial link. I will check this.

To find the file look for “20200429_1618_GPS.txt” in the same GoogleDrive location as yesterday.

/Bo

I looked at the NMEA capture and the problem is that the HDT message is coming at 1Hz, and we timeout the yaw from GPS after 300ms

@tridge @Knaldgas
I have changed the settings in the GPS to update at 10 Hz. I have uploaded a file: 20200501_114352GPS.txt and an image: 20200501_1421 Bo’s Kayak in garden.png to ‘our drive’. But I still get errors “Unhealthy AHRS” and especially “Bad Compass Health” - any clues ?

@bok555 I tested out your new log and found there is a bug in master with handling GPS yaw (the bug was introduced last week). I’ve done a fix here:


with the fix in place the log from your GPS does work fine with rover.

1 Like

@tridge @Knaldgas
Fantastic, tridge, and on a Sunday :slight_smile: :smiley:
I’ll get it tested right away.
Report back tomorrow