-
Notifications
You must be signed in to change notification settings - Fork 1
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
add first version of gnns #1
base: main
Are you sure you want to change the base?
Conversation
I will create a similar PR for ESC, taking into account the notes from the forum discussion. |
|
||
ds015.physics.geodetic.Point.0.1 point | ||
uavcan.si.unit.velocity.Vector3.1.0 velocity | ||
uavcan.si.unit.angle.Scalar.1.0 yaw |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
heading accuracy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heading accuracy is just a little lower, it is called yaw_accuracy
.
I've added RelativePosition.0.1 dsdl. We can send it if it is available as a separate message. Is it what you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes sending it separately (when available) makes sense.
I've added fields for jamming and spoofing based on what PX4 has in the Status.0.1 that is part of the general Gnss.0.1 data type. Gnss message is 59 bytes now, but still 9 CAN-frames. |
Could we consider sending the covariance in a separate message? ublox sends the covariance as a separate message anyway, it doesn't matter where we combine all the data together (on the node side or on the autopilot side). |
Yes that makes sense, packing it together atomically is a bit of a lie. |
bb915c2
to
176c8d8
Compare
GNSS
I want to propose a new interface for GNSS instead of the existing one in UDRAL. Here I've tried to fix as many of Andrew Tridgell's notes as possible, taking into account the red lines marked by Pavel Kirienko. I also tried to pay attention to the performance and the bandwidth issue.
1. Andrew proposal
Based on Andrew Tridgell's suggestion we have the following structure:
As I understand the suggested structure is mostly based on AP_GPS/GPS_State. By the way, this is what PX4 has.
It is 56 bytes long (9 CAN-frames in Cyphal).
It is pretty rigid interface, but it was pointed out that it is really important for ArduPilot to parse the all the necessary for EKF data at once.
In Cyphal we don't need to have an instance id and it is expected to use SI.
2. Existing Cyphal GNSS
The current GNSS implementation in the custom ArduPilot branch is just a minimal implementation to make it work.
It is based on something I found in an old DS-015 discussion. I did not consider it to be a finished GNSS interface, and I agree that it is not optimal at all.
Now it is divided into 5 messages:
All these messages together are 94 bytes long or 15 CAN-frames. And it is missing lots of absolutely critical information.
3. Proposal
Let's just convert what Andrew suggested with respect to SI and remove the instance ID.
I've extended the suggested status with mode and sub_mode that we have in DroneCAN and packed it into the
Status
message.I've optimized physics.geodetic.Point.0.1 to have float32 for altitude instead of float64.
It seems to be that ground_speed and ground_course are redundant because we already have velocity, so I've removed them.
As a result, we get a 58 byte message, which is exactly the same number of CAN frames as in the original message.
Please, check Gnss.0.1 for details.
4. Alternatives
ArduPilot uses 4 variables for speed, horizontal, vertical and yaw accuracy. PX4 does the same. Should we consider using the triangular covariance matrix or these 4 variables suit us?
Can we consider combining
uint32 time_week_ms
anduint16 time_week
into a singleuint48 time_week_ms
? Or should we put it into a separated message with 2 fields. Is TOW better than UTC or TAI?5. Further work
I'm assuming that RTK, MovingBaseline and other features could be further extended as separate messages.