First draft of the UDRAL DSDL namespace

[auturgy (James)]

Re WIP / versioning. WIP messages in mavlink were explicitly tagged as WIP in the xml. Didn’t stop people deploying them. I understand the intent to make prototyping easier, but we also need to protect users as much as we can. Any dev can build off a development branch, which in my view is a safer approach. Perhaps we could ask the SIG/consortium?

Re specific points, if you’d prefer I copy them in here, sure:

@coder_kalyan

Pavel:

• UAVCANv1 is a is intended to be decentralized and composable. This allows for future proofing and makes further expansion easier to accomplish by making less assumptions and focusing on a less holistic (and therefore limited by the human mind) view of the system.

Andrew: why is composability useful?

Pavel: Not useful for the user of the vehicle, but

Andrew: This seems to be accomplishable with versions. I am yet to see an actual end user benefit to the integrator. This level of decentralization has costs:

• performance/bandwidth
• complexity
• robustness
• integrator headache

What is wrong with creating messages per use case?

Pavel: This encourages designing of extremely specific messages that have limited scope for use.

Andrew: Here’s an example regarding node temperature: different temperatures have very different use cases. Having reusable types loses the association between, say, an IMU device and its temperature.

Andrew: Still doesn’t seem to be a tangible benefit. For current use cases, we need a robust sensor network that is simple, robust, and efficient. The service oriented distributed architecture is not compatible with that, and I don’t like that. Details about different sensors are also lost through this mechanism

Scott: What about the problem of too much centralization caused by flight controller-centric autoconfiguration?

Pavel: Not really a problem as high integrity environments that care should be manually configured either way.

Scott: I am also unable to see the benefits at the application layer - why not go in steps, start with the transport layer benefits of v1 and keep something that is easier to understand?

Andrew: By cleaning up the v0 junk, we won’t actually use a lot of IDs - why not reserve a few for standard sensor messages?

Pavel: I am not worried about running out of IDs or conflicts. It’s instead the question of hard associating the data type contents with its semantics (how it’s used). A range of IDs is a possible solution for type safety.

@dagar

Can we find something in between those extremes combining the type safety and simplicity we enjoy with current UAVCAN with respecting the UAVCANv1 interface guidelines (no fixed port IDs, etc)? It seems to me for the majority of the usage we actually need we should be discussing things at the level of a simple directory of subjects (mapping to data types).

Simple map of subject name to type

• port id would come from a known register naming convention using the subject name
• resolves type safety issues
• port id could even have acceptable defaults in many cases (I know this might be contentious)
• code generators could directly consume this and produce libuavcan style Publisher and Subscriber helpers that have things like the port id from register part handled automatically
• this could be extending the existing services idea, but digestible by tooling, and probably the goal of each service being much simpler/coherent at least at the start

@pavel.kirienko

This is fine in general but I think it would save much effort to you and other participants if we first agreed on what exactly we are building before actually starting the work. This requires that the technical requirements are put forth and agreed upon. Can you please briefly describe what are you trying to achieve before publishing any definitions? Otherwise, we are risking facing two negative consequences:

• Psychological anchoring might make the group reluctant to accept competitive design goals once an implementation proposal is already in place.
• The discussion may become less organized as core goals will be discussed alongside minute technicalities of the implementation.

@coder_kalyan

Nesting can be useful, but too much nesting (as seen in DS-015) causes unnecessary complexity, overhead, and developer headaches. Please, let us try to non-rigidly constrain the amount of nesting.

@coder_kalyan

Before he left, @scottdixon suggested that we shelve the port ID problem to later and focus on the stuff that we do agree on. While this is a noble idea, it was decided that this is not a good idea because problems such as the message contents are trivial to solve, while these larger architectural values need to be figured out if we want to move forward at all.

Andrew wants tangible benefits to the end user in order to counteract the increased complexity and decreased efficiency of V1. Without that, there doesn’t seem to be any point. He also noted that the transport layer improvements of V1 (CAN-FD and packet extensions/versioning) are very useful, but he doesn’t see the benefits of the V1 application layer ideology.

Pavel expressed that he is very concerned that the applications of UAVCAN in the long run will exceed the capabilities of a rigid application layer. The upfront cost of a more complex application layer specification may be outweighed by future proofing the protocol. This is the primary basis for @pavel.kirienko’s viewpoint on the subject.

Andrew TridgelltridgeUAVCAN Consortium member representative

May 4

@dagar

I propose we add services for handling these simple sensor types, and leave things like “air_data_computer” as aspirational examples

yes, we should have simple ones that just reflect the real data. I don’t think we should add the “air_data_computer” unless there is going to be real hardware that will really be used that needs it.

It would also be nice to make the covariances optional in these messages.

we should just stop using covariance matrices. It just encourages developers to make up meaningless numbers. We shouldn’t be wasting bandwidth on stuff that is just made up.
A few guiding principles in message design:

• don’t add fields unless there is a real need for them
• don’t add fields that force the developer to make stuff up that they don’t really know

@dagar

For reference, here’s what an earlier version of DS-015 had for differential pressure.

closer, but should remove a bunch of fields.

• I don’t think the timestamp really has value on this message. Timestamps have enormous value on messages like GNSS position and velocity, but on differential pressure used for airspeed I don’t think it is useful. The time of arrival is fine.
• remove both filter_delay and the filtered differential pressure. It would only make sense if we were greatly reducing the sample rate on the bus and I don’t think we are likely to be doing that.
• get rid of the variance, as the sensor is unlikely to really have a good measure of that
• only have one temperature

We should aim to get it down to a single CAN frame if possible.

The nice thing about UAVCANv1 is you don’t need the service to start or do something custom, you can directly publish a dynamic pressure ( reg.drone.physics.thermodynamics.PressureTempVarTs ) on your own subject

but that doesn’t tell you what this reading actually is. It just says it is a difference between two pressures and a temperature (plus a pointless timestamp and covariance). We need it to be broadcast in a form that says “this is from a pitot tube, if you want to get a pitot based airspeed you can use this”.

To summarise, this PR does not address the fundamental problem:

@auturgy

The bulk of the call was basically to-ing and fro-ing about “how do we use an architecture designed for high level distributed computing as a low level sensor network”.

Vadim has attempted to address the port identification/type safety issues, but the other significant rub points are untouched.
The DS-015/UDRAL messages assume high level functionality in each node, and this simply isn’t the reality for most of the systems that currently use UAVCAN. For some nodes, such as actuators or gimbals, this level of abstraction can be made to work. For many sensors, such as GNSS and other low level devices, it can’t without introducing risk. It is not reasonable to expect that this can be overcome by a one-off configuration by the integrator, or by transferring complexity to another system (ie the autopilot).
Developing a standard based on an idealised expectation of some future reality doesn’t make sense. Having the scope/flexibility within the standard to adapt to a future state is important, but for the standard to have any chance at success it needs to also be able to functionally replace v0 (particularly given that you’ve deprecated v0).
The reality is that if UAVCANv1/UDRAL doesn’t achieve that, it fails. With what you’ve presented here, it fails.