// the find
swarm-subnet/Langostino
Langostino - An open-source autonomous drone platform using ROS2 and AI-powered flight control. A complete reference implementation for building, understanding, and extending real-world drone autonomy.
Langostino is an open-source flight stack for a small INAV-based quadcopter. A Raspberry Pi 5 runs ROS2 Humble nodes that speak MSP to the flight controller, read a LiDAR, and run a learned flight policy. It is aimed at people who want to see how a learned autopilot is wired into real hardware, and who are prepared to build the airframe to find out.
- The INAV link is plain Python (msp_protocol.py, msp_serial_handler.py, msp_message_parser.py) with no vendor SDK, so you can read exactly what gets sent to the flight controller instead of trusting a library.
- Each concern is its own ROS2 node: fc_adapter, lidar_reader, ai_flight, safety_monitor, black_box_recorder. The safety monitor and recorder run as separate processes, so a crash in the policy node does not take them down with it.
- The hardware side can be reproduced from the repo. The INAV dump and custom firmware hex are committed beside the guides, and the 3D-print STLs for the mounts are included, so the configuration is not only described in prose.
- Setup has scripts for both Ubuntu 22.04 and 24.04 plus verify_setup.sh, which is more than most hardware projects ship.
- The policy that flies the drone ships as a zipped binary (model/UID_3.zip). The tree shows no training code, environment definition, or data, and the README does not say how the model was trained or whether the Bittensor side produced it. That sits awkwardly with the README's 'not a black box' claim.
- Nothing in the listing looks like unit tests or CI. tests/ holds two flight scripts that need the airframe on a bench or in the air. The boundary between simulator and real observations, which is where most sim-to-real bugs live, has no check that runs on a laptop.
- old/ holds seven superseded scripts next to the live nodes, including four competing arm and throttle sequences. A newcomer has to work out which MSP sequence is the real one before they can trust the arm logic.
- Everything is pinned to one INAV board (SPEEDYBEEF405V4) with a custom firmware build. Porting to another flight controller means reworking the MSP layer and the parameters in swarm_params.yaml, and the architecture walkthrough lives in a Substack series rather than in the repo.