Homepage GitHub

On subject ID and system model

(Pavel Kirienko) #1

While updating the specification in accordance with the changes we discussed, I decided to take a tiny step back and see whether all other possible approaches have also been considered. After an hour of doodling in my notepad, I arrived at the conclusion that none of the sensible alternatives that come to mind are viable, so I am continuing with the original plan. For the benefit of posterity, I decided to share a brief summary of my reasoning here; this will also serve as a justification for the major design decisions related to the UAVCAN type system.

A new abstraction layer added to the protocol introduces the concept of “Subject” – an entity identifying a stream of messages pertaining to a particular physical process in the system.

Within the new hierarchical system model adopted for UAVCAN (system / physical process / physical quantity / datatype / bit sequence) – which is not strictly enforced anywhere but rather used as an optional mind-crutch for ease of reasoning about the application – a physical process is modeled as a set of varying physical quantities, at least one per process.

Layer Example
System A rotating wheel
Physical process Rotation
Physical quantity uavcan.si.angular_velocity.Timestamped
Datatype float32
Bit sequence 10000101001100001100110011010010

Seeing as a process might require more than one physical quantity to be described, one would be tempted to think (I know I was) that it would be sensible to permit different physical quantities to share the same Subject. A particular quantity within the system would then be identified by a pair of values: Subject ID and some other kind of identifier used to pinpoint the physical quantity within the Subject (i.e. physical process). For example, for a rotating wheel, the same Subject might contain two physical quantities: angular velocity and the angular position of the wheel.

The obvious downside would be that we just added an extra concept out of necessity, requiring two parameters where just one used to be enough. Additionally, consider what happens if there is a need to report multiple parameters of the same physical dimension. For example, imagine that the wheel is equipped with a brake; suppose that it is desired to be aware of the temperature of the braking mechanism and of the tire surface while braking, so the Subject would contain two physical quantities (brake temperature, tire temperature) under the same dimension (kelvin). Now we got ourselves in a bind as we can’t distinguish between the two (a meticulous reader might object that braking could be considered a separate physical process under a separate Subject, thus eliminating the collision; however, the validity of this replacement largely depends on one’s view of the system structure which we don’t want to force, and there exist other examples where such replacement would be less organic).

To work around the above problem, one could go further and add yet another identifier separating physical quantities sharing the same dimension from each other, thus increasing the number of parameters needed to pinpoint a particular physical quantity within the system to three.

From my perspective, the problem would appear to be solved, but at a great cost of additional complexity and an overly strict/opinionated system model. Same results can be achieved using the initially proposed logic, where each physical quantity is referenced by Subject alone, and the mapping between Subject and its quantities is always one-to-one. Provided that the space of Subject identifiers is sufficiently large, the integrator (vendor, application designer, user) can devise custom, arbitrarily sophisticated system models, e.g. requiring that certain ranges of Subject ID are reserved for specific parts of the system (e.g. 100-200 for the left wheel, 200-300 for the right wheel). The advantage is that the specification would be made much simpler and we relieve ourselves from having to make decisions that are better delegated to the user.

(cybermerln) #2

Hi Pavel,
I just took a look at some of the proposed changes for DSDL and read and re-read the messages posted here. To be I am totally lost on what you are expecting and what you will have if anything for any sort of standard messages. In process management I am use to the definitions of system - process - subprocess and measurement points. So can we take a practical measurement that you would normally expect from a UAV.

In the example I am thinking about is an IMU for instance. So lets call this the system which could be defined at accel/gyro/mag combination. I would look at a couple different sets of data from the IMU:

  1. Raw data elements from the sensor (counts directly from the sensor
  2. Calibrated data from the sensor (accel in g’s, gyro’s in rates and magnetometer in uT).
  3. Attitude data from the sensor - yaw, pitch, roll, and heading.

Now you might have multiple IMU’s on the UAV. DSDL messages look like. Reason for the confusion may because I was looking at the GITHUB page on DSDL message which was showing all kinds of stuff like registers, pnp, internet .etc that I got me confused.

Remember I am coming from a user/hobbyist perspective.


(Pavel Kirienko) #3

Raw data elements from the sensor (counts directly from the sensor

This falls out of the scope of UAVCAN. It is a higher-level protocol, not I2C, so low-level sensor data can only be supported in vendor-specific interfaces, not in the standard set. Even in the case of vendor-specific interfaces such low-level entities are strongly discouraged; the specification talks about that by requiring adherence to SI.

Calibrated data from the sensor (accel in g’s, gyro’s in rates and magnetometer in uT).

Acceleration in m/s^2, angular velocity in rad/s, magnetic field strength in T (not uT). There are standard data types for that:

  • uavcan.si.linear_acceleration.Vector3TS
  • uavcan.si.angular_velocity.RollPitchYawTS
  • uavcan.si.magnetic_field_strength.Vector3TS

Estimators normally rely on integrated data, in which case the following data types can be used:

  • uavcan.si.duration.NanosecondTS (integration period)
  • uavcan.si.linear_velocity.Vector3TS or uavcan.si.linear_acceleration.Vector3TS (integrated acceleration samples)
  • uavcan.si.angular_position.RollPitchYawTS or uavcan.si.angular_velocity.RollPitchYawTS (integrated angular velocity samples)

Additionally, covariance data can be reported via uavcan.primitive.ArrayOfReal16. There is a related question which I’m going to raise on GitHub on standard representations of covariance matrices and whether that should be supported in the first release of the standard data type set.

Message streams originating from the same sensor are to be collected and matched together by subscribers with the help of the timestamp fields (the suffix TS means that the message contains a time stamp).

Attitude data from the sensor - yaw, pitch, roll, and heading.

Likewise, uavcan.si.angular_position.RollPitchYawTS.

(cybermerln) #4

Ok. Think I am beginning to understand now. what you are setting up. I was reading this: https://github.com/UAVCAN/dsdl/tree/v1-standard-data-types and got my self confused.