Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Format proposal, with covariance as an example #27

Open
David-OConnor opened this issue May 22, 2023 · 0 comments
Open

Format proposal, with covariance as an example #27

David-OConnor opened this issue May 22, 2023 · 0 comments

Comments

@David-OConnor
Copy link

David-OConnor commented May 22, 2023

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:

image

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant