Servers by jDrones

Use Heading from Dual GPS

We must have different professional focus and you are a more advanced user. From my point of view & the GPS I have tested the error rates are not good at 1.5 meters. Agree there are some large craft out there but I don’t need that for my professional use. I have 1/4 scale planes that I fly for hobby. Still my professional drones are all under 7 lbs. I do survey work in town most of the time a big plane scares me around people.
Declination here in my town has changed 5 degrees in the last 150 years. I have 1860’s records and though it is changing slightly faster than normal right now it’s somewhat predictable unless you are close to the poles.

For the majority of users the magnetometers are cheap and provide an adequate heading. I think for those with large enough vehicles that are already running RTK the superior lock of GPS heading is well worth it.

1 Like

@Reuben_Finch did you consider the UBX RELPOSNED message? My setup is Pixhawk4 + RPi + Dual Ardusimple GPSs (diagram here). RPi sources RTCM messages over the internet and sends them to the Ardusimple set (only have to send to one of the GPSs). Then the other Ardusimple sends NMEA messages (did you know you can enable high accuracy in NMEA messages? You can!) to the pixhawk. However per the Ardusimple folks, here, the heading information is only in a UBX RELPOSNED message.

Any hints on what code in Ardurover is the closest starting point for me to write code to receive & interpret the RELPOSNED message?

Thanks-

It will be fairly easy to modify the AP_GPS_UBLOX h and cpp to add in the ‘RELPOSNED’ message.
It seems there’s really only the ‘relPosHeading’ value that is of any use in that message.
Then I would follow @tridge’s Heading from gps yaw fork to connect that value into the EKF3 code.

I’ve just noticed that this code has now been merged, so you will only have to replace the NMEA HDT message.

Given that this ‘RELPOSNED’ methodology is now possible, it might be worth working on this together then get @tridge to look over it, if we’re quick enough we might get it merged into the next stable release. It saves one UART. Just need someone to produce a dual F9P board to make it more convenient for smaller vehicles.

Got it. Will keep you posted. I will start by hardcoding the physical location of the 2 GPS antennas on the vehicle so my code will be far from a straight merge.

In my case the 2 antennas are on the longitudinal centerline of the vehicle, one (“Primary”) at the rotational center of the vehicle, i.e. between the 2 wheels, and the other approximately 1.1m forward of it. This means that the GPS position of the primary GPS is what I will use as the GPS position of the vehicle. When the rover rotates, this antenna does not move. I have found this to be important to get pivot turns to work. The secondary GPS is just used for heading…

I expect that others may choose different geometries, in particular, 2 GPSs at the same fore/aft station, one left and one right of the centerline. This geometry would require calculations to determine the position of the center of the vehicle.

Hence I think I should leave it up to others more familiar with ardu-code to figure out the appropriate parameter names & values/encoding necessary to parameter-ize the different scenarios of the positioning of the 2 antennas.

Bear in mind that there are gps offset values that exist as parameters in Ardupilot. Usually those parameters are used to compensate for an antenna placed in a less than ideal position. Perhaps there is a way to use them. Either way it could be easier to just add 2 new parameters, Antenna separation & bearing from antenna 1 to antenna 2. This would allow any strange arrangement of antennas and even allow for the heading antenna to be placed North or South of the primary GPS antenna.

Let me know your fork when you have started.

3 Likes

@Christopher_Milner, I’m very interested in this capability also. I look forward to hearing of your progress and please let me know if I can help.

Hi Kenny, good to hear from you. Bottom line I have a work thing due 9/23 and probably won’t make much progress on the gps heading before then…

Understood! I am a member of that same club (too much to do, work, etc.) to do what I want to do!

I just purchased and setup ardusimple’s simpleRTK2B + heading. Now I have a rover reporting RELPOSNED messages so If anyone wants me to test anything in the future, let me know.

Hello, I am really new to ardupilot here. Could you please let me know:

  1. What does RELPOSNED mean?
  2. I have another module which output NMEA (GGA and HDT messages), can you please show me how to use the heading from HDT for replacing the yaw source or lowering it’s weight? I have read this here https://github.com/ArduPilot/ardupilot/pull/7215
    and trying to tune some parameters but it does not help.

Thanks in advance!

@bigboy061293 RELPOSNED is a Ublox UBX message that gives info on the RELative POSition of the GNSS antenna with respect to the base station it is receiving corrections from and uses the North, East, Down coordinate frame.

The settings in the link you give to use this data for orientation in place of the magnetometer should work with the latest code. I have only tested Rover 4.0 modified to use UBX RELPOSNED (as opposed to NMEA HDT). I no longer use the magnetometers on my CubeBlack

Hi @jimovonz , thanks for your reply, could you please check my parameter whether it is right or not

If not, do I miss something?

That looks OK. What feedback are you getting that makes you think that it is not working? What version of Ardupilot are you running? What GNSS unit do you have? Are you sure that it is configured to output the NMEA HDT message? What do you see looking at GPS.Yaw in a dataflash log? How about posting a dataflash log?

Hello,

This is the case:

.I am using arducopter firmware 3.6.11, most updated ardupilot version
.I have the GPS module (K726 from sinoGNSS) output NMEA which I have already checked with terminal software via UART, at 10Hz. When checking the HDT message, it returns exactly the same heading with respect to the true North,
. GNSS is fused between GLONASS, GPS, BD2, GALILEO, SBAS. This tasked is handled by the module, which return numbers of satellites always > 10. I think the heading from HDT message is reliable enough.
. About the yaw situation, I am looking for a way to export the dataflash for further discussion. At the moment, when I turn off the COMPASS, restart the Cube, it returns yaw 0 degree and it keeps drifting because of using only gyro and accelerometer. To my understand, if everything works well, it must be the angle from HDT message, right?

Thanks.

Looking at the Copter-3.6 branch in Github, it seems that yaw from GPS is not supported. You will have to use the latest code from the master branch if you want to test this functionality. Please be aware that this code is the bleeding edge of development and that there are untested changes in this version. You use it at your own risk.

Hi,

Do you mean that I have to do it by modifying the code and compile it? If so, could you please let me know where do I have to start.

Thanks.

No, there are daily builds of the code here: http://firmware.ardupilot.org/ You can download the most current version of copter for your hardware and upload it. Mission Planner also allows you to select ‘Beta’ versions of the firmware to upload too.

Thanks,

I have came http://firmware.ardupilot.org/Copter/ and https://github.com/ArduPilot/ardupilot but can not see the “Release notes” of this firmware (4.0) http://firmware.ardupilot.org/Copter/latest/CubeBlack/git-version.txt

Hi, I have tried it with 4.00 and it works pretty well. However, the NMEA message are read from GPS2 port which I change to GPS1 later and it does not work anymore (with the same configuration). Any ideas?

Thanks!

Servers by jDrones