mocap: add SetVisionSpeedEstimate

[Luc-Meunier]

Hi, we would like to add the VISION_SPEED_ESTIMATE (103) MAVLink message to the mocap proto.

See https://mavlink.io/en/messages/common.html#VISION_SPEED_ESTIMATE

Relates to issue mavlink/MAVSDK#2497

[julianoes]

Thanks for the pull request! Just one question regarding a comment.

[julianoes]

Just wondering on the frame here? When you see "Global" do you mean in North, East, Down, or Forward, Left, Down? I'm pretty sure "Body" would imply in body frame, so Forward, Left, Down.

[Luc-Meunier]

Hi @julianoes! Thanks for the review!

I used the same description as in the MAVLink doc, but I guess this is a typo.

However, I see in the VisionPositionEstimate a similar case:
PositionBody position_body = 2; // Global position (m)
Should I fix it too?

[julianoes]

Interesting. Might be worth checking what PX4 expects and whether we should update the MAVLink messages description.

[julianoes]

For position, PX4 expects NED:

https://github.com/PX4/PX4-Autopilot/blob/1eb9434b8c39fef3691684df520686231dce3939/src/modules/mavlink/mavlink_receiver.cpp#L1319C40-L1322

I don't see vision speed being used in PX4. How are you testing this?

[Luc-Meunier]

Actually, we are currently testing with ArduPilot.
We used Intel RealSense T265 as an example (see https://ardupilot.org/copter/docs/common-vio-tracking-camera.html).

I suggest changing the "Global speed (m/s)" comment to "Body speed (m/s)"

[Luc-Meunier]

Thanks @fed12345 and @julianoes, I added a SpeedNed struct.

[miodine]

Hello,

Just as a quick follow-up to this:

I'm tempted to rename the PositionBody type to PositionNed to make it clear...

To us it also seems like a good idea, should we do it in another PR or would it fly to add it in this one?
Aside from that, is there anything else that we should take care of?

[julianoes]

Thanks, sorry, I'll get back to this asap.

[julianoes]

I looked into it but was very confused by the fact that ArduPilot just handles local and global the same way. That doesn't really make sense to me, but anyway, I think you're right that both handle it NED, and so we should probably rename the field PositionBody to PositionNed.

Ardupilot does not differentiate between local(FRD) and global(NED) frame as it doesn't have a local frame, so it interprets the position in global frame. In fact, it processes the messages VISION_POSITION_ESTIMATE and GLOBAL_VISION_POSITION_ESTIMATE the same way, see here

It would have to differentiate between FRD and NED, as they are not the same! But you are saying it just does NED anyway? I couldn't tell from the code snippet.

[fed12345]

The code snippet only shows that whether ardupilot receives the VISION_POSITION_ESTIMATE or the GLOBAL_VISION_POSITION_ESTIMATE message from Mavlink, it still processes the message with the function handle_common_vision_position_estimate_data, so it doesn't care if it's global or local.

I also agree that this whole thing is confusing. This is how I interpret the frames:

Global: Latitude and longitude, GPS stuff
NED: Origin at initialization of Kalman Filter, yaw aligned with North
Local FRD: Origin at initialization of Kalman Filter, yaw aligned with front of the drone
Body FRD: Origin at cog of drone, yaw aligned with front of the drone

Ardupilot does not have a concept of Local FRD only body FRD.