Bridge family · mavlink

OpenMHS family: mavlink

MAVLink vehicles (helper:mavlink, planned)

Recipe published4 packageshardwaresimulated
On this page 9 sections
  1. Launch
  2. Registry coverage
  3. Applicability
  4. Capability mapping
  5. Safety
  6. Fidelity
  7. Pitfalls
  8. First task cards
  9. Sources

MAVLink vehicles (helper:mavlink, planned)

Generated by MHS/registry/build_registry.py on 2026-10-20T00:00:00Z from 4 registry records and their task cards. A plan, not a conformance claim.

  • bridge_status: planned (blocked_on: helper:mavlink)
  • helper: none
  • exemplar: none

Launch

Every driver package starts the same way; per-repo configuration (environment id, model path, port, baud rate, VISA resource) lives in the package's driver.py, never in launch flags:

text
mhs serve <driver-dir>

A package is done when python3 -m mhs.driver check <driver-dir> --backend fake exits 0 (evidence contract_checked; a fake never yields an MHS-Device level).

Registry coverage

  • Repos: 4
  • Decisions: bridge-runtime 1, family-config 2, skip 1
  • Waves: 5: 2, 9: 2
  • Dispatchable now: 0
  • Modes: hardware 2, simulated 3

Applicability

Telemetry becomes reads; arm, take-off and land are actions on x-cap extensions until classes exist; return-to-launch or land is the safe state; SITL is the fake.

Capability mapping

The mapping is fixed when the helper lands; the applicability section lists its rules.

Class ids come from python3 -m mhs.driver catalog search <words>. The deprecated classes cap.device.describe.v1, cap.world.state.v1, cap.world.snapshot.v1 and cap.world.restore.v1 are replaced by the protocol methods mhs.devices.get, mhs.resource.read, mhs.snapshot and mhs.restore.

Safety

The risk floor of a device is the highest catalogue risk_class of its classes (CAP-017); a driver may declare a higher risk, never a lower one. Hardware at R1 or above needs an @estop and a non-empty safe state. Flying vehicles; the e-stop and the geofence come first.

Fidelity

Bridge only; the fidelity belongs to the service, simulator or hardware behind it.

Pitfalls

PX4 and ArduPilot differ; frame conventions must be declared.

First task cards

  • gh.ardupilot/ardupilot: family-config, wave 5, rank 2, MHS/registry/tasks/robots/ardupilot__ardupilot.json
  • gh.px4/px4-autopilot: family-config, wave 5, rank 3, MHS/registry/tasks/robots/px4__px4-autopilot.json
  • gh.intel/gazebo-sitl: bridge-runtime, wave 9, rank 571, MHS/registry/tasks/robots/intel__gazebo-sitl.json
  • gh.radarku/px4-sitl-docker: skip, wave 9, rank 1913, MHS/registry/tasks/robots/radarku__px4-sitl-docker.json

Sources

  • Task cards: MHS/registry/tasks/<track>/<owner>__<repo>.json (schema/taskcard.schema.json).
  • Triage rules and the helper table: MHS/registry/triage.py; curated decisions: MHS/registry/overrides/.
  • Driver API and gate: MHS/sdk/docs/driver-authoring.md; exemplars: MHS/drivers/.

Packages

Top 4 of 4 by stars. Filter the full list.

PackageTierRingEvidenceStars
ardupilot/ardupilot
ardupilot/ardupilot: control framework for UAVs; underwater robotics; mobile robots (robotics track). OpenMHS plan: fami
Tier B3static scan16,018
px4/px4-autopilot
px4/px4-autopilot: device backend; control framework (robotics track). OpenMHS plan: family-config with mavlink helper (
Tier B3static scan12,764
intel/gazebo-sitl
intel/gazebo-sitl: protocol implementation/bridge for UAVs (robotics track). OpenMHS plan: SDK bridge runtime, not a per
Tier B3static scan10
radarku/px4-sitl-docker
radarku/px4-sitl-docker: complete environment for UAVs (robotics track). OpenMHS plan: not integrated (override:recon).
Tier D3static scan8