sl-firmware 30b0f245e1 docs: retire Mamba F722S/BlackPill, adopt ESP32 BALANCE + ESP32 IO architecture

Effective 2026-04-03: STM32F722 flight controller no longer used.
New architecture:
- ESP32 BALANCE: PID balance loop
- ESP32 IO: motors, sensors, comms

Updated: CLAUDE.md, TEAM.md, docs/AGENTS.md, docs/SALTYLAB.md
Legacy src/ STM32 firmware is archived — not extended.
Source code migration pending ESP32 hardware spec from max.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-04-04 08:25:24 -04:00

2.8 KiB

Raw Blame History

SaltyLab Firmware — Agent Playbook

Project

Self-balancing two-wheeled robot: two ESP32 boards (BALANCE + IO), hoverboard hub motors, Jetson Orin for AI/SLAM.

⚠️ ARCHITECTURE CHANGE (2026-04-03): Mamba F722S (STM32F722) and BlackPill are NO LONGER USED. Replaced by: ESP32 BALANCE (PID loop) + ESP32 IO (motors/sensors/comms). The src/ and include/ STM32 firmware is legacy/archived — do not extend it. New firmware goes in esp32/ — pin assignments and framework details TBD pending max.

Team

Agent	Role	Focus
sl-firmware	Embedded Firmware Lead	ESP32 firmware, balance loop, I/O drivers, PlatformIO
sl-controls	Control Systems Engineer	PID tuning, IMU sensor fusion, real-time control loops, safety systems
sl-perception	Perception / SLAM Engineer	Jetson Orin, RealSense D435i, RPLIDAR, ROS2, Nav2

Status

USB CDC TX bug resolved (PR #10 — DCache MPU non-cacheable region + IWDG ordering fix).

Repo Structure

projects/saltybot/SALTYLAB.md — Design doc
USB_CDC_BUG.md — USB peripheral conflict details
TEAM.md — Team roles specification

Branch Strategy (issue #28)

Variant branches

Branch	Purpose
`saltylab`	Stable — SaltyLab 2-wheel balance bot (promoted from saltylab-dev)
`saltylab-dev`	Integration — SaltyLab balance bot; agents target this branch
`saltyrover`	Stable — 4-wheel rover variant
`saltyrover-dev`	Integration — rover variant
`saltytank`	Stable — tracked tank variant
`saltytank-dev`	Integration — tank variant
`main`	Shared code only (IMU drivers, USB CDC, balance core, safety)

Rules

Agents branch FROM <variant>-dev and PR back TO <variant>-dev
Shared/infrastructure code (IMU drivers, USB CDC, balance core, safety) goes in main
Variant-specific code (motor topology, kinematics, config) goes in variant branches
Stable branches get promoted from -dev after review and hardware testing
Current SaltyLab team works against saltylab-dev

Git Workflow

Branch naming: <agent>/<slug> (e.g., sl-firmware/usb-cdc-fix)
For shared code targeting main: <agent>/bd-<id>-<slug>
Before every push: git fetch origin && git rebase origin/<base-branch>
Gitea: gitea.vayrette.com/seb/saltylab-firmware

Communication

Report progress to max via MQTT: AGENT_NAME=<agent> ~/agent-mqtt/agent-send max "<message>"
Check inbox: ~/agent-mqtt/agent-read 2>/dev/null | tail -15
Prioritize messages from max (PM)

Beads (Task System)

cd /Users/seb/AI/saltylab-firmware
br list                    # List open beads
br update <id> --claim     # Claim a bead
br close <id> --reason "Done. PR #N"
br comment <id> "message"

2.8 KiB Raw Blame History