Entry 0 – Building the Drone & Setting Up Our Development Environment

Before any real development can begin, two things need to happen: the drone has to be physically built, and everyone on the team needs a working development environment. That was the focus of this week — and while it sounds straightforward, getting a group of developers onto the same toolchain when everyone is running a different machine turned out to be its own challenge.

The hardware team spent this week getting the physical drone ready. This meant soldering the components, assembling the frame, and connecting everything up. Once built, the drone was successfully connected to Betaflight — the stock firmware — which confirmed that all the hardware is wired correctly and the board is responsive.

Beyond just verifying the assembly, the hardware team also took their first steps with iNav by running an initial SITL (Software-in-the-Loop) test. This was an important early milestone: it meant that even before any custom firmware work begins, the team could observe how iNav behaves in simulation and get familiar with its configuration.

The software team's task this week was getting Gazebo and iNav installed and running the first simulations. This turned out to be more involved than expected, mostly because our team runs on four different types of machines — and not all of them play equally nicely with Linux-based tooling.

One team member had initially set up Gazebo Jetty, which worked fine on its own. However, since the whole group needs to work on the same version to avoid compatibility issues, he switched over to Gazebo Harmonic — the version we agreed on as a team standard.

Once everyone was on Harmonic, the first simulations with iNav SITL were up and running. Seeing the simulated drone respond to iNav's flight controller logic for the first time was a satisfying moment — and a good sign that the simulation foundation for Phase 1 is taking shape.

One of the more interesting aspects of this week was just how varied our team's setups are. Since Gazebo and iNav's build tools are Linux-native, everyone needed a working Ubuntu environment — but getting there looked different for each person:

• Mac M1 (Asahi Linux): One team member runs a dual-boot setup using Asahi Linux on an Apple Silicon MacBook. This gives him native Linux performance on ARM, and it has been working well so far.
• Native Ubuntu machine:Another team member has a personal desktop at home running Ubuntu natively — the simplest setup of the group.
• Old Mac with Ubuntu: One team member repurposed an older Intel-based MacBook by installing Ubuntu directly on it, replacing macOS entirely.
• Virtual Machine (Intel): One member runs Ubuntu in a VM on an Intel-based machine. Because it's an x86 chip, virtualization works smoothly and performance has not been an issue.
• Windows with external SSD boot: The Windows users on the team boot Ubuntu directly from an external SSD. This has worked surprisingly well and avoids the overhead of a VM while keeping their Windows installation untouched.

Despite the variety, everyone managed to get a working environment by the end of the week — which sets us up well for the more technical work ahead.

With the drone assembled and the development environments in place, the team is now ready to move into the real work of Phase 1: flashing iNav onto the LionBee's custom hardware and getting the simulation to properly reflect the real drone's sensor setup. More on that in the next post.