We need to express units in the types somewhere. I had it where you put “value”. Are you opposed to this
I am not opposed to that, even though it seems a bit redundant, since it is already stated that all units are according to the SI. So if a type is defined under uavcan.si.energy.Scalar, it is clear that we mean joules. Being redundant here is not necessarily a very bad thing though.
Should the unit of measurement be used in its plural form or singular? float32 joule or float32 joules?
Alternatively we could require that the type be aliased to a set of si units (derived or otherwise) so we would have something like
Seems too complicated. Let’s go with the first suggestion.
Where this breaks down is if we have heterogeneous types that are components of a quantity. Does such a thing exist or does such a thing imply a thing too complex to be part of this namespace?
I see now that by adding spherical coordinates and such, we are trying to fit too much semantics into the SI namespace. Perhaps, indeed, it is best to leave higher level concepts out of it, in which case simple Scalar and VectorN would be enough, except that we’ll also need higher-precision options for those. For example, how do we represent a vector of float64? WideVectorN? Something else?
Higher-level heterogeneous quantities are definitely needed; the question is, though, whether they are needed in UAVCAN v1.0, or can they wait until UAVCAN v1.1. I am currently mildly inclined towards the latter option. Those would include global positioning data (“global” as in “pertaining to a nearly-spherical celestial body”: longitude, latitude, elevation, etc.), spatial location (position, orientation, velocities), electrical circuit status (voltage and current), inertial readings (acceleration and angular velocities, also integrated), and so on. I don’t feel confident enough in my understanding of the topic to commence any sensible work on it yet.