Servers by jDrones

Use Heading from Dual GPS

Yes & No I have not other than looking at post processed data. I will rig up a test this week.
set 3 baselines for comparison CA, carrier phase & RTK GPS receivers.

Possibly if you were using 1GPS only & 1 Glonass only or had interference at only one GPS.
Like I said I run a test for ya.

I did run a test today. This does work. If you set up 2 gps just watch as the positions float together. With all corrections off max variations were +/- 6 cm (in 2 out of 20 comparisons). As you suspected, this occurred when one had 16 sv’s one had 17 sv’s. However for most (18 out of 20 comparisons) they were right on +/- 2cm.
For this test the units were 1 meter apart and ran for 1.5 hours. I started recording data after 5 minutes of position reporting.

1 Like

Here are some photos of a 2nd test situation. The 3rd observation you can see a 4.5 degree vertical error when different sv’s are used . The horizontal is much better still.
The receivers are 1.515 meters apart (field measured)

1 Like

Thanks, for this test. We ran a similar test with an Ardusimple RTK. The problem is that it is far from the accuracy of a compass if you don’t have a huge vehicle. I have a copter on a F550 frame which does not even allow me to mount the GPS 1m apart.

Agreed! I do not think Dual GPS is applicable to RC anything. There are some nice compass out now that look like a much easier solution https://store.drotek.com/sensors

I understand if you are purely hobby users, but understand that for professional users of Ardupilot an aircraft/boat/rover with at least 1m span or length is not unusual. There are many use cases where either magnetic interference or not being able to physically move the craft into all the positions required to initialise magnetometers makes them less than ideal.

There is also the added benefit that GPS heading does not change over time, if you are wanting to repeat missions over multiple years magnetic declination changes quite quickly. This requires compensation that GPS heading does not.

2 Likes

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?

Servers by jDrones