I’ve been having an in-depth discussion with Pavel about the future of v1 and DS-015 in ArduPilot. While the discussion has been useful, I think it a wider technical audience is worthwhile.
First the good news. From my point of view as systems lead for ArduPilot I see two big advantages of UAVCAN v1:
- supporting FDCAN, so that in the future we can get more bandwidth (higher bitrates and larger frames)
- the ability to extend messages as requirements change to add new fields without duplicating a message (so hopefully we don’t get things like the mess we have now with “Fix”, “Fix2”, “Auxiliary”, “Status” (all sent by current GNSS v0 nodes).
Along with that good news there is some bad:
- as far as I know, nobody has demonstrated correct operation of a mixed network of v0 and v1 on the same CAN bus with a rich set of v0 messages. This must be demonstrated for v1 to have any chance of wide adoption. I’d appreciate it if anyone can point me to such a demonstration if it has actually been done.
- the message set in DS-015 is in my opinion not fit for purpose. It is in fact a complete mess.
The main focus of the discussions between Pavel and myself has been around DS-015, and it is the philosophy behind the design DS-015 that is the core problem. This description from Pavel sums up the philosophy:
You would notice that providing accurate modeling of each sensor kind is,
in fact, an anti-goal, which is why there is no dedicated message, say, for a
GNSS fix, magnetometer, or lidar. DS-015 takes a higher-level approach,
modeling physical processes and entire subsystems instead of particular
kinds of hardware. Under this model, the autopilot is not intended to be
the central piece of the onboard intelligence, but rather yet another agent of the
distributed computing system. The objective of this design is to enable
composable systems where new, complex behaviors can emerge from a
combination of simple and robust components, instead of aggregating the
entire intelligence in a single complex unit (being, in this case, the ArduPilot).
To me, the idea of new complex behaviors emerging from the design makes me want to run away from this as fast as I can. I want predictable behavior from the network, not emergent behavior. This is not some academic exercise we’re we are trying to get a paper in a journal. ArduPilot is depended on by a huge community of users, from hobbyists to companies flying multi-million dollar aircraft carrying payloads of a ton or more.
Beyond the high level philosophy is a much deeper problem where this design concept has driven the message design in ways that make it completely unworkable. Some of this philosophy driven poor design was present in v0 as well, but in v1 it has grown much more pervasive.
To explain the issues a simple example is useful. Pavel and I hit upon the representation of airspeed in DS-015 as simple example of our key difference of opinion, so I’ll use that here.
This is the DS-015 airspeed message:
Airspeed is also used in the top level README.md as an example of the design philosophy:
In UAVCAN v0 airspeed is represented with the RawAirData message. I’ve never liked that message, as it has a whole lot of useless fluff in it. The only useful fields in RawAirData are the differential_pressure and the static_air_temperature. All the others are just wasted bandwidth.
I was absolutely stunned to see that in v1 the design philosophy has resulted in the removal of the differential pressure. No amount of philosophy or “emergent behaviour” can justify that.
As explained in the v1 README, the reason for this is v1 wants the “air data computer” to be smart and to know how to turn the differential pressure into a CAS (calibrated airspeed). The sensor itself is supposed to know about all the effects that go into creating a useful CAS. That would be a disaster.
The key problems are:
- we absolutely need to know the differential pressure to analyse flight logs properly. It will be rare for an airspeed sensor to have logging, and even if it did have logging the burden of aggregating logs from a dozen different UAVCAN sensors into a single usage log set would be prohibitive.
- we use a small EKF to automatically calibrate airspeed sensors in ArduPilot. We certainly don’t want to duplicate that EKF code on the airspeed sensor node, and we want the detailed logging of the operation of that EKF to be embedded in the main flight log. The most common UAVCAN airspeed sensors for ArduPilot are based on a STM32F1 and F3, which have neither the processing power nor the flash space to run a suitable EKF, quite apart from the development, testing and update nightmare of getting this deployed.
- users commonly don’t even know which port on pitot is static and which is dynamic pressure. They see two identical tubes and connect them. ArduPilot lets them do that and we sort it out inside the autopilot. It cannot be robustly sorted out inside the sensor itself.
I spend a lot of time analyzing flight logs, and this is a common type of graph (off my NanoTalon from a flight yesterday)
here I am checking the calibration of the airspeed sensor by scaling the GPS speed by EAS/TAS ratio and comparing to a simplified form of the airspeed equation from differential pressure. I can’t do that type of analysis if I don’t get the differential pressure in the log.
Those of you who know about airspeed sensors may be thinking at this point that some airspeed sensors don’t work via a differential pressure so sending a differential pressure is silly. I am well aware of that, for example the SDP3X does not have a differential pressure to send, and instead is a type of “flow” sensor. In that case we should send the data that it does have as a separate message designed for this type of sensor. The SDP3X is actually an interesting case as you can’t calculate an airspeed without knowing the current pressure altitude (or more specifically outside air pressure rho). Under the DS-015 design philosophy the SDP3X based sensor would listen on the network for someone else to give it the air pressure. That completely misses the fact that it is common that there are multiple barometers on the aircraft, and the SDP3X based sensor has no way of knowing which one to use. On my little NanoTalon I have 3 barometers. Some aircraft have more than that. To job of choosing which one is the best choice needs to be made by the main autopilot, which has all the other sensors available to it and can see which barometer is most consistent with the full set of sensors.
It is also absolutely critical that deploying UAVCAN be as easy as we can possibly make it. We’ve been working very hard to make UAVCAN viable for as many people in our community as we can. That involves ensuring that you can buy a UAVCAN airspeed sensor (like this one) plug it in and immediately be able to use it, just like if you plugged in an I2C sensor, but with all of the nice bus properties of CAN. Under Pavels model you would need to do a pile of configuration of the sensor before you could use it, and even after doing that you’d end up with a less useful sensor than you’d get with I2C. Adopting this design approach will undo much of the hard won gains we’ve made in UAVCAN adoption.
Now you may be thinking this is just about a silly approach to airspeed in DS-015, but it isn’t. The same poor design choices for airspeed are right throughout the DS-015 message set. Everything in DS-015 is made subservient to the design philosophy, rendering the entire message set not fit for purpose.
So what to do? We have to drop DS-015. Instead we should create a message set that contains the information we actually need for robust UAS.
For the simple example of an airspeed sensor based around differential pressure it should contain differential pressure and temperature. That is it. It should not have a covariance matrix (the use of piles of covariance matrices in v0 and v1 is one of the worst aspects of the design). It should not try to provide a calibrated airspeed reading.
If you have a true air data computer like is common in manned aviation then that should be a separate message. That is likely to remain very rare in small UAS, but as ArduPilot is used on more complex aircraft then it will happen. In that case we should have a separate CalibratedAirspeed message. We should not try to fake up this message if the sensor has no reasonable way to provide the data in a robust manner.
The UAVCAN message set needs to be a robust transport of accurate data from the sensors which take measurements to the nodes that need those measurements. It should not make stuff up in order to fit into a broken philosophical mold.
The ArduPilot dev team is happy to create this sane message set. I hope that everyone will understand why it is necessary, and why adopting DS-015 would be a great disservice to our community.