Glue logicielle — Cargo workspace Rust¶

Environnement de dev pour le code custom du projet : orchestrateur multi-véhicule, daemon companion, et types MAVLink partagés.

Prérequis : setup-macos.md terminé, SITL fonctionnel, Rust installé (rustup).

Workspace `my_fleet/software/`¶

Trois crates dans un seul Cargo workspace :

Crate	Rôle	Cible	Phase	Statut
`fleet-mavlink`	Types MAVLink + helpers (mode names, `VehicleState`) partagés	lib	dès Phase 0.5	OK 2026-05-10
`fleet-base`	Orchestrateur multi-véhicule station de base	bin Mac M1	Phase 4+	OK 2026-05-10 (smoke test SITL)
`fleet-companion`	Daemon embarqué (sentinel PIR + photo-on-demand)	bin Pi Zero 2W	Phase 3+	OK 2026-05-10 (selftest)

fleet-sync (rsync au retour WiFi) reste à écrire en shell — pas besoin de Cargo.

Pourquoi Rust partout¶

Facteur	Impact
Mêmes types MAVLink des deux côtés	`fleet-base` et `fleet-companion` consomment `fleet-mavlink` → zéro duplication de protocole
Solo dev R&D	Une seule stack, un seul `cargo test`, un seul `cargo build --workspace`
Memory safety en plein air	Crash en mission = mission perdue. Rust élimine les bugs C classiques (UB, double-free, races)
Cross-compile depuis M1	`aarch64-unknown-linux-gnu` pour Pi Zero 2W via `cross` ou linker Homebrew (voir `fleet/README.md`)
Scale jusqu'à ESP32	Si un module ESP32 entre au BOM (sensor pod, beacon LoRa…), Rust scale via `esp-hal` + `embassy` sans changer de langage

C reste réservé aux MCU sans OS contraints (STM32 sans ArduPilot par exemple) — pas notre cas.

Build & test¶

cd ~/Project/bascanada/my_fleet/software
cargo build --workspace --release
cargo test --workspace

Run fleet-base contre SITL local :

# Terminal 1 (depuis my_fleet/)
make plane

# Terminal 2
cargo run --release -p fleet-base -- --vehicle plane=tcpout:127.0.0.1:5760

Selftest companion sur Mac :

cargo run --release -p fleet-companion -- --selftest
# → écrit /tmp/fleet-captures/selftest.jpg (1 byte stub sur macOS)

Cross-compile fleet-companion pour Pi Zero 2W¶

rustup target add aarch64-unknown-linux-gnu
brew tap messense/macos-cross-toolchains
brew install aarch64-unknown-linux-gnu

# ~/.cargo/config.toml :
# [target.aarch64-unknown-linux-gnu]
# linker = "aarch64-unknown-linux-gnu-gcc"

cargo build --release -p fleet-companion --target aarch64-unknown-linux-gnu

Détails complets dans software/README.md.

Layout¶

my_fleet/software/
├── Cargo.toml              # workspace root, deps centralisées
├── fleet-mavlink/
│   └── src/lib.rs          # VehicleState + mode helpers
├── fleet-base/
│   └── src/
│       ├── main.rs         # CLI multi-véhicule
│       ├── vehicle.rs      # 1 task Tokio par véhicule
│       └── coordinator.rs  # règles cross-vehicle (TODO Phase 4)
└── fleet-companion/
    └── src/
        ├── main.rs         # entry + selftest
        ├── camera.rs       # libcamera-jpeg (Linux) / stub (macOS)
        ├── sentinel.rs     # rppal GPIO PIR (Linux) / stub (macOS)
        └── serial.rs       # MAVLink serial reader (Linux + macOS)

TODO par phase¶

Phase	Crate	Travail
1	fleet-sync (à créer)	Script shell rsync au retour WiFi
3	fleet-companion	MAVLink read loop complet, handler `CAMERA_TRIGGER`, serveur FTP
4	fleet-base	Règles dans `coordinator.rs` (RTL → HOLD, etc.) + dashboard terminal
4+	fleet-base	Optionnel : web local axum pour superviser depuis tablet
Futur	nouvel ESP32	`esp-hal` + `embassy` pour sensor pod / beacon / repeater

Logging¶

RUST_LOG=fleet_base=debug,fleet_companion=debug,info cargo run -p fleet-base -- ...