Proposal for CANDevices Repository
I’d like to make a more concrete proposal for how we can move forward with sensor and device oriented messages that specifically aim to cover the very important use case of a set of sensors on the bus while being robust and efficient.
I propose creating a new CANDevices git repo under github.com/ArduPilot which we will populate with UAVCAN v1 messages for the key devices (at least GNSS, mag, baro, airspeed, rangefinder and likely a few more).
With Pavel’s permission we’d also like a section on this UAVCAN forum to be created specifically for discussion of this CANDevices message set. That gives a common location for discussion between vendors and autopilot stack developers.
Changes to CANDevices would be by pull requests against the CANDevices repo.
Idiom of CANDevices
The messages in CANDevices would be designed to be a regulated message set, and meant to be brought in as a git submodule. The design of the messages would follow the efficient/clear/robust approach I’ve been advocating above. It would not follow the v1 idiom of separate topics for a single logical device (eg. barometer would be one topic containing both pressure and temperature, not two topics). This would be explained in the top level README.md for the repo.
The AP_Periph firmware would implement CANDevices, plus the core UAVCAN v1 message set, along with v0. For boards with sufficient flash selection of v0/v1 will be by parameter allowing for only v0, only v1 or both.
The CANDevices repo will also offer a nice chance for people to point out where I screw up messages for v1, just like I’ve been (very) critical of the DS-015 message set. As I’ve never created a v1 message before it seems likely I’ll make mistakes and I hope we can sort those out on the CANDevices section of the UAVCAN forum.
A Device Class Id
I am also considering having a common uint8 device class ID as the first byte in every message in CANDevices. This is to address a concern I have about the fragility of the UAVCAN v1 subject-id configuration system. There would be a text file in the root of CANDevices where these class IDs are allocated by pull request. The IDs would be high level devices classes, such as “GNSS”, “Barometer”, “Magnetometer”.
The aim of this ID is to allow for mis-configuration detection at the point the data is entering the consuming node. So for example in the ArduPilot code structure, the AP_Compass_UAVCAN.cpp driver would check this field then it gets a message and if it isn’t the right class ID then it would signal a mis-configuration error, prevent arming, and notify the user of the error.
The motivation for this ID is this sort of scenario:
- a user is out at the field about to do an important flight. One of their UAVCAN v1 barometers is misbehaving, and it is causing a pre-arm error.
- the user decides to swap it out, so pulls the misbehaving device off the vehicle and replaces it with one from their box of spares.
- the spare was previously used on a different vehicle, perhaps a vehicle running a different firmware version, it may have even been previously on a copter when they are currently configuring a plane. On that previous vehicle the barometer had been allocated a PnP subject ID which it had stored in its parameters.
- when the spare baro is plugged into the new vehicle it has no idea that it has been sitting in the spares box for 6 months. It has no realtime clock, no battery, so no way of knowing that something might be wrong. It thus immediately takes its subject ID configuration and starts publishing barometer data.
- the subject ID it inherited from the other vehicle happens to be one allocated for an airspeed sensor on this new vehicle.
- as V1 has no indicator in the wire format of what message format the data is, and doesn’t even have a structural checksum like mavlink, the baro data effectively gets “network cast” into differential pressure data by the recipient.
- when the user turns on the vehicle it starts getting garbage for airspeed. The EKF might or might not be able to detect this, especially if it is a backup sensor.
Is there any existing mechanism in V1 that protects against scenarios like this? If so, can someone explain what it is?
Adding a 1 byte sensor class ID at the front of all CANDevices messages seems like a cheap way to auto-detect this type of config error for critical sensors, unless there is some mechanism for robustly detecting mis-configuration that I’ve missed. Note that this 8 bit ID is just another field in a v1 message as far as UAVCAN v1 is concerned. The meaning is given by the conventions of the message set and the table committed into the repo.