Autopilot: OSD waypoint elements, CLI mission status, MAVLink SET_CURRENT - #15416

docs/flight_plan.md (1)

51-59: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Specify a language for the fenced code block.

To resolve Markdown linting warnings and improve rendering, consider specifying text as the language for this CLI code block.

📝 Proposed fix

-```
+```text
 waypoint list
 waypoint status
 waypoint insert <idx> <lat.ddddddd> <lon.ddddddd> <alt_cm> <spd_cms> <type> <dur_ds> <pattern>
 waypoint update <idx> <lat.ddddddd> <lon.ddddddd> <alt_cm> <spd_cms> <type> <dur_ds> <pattern>
 waypoint remove <idx>
 waypoint clear
 save

</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @docs/flight_plan.md around lines 51 - 59, Specify text as the language for
the fenced CLI command block containing the waypoint commands and save
instruction, changing the opening fence from an unannotated fence to a
text-language fence while preserving its contents.

</details>

<!-- cr-comment:v1:2a19fb97b3c610b0fb6e5f23 -->

_Source: Linters/SAST tools_

</blockquote></details>
<details>
<summary>src/test/unit/telemetry_mavlink_mission_unittest.cc (1)</summary><blockquote>

`225-227`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_

**Positional struct literals for `flightPlanWaypoint_t` are fragile.**

`plan->waypoints[N] = { ... }` relies on 7 unnamed fields matching the struct's exact declaration order; a future field reorder in the struct definition would silently misassign values without a compile error. Designated initializers would make this self-documenting and reorder-safe.

<details>
<summary>♻️ Optional refactor using designated initializers</summary>

```diff
-    plan->waypoints[0] = { 100, 200, 1200, 0, 0, WAYPOINT_TYPE_TAKEOFF, WAYPOINT_PATTERN_NONE };
-    plan->waypoints[1] = { 300, 400, 2000, 0, 300 /* 30 s */, WAYPOINT_TYPE_HOLD, WAYPOINT_PATTERN_ORBIT };
-    plan->waypoints[2] = { 500, 600, 0, 0, 0, WAYPOINT_TYPE_LAND, WAYPOINT_PATTERN_NONE };
+    plan->waypoints[0] = { .latitude = 100, .longitude = 200, .altitude = 1200, .type = WAYPOINT_TYPE_TAKEOFF, .pattern = WAYPOINT_PATTERN_NONE };
+    plan->waypoints[1] = { .latitude = 300, .longitude = 400, .altitude = 2000, .duration = 300 /* 30 s */, .type = WAYPOINT_TYPE_HOLD, .pattern = WAYPOINT_PATTERN_ORBIT };
+    plan->waypoints[2] = { .latitude = 500, .longitude = 600, .type = WAYPOINT_TYPE_LAND, .pattern = WAYPOINT_PATTERN_NONE };

(Field names above are guesses — adjust to match the actual flightPlanWaypoint_t member names.)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/test/unit/telemetry_mavlink_mission_unittest.cc` around lines 225 - 227,
Replace the positional initializers assigned to plan->waypoints[0],
plan->waypoints[1], and plan->waypoints[2] with designated initializers using
the actual flightPlanWaypoint_t member names. Preserve all existing values and
comments while making each assignment independent of struct declaration order.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/main/flight/flight_plan_nav.c (1)

1074-1087: ⚠️ Potential issue | 🟡 Minor

Dimensional mismatch in ETA calculation.

The ETA calculation divides distanceToNavTargetM(est) (which evaluates to a 3D slant distance when the command includes altitude) by a strictly 2D horizontal speed. For waypoints involving steep climbs or descents, this dimensional mismatch will drastically overestimate the ETA.

Consider calculating a strictly 2D horizontal distance to divide by the 2D horizontal speed.

💡 Proposed fix

 uint16_t flightPlanNavGetEtaSeconds(void)
 {
     if (!fp.active || !positionNavHasActiveTarget()) {
         return 0;
     }
     const positionEstimate3d_t *est = positionEstimatorGetEstimate();
     const float speedMps = sqrtf(sq(est->velocity.v[ENU_E]) + sq(est->velocity.v[ENU_N])) * 0.01f;
     if (speedMps < 0.5f) {
         return 0;
     }
-    const float etaS = distanceToNavTargetM(est) / speedMps;
+    vector3_t deltaM;
+    navTargetDeltaEnuM(est, &deltaM);
+    const float distance2dM = sqrtf(sq(deltaM.v[ENU_E]) + sq(deltaM.v[ENU_N]));
+    const float etaS = distance2dM / speedMps;
     return (etaS >= (float)UINT16_MAX) ? UINT16_MAX : (uint16_t)lrintf(etaS);
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/main/flight/flight_plan_nav.c` around lines 1074 - 1087, Update
flightPlanNavGetEtaSeconds to calculate ETA using a strictly 2D horizontal
distance that matches the existing ENU horizontal speed, rather than
distanceToNavTargetM(est) when altitude contributes a slant distance. Preserve
the current inactive-target, low-speed, saturation, and rounding behavior.