GPS Autoconfig with AP_Periph devices over DroneCAN (Here4 Blue)

[Joshua_Kordani]

Here3+ issues after (failed) GPS Yaw attempt

You can probably get rid of any boot delay greater than zero now. I can also confirm that there is likely a bug in the CAN auto configure routine that does indeed affect GPS_AUTOCONFIG=2 and reversion to GPS_TYPE=9 from GPS_TYPE=22 or 23. Bench tested on my own autopilot just now. GitHub issue raised: AP_GPS: DroneCAN GPS_AUTOCONFIG does not revert from moving baseline to standard · Issue #24272 · ArduPilot/ardupilot (github.com)

I was referring to the above conversation thread, which suggests that there were issues related to autoconfig and DroneCAN (although specifically about configuring RTK AP_Periphs, in my case it’s just one AP_Periph and not using RTK).

I’m inferring from that thread that the Here4 should have the configuration of GPS_TYPE=1 in order to allow for the Cube GPS_TYPE=9 and GPS_AUTO_CONFIG=2 to flow the rest of the GPS_ configs down to the Here4? That didn’t seem to be my experience.

I haven’t found much documentation that describes the interactions here, basically this. If there’s somewhere else I should look, besides the code, I’m happy to avoid “Getting too creative”.

Thank you for your response!

Edit: According to this looks like the raw messages aren’t currently passed through, so that answers that question. Still looking for the logic that handles the autoconfig negotiation between the main autopilot and the periph