MAVLink stream control, protocol replies, and telemetry detail#11715
MAVLink stream control, protocol replies, and telemetry detail#11715xznhj8129 wants to merge 6 commits into
Conversation
Modularize the monolithic telemetry/mavlink.c into src/main/mavlink/ (runtime, ports, streams, routing, modes, command, guided) plus fc/fc_mavlink.c for FC-facing dispatch, leaving telemetry/mavlink.c as a thin adapter. - Up to MAX_MAVLINK_PORTS (4) concurrent MAVLink ports with per-port runtime state and per-port mavlink_portN_* settings - ArduPilot-style route learning ((sysid,compid) -> ingress port), targeted forwarding, broadcast fan-out, fixed local identity MAV_COMP_ID_AUTOPILOT1 - Half-duplex TX backoff on shared serialrx_halfduplex MAVLink RX ports - mLRS radio link stats/information/flow-control handling per port - HIGH_LATENCY2 service with per-port high_latency setting and MAV_CMD_CONTROL_HIGH_LATENCY - Bounded RX work per scheduler invocation (MAVLINK_RX_BYTE_BUDGET) - MAVLink moved behind the MCU_FLASH_SIZE > 512 gate Incoming message surface otherwise matches the previous single-port implementation (COMMAND_INT DO_REPOSITION / DO_CHANGE_ALTITUDE, RC override, RADIO_STATUS, ADSB, param stub, heartbeat), now also accepted via COMMAND_LONG. MAVLink mission protocol is intentionally absent at this point in the stack and returns rewritten as a transfer state machine in a later PR; merge only as part of the stack.
Core slice of the full mavlink_multiport2 test suite: routing identity, RC override forwarding, mLRS link handling, RADIO_STATUS flow control, telemetry payloads, param stub, and the reposition/change-altitude command surface. Later stack PRs re-add their own test sections. 19/19 passing (cmake -DTOOLCHAIN=none, target mavlink_unittest).
Picks up the MAVLink module enums added by the multi-port split: dispatch results, radio types (mLRS, none), and autopilot types.
Live SITL test tooling for the multi-port runtime: mav_multi_benchmark.py runs baseline and stress scenarios across 1-4 active MAVLink ports (MSP failure rates, heartbeat warmup, reconnect handling); mav_multi_sweep.py drives configuration sweeps. Config paths point at the in-tree results directory; runtime artifacts are gitignored.
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
The MAVLink section of telemetryConfig_t changed shape in this PR (single mavlink struct → mavlink_common + mavlink[MAX_MAVLINK_PORTS]). pgLoad() only accepts stored EEPROM bytes when the PG version matches, so without a version bump a firmware upgrade would memcpy old-layout telemetry config onto the new struct. Bump 9 → 10 so the old blob is discarded and defaults are reset instead.
Restores the branch's protocol-service layer on top of the multi-port core: - PING and TIMESYNC replies - REQUEST_DATA_STREAM handling and per-message SET/GET_MESSAGE_INTERVAL command surface over the existing override storage - MAV_CMD_REQUEST_MESSAGE (incl. MESSAGE_INTERVAL query), REQUEST_PROTOCOL_VERSION, REQUEST_AUTOPILOT_CAPABILITIES, GET_HOME_POSITION - UBlox ellipsoid altitude, speed and heading accuracy retained in the GPS solution and emitted in GPS_RAW_INT when valid - Arming-disable reasons broadcast as STATUSTEXT once a MAVLink port is active; INAV flight-mode change notices incl. GCS NAV enter/exit - Per-port OSD-derived STATUSTEXT de-spam (changed text immediately, notice 30s / warning 10s / critical 5s repeat intervals) Unit slice: 38/38 passing.
xznhj8129
force-pushed
the
mav/04-streams-protocol
branch
from
bdf3828 to
31094de
Compare
|
I notice that the last PR was "split Mavlink telemetry into modules". I haven't read this PR in detail yet because I didn't bring my laptop on vacation. But my automation did mention: mavlink_streams.c was already the largest module at 1206 lines - the one file that didn't get split along the same clean boundaries as the rest. This PR grows it to 1454 lines by adding protocol-service logic (interval control, stream-request handling) on top of its existing stream-building. The automation may be making up silly stuff, or maybe pointing out something real? |
It grows quite a bit due to a whole lot more to do; it is a lot more manageable now on it's own but it could be a good candidate for a later refactor that breaks it down more. The current modular split i decided roughly rather than try to plan everything ahead, and little time was spent on refining the architecture too much before i decided to go for the PR. Once the whole thing is in and we've worked out the kinks there is much room for improvement. |
2 participants
Part 4/7 of the mavlink_multiport2 stack.
Adds the protocol-service layer on the multi-port MAVLink core:
REQUEST_DATA_STREAM, per-messageSET_MESSAGE_INTERVAL/GET_MESSAGE_INTERVALlayered over the legacy stream-rate model,MAV_CMD_REQUEST_MESSAGE(incl. MESSAGE_INTERVAL query),REQUEST_PROTOCOL_VERSION,REQUEST_AUTOPILOT_CAPABILITIES,GET_HOME_POSITION.GPS_RAW_INTwhen valid.Notice: INAV: Entering <mode>, GCS NAV enter/exit); OSD system messages de-spammed per port (changed text immediately; unchanged notices repeat after 30 s, warnings 10 s, critical 5 s) instead of resending every EXTRA3 tick.USE_MAVLINK_STANDARD_MODES, off by default.Verified: SITL warnings-as-errors clean;
mavlink_unittestslice 38/38.