Getting reliable heading/yaw for a big metal vehicle?

Will try the log again and have set the GPS injection back to 1. NTRIP wasnt connected for that test.

The GPS positions are as correct as I can make them with no knowledge of the antenna patterns, and if Mission Planner’s parameter notes are correct - “positive Y is to the right of the origin”. By that standard, they have the same X and Z position and GPS2 is to the left of the origin and GPS1 is to the right.

All of that is fair enough. With the fix types you have, it’s not really valid to compare antenna positions that way. It just appeared that something could be amiss.

Yeah, I haven’t got a clue why the difference between the GPS tracks is as big (or variable) as it is, other than that one or both just doesn’t have a great fix. I swear, this vehicle lives in its own portable Bermuda Triangle…

Here are some more logs with LOG_DISARMED=1:
https://drive.google.com/file/d/1FV_p2mp1NfVSzNRmMnlpy5YhIPBXZ_XR/view?usp=sharing
https://drive.google.com/file/d/1ajjJ_rcx4d2P0F-k8n0u9HOvvCP-g92U/view?usp=sharing

That’s interesting about the AHRS message. I definitely saw some ‘unhealthy AHRS’ warnings on MP during the above two tests but I didn’t see any EKF errors. I would think that if the AHRS wasn’t active at all, the EKF would be disabled. I guess I’m not sure what it means by AHRS from a software sense… Is that referring to the position control loop or something?

Ok, having resolved my telemetry radio packet size SNAFU, I’m back to actually setting up the GPS yaw.

Currently, the gps_yaw value is always 65535. I have RTK fix or float on the base GPS, which is receiving NTRIP injections, but still 3D fix or intermittent RTK float on the rover. The base is plugged into GPS1 port on the Cube Orange and the rover is plugged into Telem1. (GPS2 port doesn’t seem to work - nor did it on my last Orange…) Both GPS rates are set to 5Hz. Does this seem like a case for connecting the GPS’s directly to each other instead? Also, the GPS antennas are located only about 50cm apart. Would further be better?

5Hz is correct. I prefer the GPS2 port (SERIAL4), which I think is preferable due to a potential for DMA contention between certain UARTs on the Cube.

Before we go down that rabbit hole, what is your satellite count on each GPS?

Also, if you can increase the distance between the antennas, that may help, but I think 0.5m should work. Be sure the measurements are precise.

Sat counts are 24 for the base and 26 for the rover. I just moved the base further away from the rover and re-measured. Still the same deal - 3D/3D dgps on rover, RTK fix on base, gps_yaw = 65535.

Not sure what’s up with my GPS2 ports. Seems unlikely that they are both actually bad… but I have tried setting them up for GPS but they don’t even recognize that one is plugged in. It should be the same cable pinout as for Telem1, right?

Same pinout as Telem1, set SERIAL4_PROTOCOL=5 and SERIAL1_PROTOCOL=0. It will work.

Ahhh interesting. So Serial1 would be unused, I move the telemetry radio to Telem2/Serial2, move 2nd GPS to GPS2/Serial4, and the first GPS (which loads up as GPS2, for reasons I cannot explain) will stay on GPS1/Serial3? I will try this.

It’s now clear why things are happening the way they are for you. You have a GPS connected to SERIAL1 and SERIAL3. The one connected to SERIAL1 is the first one found, so it becomes GPS1, despite the labeling on the board (the UARTs are polled in SERIALx order at boot time).

Use GPS1 and GPS2 for the GPS modules. SERIAL3_PROTOCOL=5, SERIAL4_PROTOCOL=5. They will be found in order.

If you then choose to move your telemetry radio to Telem1, set SERIAL1_PROTOCOL=2 and SERIAL2_PROTOCOL=0. That step should make little difference as to your problem at hand, but I do think moving the GPS modules will help.

Okay, I now have:

Telemetry radio: Seral1/Telem1
GPS1 (base, receiving RTK injections): Serial3/GPS1
GPS2 (rover): Serial4/GPS2

