Currently, implementation of DSDL types if often complicated. The causes manifest in these related ways:
Bit-level alignment
Strings used as enums
Variable field sizes
Variable message sizes
Non-constant, and/or non-documented indexes.
This makes writing firmware to read from or write to DroneCAN devices more complicated than for other common communications protocols. I recommend something like this instead. This is from the UBLOX M10 interface description:
Note that it uses byte-level alignment, an explicit length, and explicit indexes. It lists the fields in a standard format, without mixing enums, comments, and fields. This is substantially easier to code for than DroneCAN messages. I propose considering something like this for future messages, and adding new messages for existing functionality that uses something like this. This specific example could be used as a replacement for this in the Fix2 message:
#
# Precision
#
float16[<=36] covariance # Position and velocity covariance. Units are
# m^2 for position, (m/s)^2 for velocity and
# m^2/s for position/velocity.
float16 pdop
#
# Position and velocity solution in ECEF, if available
#
ECEFPositionVelocity[<=1] ecef_position_velocity
Note how this, from the DSDL uses bit-level alignment due to its length field, changes the index of future values, and is effectively useless for describing what values go in it.
Currently, implementation of DSDL types if often complicated. The causes manifest in these related ways:
This makes writing firmware to read from or write to DroneCAN devices more complicated than for other common communications protocols. I recommend something like this instead. This is from the UBLOX M10 interface description:
Note that it uses byte-level alignment, an explicit length, and explicit indexes. It lists the fields in a standard format, without mixing enums, comments, and fields. This is substantially easier to code for than DroneCAN messages. I propose considering something like this for future messages, and adding new messages for existing functionality that uses something like this. This specific example could be used as a replacement for this in the Fix2 message:
Note how this, from the DSDL uses bit-level alignment due to its length field, changes the index of future values, and is effectively useless for describing what values go in it.