Eight synthetic activity groups drive two motor outputs
FlyBrain Robot Bridge connects a camera pipeline to left and right motor commands. Frames are resized to 160 by 120, converted to grayscale, and processed with Farneback optical flow. Motion in each half and center-relative expansion feed a small model with 8 activity groups. A decoder applies limits, a dead zone, optional inversion, and smoothing before producing the two outputs. IMU yaw can damp activity on the corresponding side.
The name invites a much bigger interpretation than the code supports, and the README handles that honestly. The default backend is hand designed. Its groups have labels such as left_motion, looming, and escape; they are not mapped biological neurons. MaleCNS support is an integration target. The current class validates that a dataset path exists, calls load_graph, and raises Not implemented yet. No connectome is loaded or simulated.
The 10-second synthetic demo is the finished product
The strongest use of this repository is its deterministic synthetic mode. The default run covers 300 frames, roughly 10 seconds, without a camera, robot, network connection, or downloaded connectome. A recorded GIF comes from the actual encoder, mock backend, and decoder. Terminal output exposes motion, looming, IMU freshness, commands, and watchdog state, which makes the signal path easy to inspect while changing parameters.
Synthetic mode is not a physics simulator. Its IMU oscillation is generated independently, and the displayed frequency is simulation rate rather than a performance result. That boundary matters because a stable console trace cannot predict traction, motor lag, bad lighting, camera shake, or a robot's response to a command. The demo proves data flow, not control quality.
What happened when we ran it
Our sandbox installed commit 966e541 in 39 seconds, pulling 40 packages and occupying 272 MB on disk. The build succeeded in 7 seconds. Pytest completed in 10 seconds with 26 passed and 0 failed out of 26. Pip-audit reported 0 known vulnerabilities in the environment we tested.
The checkout contained 38 files, about 826 lines of source, and used 2.6 MB before installation. It has 1 CI workflow, a tests directory, and no Dockerfile. Those proportions fit the project: most behavior is compact Python, while OpenCV and its dependencies account for much of the installed footprint. Our results cover software checks, not camera quality, UDP reliability on a real network, or physical motion.
A 500 ms watchdog helps only while both ends keep working
The PC emits zero commands when telemetry is absent or older than 500 ms. The motor decoder also returns zero when read more than 500 ms after an update, and normal shutdown attempts to send a stop packet. Packet validation rejects malformed JSON, nonfinite speeds, invalid vectors, out-of-order sequence numbers within a session, and datagrams larger than 2,048 bytes. Those are sensible defensive choices for a prototype.
They are not an emergency-stop system. The decoder is not a background thread and cannot act if Python hangs. UDP does not guarantee delivery, while the protocol has no authentication, handshake, or session identifier. The README therefore requires an independent receiver watchdog and motor power cutoff. Keep both. A source-IP check and increasing integer do not protect a robot on an untrusted network.
Physical motion still needs firmware engineering
The included Atom Matrix firmware is a scaffold. Before it can move hardware, someone must implement board-specific servo output and IMU reads, choose pins, calibrate neutral positions and limits, and verify the receiver's 500 ms stop behavior. The project says that scaffold has not been compiled or tested on a board. There is also no recorded physical robot demonstration.
Configuration is otherwise readable. The example YAML exposes the PC and robot ports, maximum speed, smoothing, dead zone, looming threshold, watchdog timeout, and per-side inversion. Start with --dry-run, then test with the robot lifted and an independent cutoff within reach. The looming signal is an optical-flow heuristic affected by camera motion, frame rate, and light; it is explicitly not collision avoidance.
September activity supports the demo, not a release promise
GitHub records 222 stars, 0 open issues or pull requests, and a last push on September 16, 2026. There is no published release. The repository includes one CI workflow that runs linting, pytest, and a synthetic smoke command, which lines up with the 26 tests that passed in our lab. The visible maintenance evidence is recent but brief.
Documentation is the project's best maturity signal. The architecture notes define ports 9000 and 9001, numeric ranges, packet rejection rules, and the limits of the watchdog. The MaleCNS document lists extension seams without pretending they work. That candor makes FlyBrain good teaching material. It also makes the buying decision simple: adopt the tested mock pipeline, or wait if the connectome and robot are the parts you need.