Hux
Bench-learning plan, superseded 2026-09-26. This page describes what the F765-Wing and the Pi 5 on the table would run for P0–P1: blink, CRSF, one wheel, a listener. The F765-Wing has no CAN bus, so it is not the robot's controller; the robot's stack is four layers — CAN actuators, a portable control core, a CAN real-time MCU, and a ROS 2 companion — in docs/software.md. What survives from this page is what lands in the control core; the Pi 5 does carry forward, in containers.
V1 scope, 2026-09-27: done means one 9.5" step, 9 of 10 from a standstill (R37); the TWO_WHEEL speed command clamps at 1.5 m/s, cruise 1.0 (R38); V1 terrain is flat + 1" sills + ~20° slopes (R40). The one-leg shift is roll plus a planned leg-length difference (2.8" at the Sheet 1 roll axes) — the sandbox's feed-forward, to be carried into the control core. Detail: docs/software.md.
| Chip | Software | Job |
|---|---|---|
| F765-Wing | No OS. A 1 kHz timer and a main loop, built in PlatformIO with the STM32 Arduino core. | Read both gyros. Read the Nano. Keep the mode. Send a text stream to the Pi. The PID joins this same timer later. |
| Pi 5 | Raspberry Pi OS Lite, 64-bit. Debian 13 Trixie, kernel 6.18. | One Python 3 process. It reads the stream and prints the mode, the attitude, and the sticks. |
| TBS Nano RX | TBS firmware, set to CRSF. | Sticks in, telemetry back. No Hux code. Channel 1 is CRSF TX, channel 2 is CRSF RX. |
| ESP32 | Nothing. | Stays unused. The Pi already has Wi-Fi. |
| Wheel driver, later | SimpleFOC on that driver's own microcontroller. | The current loop. It takes a torque number from the Wing. It does not move onto the F765 or the Pi. |
ArduPilot is on the F765-Wing today and comes off. Its estimator and mixer assume a plane or a rover, and its arming rules will fight a balance loop. INAV and Betaflight are the same kind of program. Hux is MIT and ArduPilot is GPL-3, so the new image is not a fork. Keep the pin map: which pad is which UART, and that the two gyros are an MPU6000 and an ICM20602 on SPI. Write Hux's own startup.
| When | On the Wing | On the Pi |
|---|---|---|
| First flash | Tilt the board, move a stick, write one text line out USB. | Open the serial port and print the line. Listen only. No torque commands. |
| After the balance study | The studied PID, a few more lines in that same 1 kHz timer. Not a second framework. | Still listening. Setpoints come later, after the four modes work from the stick. |
The Pi does not get a real-time kernel, and it does not run ROS. Python is enough for the listener. The same process can grow a camera stream and pathfinding later. The Pi does not build or flash the Wing. That happens from the bench computer over USB, using the Wing's boot button.
C1 and C2 on the Wing are analog composite video into the OSD, then out the VTX pad. Both cameras have to be the same format. That path is a pilot picture later, with the horizon burned in. The stair cameras are CSI or USB on the Pi. They do not go through those pads, and they are not in this image.
The first image tracks the name. It does not balance, lift a foot, or follow a path.