And yep, the GPS plugged into GPS1 finally comes up as GPS1. That makes life a lot less confusing! However, the rover is still apparently not receiving an RTK fix from the base. I’ve still got an RTK fix on GPS1/base and 3D on GPS2/rover, and I now see the ‘gpsyaw’ value is 0 and ‘gpsyaw2’ is 65535 in the MP status screen.

Let’s reduce variables. Disconnect from the NTRIP server and see what happens. Also, post your GPS_POS* parameters here.

Well, I had to remove the autopilot from the vehicle again to open the enclosure and switch the ports - but with everything in a cardboard box in the parking lot I got 3D fixes and 25-30 satellites on both GPS’s, and the same gpsyaw=0, gpsyaw2=65535. It’s back on the vehicle now, I’ll re-test with the GPS’s in their appropriate locations and grab those params tomorrow.

Is it possible to get valid GPS yaw without RTK injection, theoretically? In previous tests I’ve done with these GPS’s with no injection, they seemed to disagree with each other pretty significantly… Maybe I’ve got some underlying hardware issues?

It’s entirely possible to get yaw without external RTCM3. That’s what I’ve been trying to get you to achieve. Like I said, one thing at a time.

I’m sure everyone above has seen the documentation for GPS-for-yaw but for those new to the discussion here is the wiki link.

I must admit that I still haven’t setup GPS-for-yaw on any of my vehicles so I’m unsure if the documentation is sufficient or not. If it isn’t sufficient just ping me and/or @hwurzburg with what we should add.

3 Likes

I believe the documentation is very accurate. Like most of the Wiki, it is concise, which is good. One just has to be careful not to gloss over anything. Every statement is important.

1 Like

Randy, if feasible, you really ought to try a moving base configuration on one of your boats. I think you’ll be pleasantly surprised with its precision and performance.

There’s not much lacking about the moving base documentation unless you’d like for it to explain basic concepts as a preamble to setup instructions. As shown in this topic and several others, there’s a fundamental misconception that external RTCM3 injection is required for a moving base configuration, and there may be some other easily misunderstood aspects as well.

There are also competing documents from various vendors that lead to more complex than necessary configuration steps (like diving deep into uCenter for uBlox modules that can be perfectly configured by the autopilot with no need for uCenter) and/or referencing no longer relevant parameter settings.

I’ve been meaning to follow the wiki editing guide and set up the editing environment in the event that I find a case where a note or clarification would prove valuable. I’ll see if I can find a little time for that.

2 Likes

Sorry I didn’t explain this. You can check here for a day and hour in your location with low HDOP and test then. You can check if you get RTK fixed with the RTK GPS and u-center alone.

See this other video: two RTK GPS’s with RTK fixed (u-center 3D/DGNSS/FIXED) report coordinates difference coincident with their physical separation, but that doesn’t happen every day, and even on a good satellites day at all times.

Aha. Okay, I did misunderstand that from reading the documentation at GPS for Yaw (aka Moving Baseline) — Copter documentation (ardupilot.org). Knowing next to nothing about GPS yaw or GPS anything, I saw this under the ‘Testing’ section:

Note that it can take some time for the two GPS modules to get a sufficiently good fix for yaw to work. The ArduPilot GPS driver validates that the fix is good enough in several ways:

  • that the rover GPS module is in fix type 6 (fixed RTK)

…And since I have only seen my GPS’s in fix type 6 when connected to NTRIP, I just assumed that was a prerequisite.

I’m not sure the docs need to explain basic GPS concepts, but maybe they could include a link to something that does–for those of us who are too clueless to even know what to Google.

GPS status more or less unchanged from yesterday - I’ve got 28 satellites and 3D dgps fix for both GPS’s, gpsyaw=0, gpsyaw2=655.35. Does that indicate that GPS1 isn’t configured correctly?

And here are the location params:

GPS_POS1_X: -0.41
GPS_POS1_Y: -0.62
GPS_POS1_Z: 0
GPS_POS2_X: 0
GPS_POS2_Y: 0.32
GPS_POS2_Z: 0.41

GPS1 is mounted to the left side of the UTV’s cargo bed. GPS2 is up on the right side of the roll cage, slightly to the right of center.

Is there really a Z difference?

Can you attach the full parameter file?