Trimble PX-1 GNSS-RTX-INS External AHRS
Purpose
Add support for Trimble PX-1 GNSS-RTX-INS External AHRS.
Testing Performed
I flew this on a copter with Ublox on GPS1, PX-1 as GPS2 and verified all EAHRS and GPS fields are in alignment in the dataflash logs.
- BIN Log 00000011.zip - standard This flies off the UBX, but has the PX-1 EAHRS configured as GPS2. BIN Log 13 - replay, with T04 sent to Trimble for analysis. Same as above but with LOG_REPLAY=1 and LOG_DISARMED=1
- BIN Log 15 This time, GPS_PRIMARY was set to GPS2 and I flew off it.
Roll and Pitch
Alt
A few meters is expected given the PX-1 has the full resolution EGM-96 grid, but it's also smoother.
Lat/Lon
Vertical Velocity against Altitude
The EAHRS altitude does not change at the rate that it reports the velocity, but overall tracks
Horizontal Velocities
Ticket
Closes #27033
Disclaimer
Packet parsing and particular the HAL logger calls were written with ChatGTP and (quickly) validated. There may be issues with some BIN log data, but what I've checked so far seems to be sane.
Follow Up
- I have not flown off the EAHRS solution yet, but plan to after the code has been reviewed and we verify replay works.
- Add error thresholds for healthy filter
- Refactor the existing GPS_GSOF simulator to also simulate the EAHRS
- set the nav_filter_status fields
- estimate lag with this tool
There are still comments on here that haven't been addressed, and it would be nice if more things in the CI suite passed :-)
Need to fix logger metadata. https://github.com/ArduPilot/ardupilot/actions/runs/19197230527/job/54879964205?pr=30232#step:4:93
LoggerDocumentation (Test Onboard Logging Generation) (Command '['/__w/ardupilot/ardupilot/Tools/autotest/logger_metadata/parse.py', '--vehicle', 'Tracker'
Unknown field ( // 0=GPS_ONLY
)
Which is observed in
// @LoggerMessage: GSN1
// @Description: GSOF49 Full INS Navigation Solution 1
// @Field: TimeUS: Time since system startup [µs]
// @Field: GpsWeek: GPS week number since Jan 1980
// @Field: GpsTimeMs: GPS time of week [ms]
// @Field: ImuStat: IMU alignment status (enum)
// 0=GPS_ONLY
// 1=COARSE_LEVELING
// 2=DEGRADED
// 3=ALIGNED
// 4=FULL_NAV
Bitfields are not documented in AP_Logger/README.md
Need to fix logger metadata. https://github.com/ArduPilot/ardupilot/actions/runs/19197230527/job/54879964205?pr=30232#step:4:93
LoggerDocumentation (Test Onboard Logging Generation) (Command '['/__w/ardupilot/ardupilot/Tools/autotest/logger_metadata/parse.py', '--vehicle', 'Tracker'Unknown field ( // 0=GPS_ONLY )Which is observed in
// @LoggerMessage: GSN1 // @Description: GSOF49 Full INS Navigation Solution 1 // @Field: TimeUS: Time since system startup [µs] // @Field: GpsWeek: GPS week number since Jan 1980 // @Field: GpsTimeMs: GPS time of week [ms] // @Field: ImuStat: IMU alignment status (enum) // 0=GPS_ONLY // 1=COARSE_LEVELING // 2=DEGRADED // 3=ALIGNED // 4=FULL_NAVBitfields are not documented in AP_Logger/README.md
Fixed! Since we don't use these enums yet, I just log the raw values for now.
Can we document the return value? UARTDriver.h does not say that 0 is a failure.
0 is not failure - it really is \0. ->read() returns int16_t and you have to check for -1 before using the value. Which many places to not, thus my goal of removing the damned call :-)
Bitfields are not documented in AP_Logger/README.md
The parameter documentation in general is not documented in there.
@Ryanf55 are we using https://receiverhelp.trimble.com/oem-gnss/gsof-messages-code-position-llh.html ? that looks like the GNSS solution also, does the receiver have a way to ask it to stop fusing GNSS? that would be what we would use to test it
some todo for trimble, none of this is required for this PR, but nice for the future:
- add a protocol element to disable use of GNSS for testing purposes
- add protocol packet for GNSS solution that doesn't involve IMU or mag
- add protocol packet for mag field