Quick disclaimer - I work for Trimble but not in this division. I’m posting this because I found it interesting and believe others in the community will too.
Hi Mal, I am working on updating ArduPilot’s GSOF driver. I have been working with Applanix to support the BD940-INS as well as the PX1 RTX.
I’ve already sone some refactor the AP_GPS_GSOF driver, and plan to add more support soon. Applanix has agreed to ship me a unit to develop against.
Here’s the list of currently merged work, which is all refactor (non-functional changes)
Currently, I am working on adding a simulator for GSOF. The purpose is to use SITL to ensure the changes and refactor work to the driver does not introduce regressions. Then, it will be more safe to introduce features. I plan to start out by increasing support for using it as a precise GPS. For example, using the covariance estimates instead of just HDOP/VDOP.
After that, the next phase would be to use it as an “external AHRS” for ArduPilot.
If you had any specific requests for support, I am happy to discuss them here.
We got the current (merged) driver working with the old messages treating the PX1 as a simple GPS, like the BD930. The default configuration hard-coded in the autopilot sets the serial output on COM1 (RS232), while COM2 is TTL. We will need to make a parameter to expose that interface.
This PR now exposes the desired baud rate through an ArduPilot parameter. Default is preserved at 115k, however 230k is now supported for decreased latency on platforms that allow it.
It also fixes the default ports that GSOF is enabled. Now, GSOF data output is hard coded to COM2, as that is the only TTL level serial port available for GSOF on the PX1. This would be connected directly to the TELEM port on your autopilot. In the future, this could be exposed in the following param: https://ardupilot.org/plane/docs/parameters.html#gps-com-port-gps-physical-com-port
In the future, parameters can be exposed to support the planned ethernet support in ArduPilot.
