EDIT:
Let’s start over here - EXACTLY which radios (model/type) are connected to EXACTLY which bits of hardware? Be specific.
(I don’t think we are using the same terminology to describe what a “radio” is - hence the question)
1 Like
Oh, I’m sure I’ve messed up somewhere…
Best I could do on short notice:
Pixhawk 6X CM4 (without an RPi installed)
Are you still injecting the RTCM3 signal from base station by going through your ground computer and to the rover over the telemetry radio? It sounds like you now have additional radios on your mower. Are you trying to send the correction signal directly from the base station to the Ardusimple GPS card? If so, only one radio is needed in addition to the main telemetry radio.
1 Like
Ok, so you have no additional telemetry radios (like XBee or LoRa) connected to the ArduSimple modules themselves?
And only one telemetry radio connected to SERIAL1, through which RTCM3 is passed from Mission Planner?
1 Like
Correct - no xbee or LoRa or anything other than one telemetry radio (holybro 915mhz) from MP base computer with NTRIP connected to (fairly) close NTRIP broadcast station, to, pixhawk/Telem1.
Then I think your config is likely correct at this point, and you should try a full power cycle of the vehicle and electronics while in full view of the sky. Leave it disarmed with the engine off. Wait 15 minutes. If you see no change in gpsyaw2 (to a valid heading) at that point, we need to dive deeper.
1 Like
On it…thx for the lift…
And a quick glossary that might shed some light on where SJ and I got confused:
Typically, when we say “radio,” we mean a telemetry radio or RC system component (usually evident by context).
Typically, when we say “GPS,” we mean GNSS receiver module (like the ArduSimple board).
Rarely do we mean GNSS receiver module when we say “radio.”
But…the community is rife with slightly inaccurate/imprecise terminology…
1 Like
On it…thx for the lift…
Get out your speedo - Just took a pass with the shredder down/back on the runway while system sat as you proposed above. gpsyaw2 in the 655.35 zone.
Were the NTRIP settings appropriate? Should autoconfig be on or Send NTRIP… be off?
From the quick screen:
GPS Track in this pic is the approximate heading of the machine. Other current heading is not accurate:
On glossary - I’m trainable - got it now…
NTRIP appears to be fine and functional. Most checkmark settings don’t really matter except when you have a fixed base directly connected. The “send GGA” setting should probably be checked for most NTRIP applications (leave it the way it is).
Aaaand, NTRIP is immaterial to deriving heading with moving baseline (you could turn off external RTCM3 injects, and heading should still work).
I’m stumped for now. Will reply back when I have some idea of what to try next.
1 Like
Many thanks - happy Friday!
Most recent log wouldn’t hurt.
1 Like
I’m rusty on the subject, but Yuri, if he didn’t have his GPS_POSx_X, Y and Z parameters correct, would he get 65535 or 0?
1 Like
If the gps antennas were switched, that would throw things off.
1 Like
I don’t think it would give the 65535 error, though. I think it would just have his heading 180 deg off.
2 Likes
Correct. Good distance but bad orientation would just result in a non-forward aligned heading.
I think a mis-measured offset would never align and remain at 65535.
Given:
GPS_POS1_X,-0.52
GPS_POS1_Y,0.26
GPS_POS1_Z,0.78
GPS_POS2_X,1.44
GPS_POS2_Y,-0.33
GPS_POS2_Z,0.55
I come up with 2.05m between the two antennas. If they are not that distance apart (or very close to it), that would explain some bad behavior.
Your 114 log does show some occasional glimpses of gpsyaw2, but it mostly remains at an invalid state, which could be indicative of a “struggle” to determine yaw due to poorly calculated position offsets.
I don’t see any changes to the GPS backend or drivers that would impact an update from 4.5.4 to 4.5.5, so I think the timing of the upgrade is coincidental and not causal.
1 Like
The actual distance has to be within 20% of the distance calculated from the GPS_POSxxx parameters, which is 2.05m, per Yuri.
2 Likes
Another possible root cause (as observed in log 114):
This shows an extremely unstable update rate on GPS2. How long is the cable between GPS2 and the autopilot? Does it run alongside a high current/interference source? Or is it possibly a bad cable?
Even GPS1 shows an unstable rate, but it at least averages the 100ms rate that you demanded.
Need to see a log with GPS_RATE_MS* set to 200ms, as well.
By way of comparison, here’s a sample log from my own ArduSimple based moving baseline config, showing near rock solid updates at 5Hz:
A loose antenna connection could also be a culprit.
3 Likes