mocap: wire up reset_counter, estimator_type, quality fields

[alireza787b]

Problem

The Mocap plugin hardcodes several fields when packing MAVLink messages,
ignoring values that PX4's EKF2 can use for better sensor fusion:

send_vision_position_estimate:

0); // FIXME: reset_counter not set   ← line 119

send_vision_speed_estimate:

0); // FIXME: reset_counter not set   ← line 170

send_odometry:

0,                        // reset_counter hardcoded
MAV_ESTIMATOR_TYPE_MOCAP, // estimator_type hardcoded (wrong for VIO users)
0);                       // quality hardcoded

Additionally, static_cast<uint8_t>(odometry.frame_id) sends the proto enum
value (0) instead of the MAVLink value (14 = MAV_FRAME_MOCAP_NED), because
the proto enum uses sequential values rather than MAVLink values.

Changes

1. Wire up reset_counter in send_vision_position_estimate — resolves
   the FIXME comment

2. Wire up reset_counter in send_vision_speed_estimate — resolves
   the FIXME comment

3. Wire up reset_counter, estimator_type, quality in send_odometry
   — replaces all three hardcoded values with the proto fields

4. Fix frame_id mapping — add switch to map proto MavFrame enum values
   to correct MAVLink MAV_FRAME constants (14 for MOCAP_NED, 20 for LOCAL_FRD)

5. Backward compatibility — when estimator_type is UNKNOWN (proto3 default),
   fall back to MAV_ESTIMATOR_TYPE_MOCAP to preserve existing behavior

Dependencies

• Requires mocap: add reset_counter, quality, estimator_type to odometry messages MAVSDK-Proto#395 (adds the new proto fields)
• Proto submodule update needed after that PR merges, then run
  tools/generate_from_protos.sh to regenerate auto-generated code

Related PRs

• Proto fields: mocap: add reset_counter, quality, estimator_type to odometry messages MAVSDK-Proto#395 — adds reset_counter, estimator_type, quality to proto
• MavFrame fix: mocap: fix MavFrame enum values to match MAVLink specification MAVSDK-Proto#396 — fixes proto enum values to match MAVLink (once merged, the switch mapping here can be simplified to a direct cast)
• Python example: examples: add vision odometry example MAVSDK-Python#820 — vision odometry example

Testing

After proto submodule update:

cmake -Bbuild/default -S. -DBUILD_MAVSDK_SERVER=ON -DWERROR=ON
cmake --build build/default -j$(nproc)

Verified: all changes maintain backward compatibility — existing users who
don't set the new fields get identical MAVLink output (reset_counter=0,
estimator_type=MOCAP, quality=0, frame_id=MOCAP_NED).

[alireza787b]

Hi — just a note that the CI failures here are expected: this PR references reset_counter, estimator_type, and quality_percent fields that were added in MAVSDK-Proto PR #395, which hasn't been merged yet.

Once #395 is merged and the proto submodule pointer is updated, the build should pass.

Dependency chain:

1. MAVSDK-Proto fly_qgc_mission: link to json11 #395 (merge) → update proto submodule in MAVSDK → this PR's CI passes
2. Then MAVSDK-Python Trying out GitLab CI #820 can use the new fields

Happy to rebase or address anything else in the meantime.

[julianoes]

I tried to merge this and it didn't compile, see comment mavlink/MAVSDK-Proto#395 (comment).

[alireza787b]

Hey Juliano, you are right. This branch is stale in its current form and the old dependency assumption was not enough. I re-checked the proto/C++/generation path end-to-end and I would rather replace this with clean current-main PRs than keep patching stale history here. I will prepare a small fresh MAVSDK-Proto PR first, then a regenerated MAVSDK follow-up that keeps the frame mapping in C++. Very happy to align with any suggestion on that split if you prefer a different sequencing.

[julianoes]

I've merged proto, you can now fix this up.

[julianoes]

@alireza787b I've rebased this and fixed it up. Hopefully that works for you like that. I want to get this into the next v3 release, so I went ahead.