This is the design draft for the modular drone we built at TARS — what became the Modular Aerial Robotics Project (MARP). The idea was a stackable aerial platform where any unit could act as top or bottom through inverse-taper mating surfaces, mixing off-the-shelf electronics with 3D-printed structural components. Each drone carries its own weight, so stacks can grow; each unit does one thing, and you get complexity by combining them. The frame doubles as airflow duct and mating surface — structure and connection in one piece. Below is the design rationale, hardware and software stack, VR interface plans, and lab notes from early 2021. We never published this; it sat as an internal document. I'm putting it here because the thinking feeds into everything that came after — MosaicDrone, the seed-factory vision, and the thread about interfaces that I keep coming back to.
Interactive PID tuner — simulated pancake drone
Tune Proportional, Integral, and Derivative gains below. The box represents a pancake-style drone; thrust (from the PID) fights gravity. Watch overshoot, oscillation, or steady-state error in the height plot. Enable wind or turbulence to see how the controller rejects disturbances. The teal plane is the target height.
Givens — physics & BOM (flat box, RPi 4, carbon fiber)
- g
- 9.81 m/s²
- mass
- 0.610 kg (610 g)
- max thrust
- 13.17 N
- thrust-to-weight
- 2.2∶1
- frame
- 320 mm span × 30 mm (flat box)
- arm (half)
- 160 mm
- Ixx, Izz
- 5.25 g·m²
- Iyy
- 10.41 g·m²
- wobble
- 4-motor asymmetry → torque → pitch/roll
| Item | Mass (g) |
|---|---|
| Raspberry Pi 4 (4GB, with heatsink) | 55 |
| Carbon fiber frame (flat plate + arms, ~320 mm) | 95 |
| 4× brushless motors (2207 2400 kV) | 140 |
| 4× ESCs (25 A) | 32 |
| Flight controller (Pixhawk-style) | 16 |
| 4S LiPo 1800 mAh | 185 |
| 4× props (5") | 56 |
| Wiring, screws, mounting | 31 |
| Total | 610 |
Architecture overview
We drew this up in one of the early design sessions — mapping compute (Raspberry Pi 4, Jetson Nano), flight control (Navio2 on the RPi4), the data streams we cared about (odometry, telemetry, air temp/pressure, wind, compass, depth from the RealSense), how units would physically connect (Velcro first, rigid clasps later), and how depth data would get into Unity via Python bindings for the VR interface.
Design principles
We wanted units you could modify, reprint, and swap without the whole system being special. Modularity meant any part could be iterated on independently; stackability meant you could combine units for different missions without redesigning anything. The inverse-taper geometry gives every unit a universal connector — any unit can mate above or below another. The airframe is ducted to hide the blades and improve safety.
The split was: off-the-shelf for electronics (Pi, Navio2, RealSense, ESCs, motors) and custom additive-manufactured for structure (frame, arms, mating surfaces). Everything was laid out for repeatable assembly and eventual automation — DFM (design for manufacturability) and robot-assembleable. Because the mating system is the same regardless of what hardware a unit carries, you can stack units with different compute, sensors, or roles and the capabilities combine.
Geometry and mating
The airframe has two halves — top and bottom — that are inverse tapers of each other: bottom concave, top convex. Those are the mating surfaces. The arms are the primary structure, with the center of mass contained inside the core. This gives you a universal frame and connector: every unit can be a top or a bottom, so you can stack heterogeneous drones without limit. As of 3/30/21, our first milestone was demonstrating physical connection in midair; pairing drones with different hardware would come once basic stacking was proven.
v1 pancake, v2–v3 box — and Crazyflie
v1 was the pancake — so called because you stack units on top of each other to form a pancake stack; it's conic as well, with inverse-taper mating. It was a collaborative effort: I drove bi-weekly sprints with Spencer Carr, AJ Lombardi, and Patrick O'Mahoney, coordinated the grad students and PhDs — including Xinchao Song, who I did a lot of the work with — and coordinated the efforts of the other undergrads. Clips in the sidebar show the pancake prototype in flight.
v2 was the big, heavy box with ball-and-socket joints at the corners — clearer structure for mid-air docking and more room for stackable modules (compute, power, sensors).
v3 was the small box: joints that can have magnets on the ends to connect the drones, lighter and more compact.
At a certain point we also brought Crazyflie into the pipeline. Crazyflie is a small, research-oriented quadcopter with a strong SDK and swarm support, and it's indoor-safe and easy to iterate on. Using it let us focus on stacking logic, coordination, and VR teleoperation without spending as much time on low-level flight reliability and custom hardware integration. We could validate algorithms and human-in-the-loop behavior on Crazyflies while the heavier custom builds (Pi, Navio2, Jetson) remained the platform for full MosaicDrone-style stacking and sensing. So: v1 pancake proved the concept, v2 and v3 box gave us physical docking and connectors, and Crazyflie gave us a fast loop for control and swarm research.
More footage
v1 pancake, v2–v3 box drone and other clips (sped up, looped). TARS Lab.
Truss structure
The whole frame is truss — one topology that gives you airflow, structural integrity, and mating capability at the same time. Because each drone supports its own weight, a stack is theoretically unlimited in height (in practice you hit control, stiffness, and mission constraints). All the CAD was done in SolidWorks with parametric models so we could change arm length, motor spacing, or connector geometry without starting from scratch.
System composition and hardware
A single unit has four arms and one core, mixing off-the-shelf electronics with 3D-printed structure. For compute we used Raspberry Pi 4 (Pi 3 as interim) and a Jetson Nano for image recognition, object detection, and segmentation through jetson-inference. Flight control ran on Navio2 (on the RPi4) with ArduPilot for PID and stabilization; we also used BetaFlight and the BetaFlight Configurator for direct control and PID tuning. Depth came from an Intel RealSense 455; we also pulled telemetry, air temp, pressure, wind, and compass. One early constraint that shaped the design: Navio2 is incompatible with the Jetson Nano, so the first prototypes ran dual Pis — a Pixhawk would be needed as flight controller for any Nano-based unit.
Physical connection
We started with Velcro between stacked units — cheaper and easier to iterate on — with rigid clasps and eventually magnetic locking planned for later. On the software side, GPIO on the Pi could trigger a Python script when a connection was detected, so the system could automatically reconfigure or log when modules stacked. As of 3/30/21 the main goal was getting two drones to physically connect in midair.
VR interface
We planned a VR teleoperation interface on the HTC Vive Pro: import depth data from the RealSense into Unity via Python bindings, then build controls for flying and visualizing from the drone's perspective. In spring 2021 VR wasn't the immediate priority — physical connection was — but we had the architecture mapped out, including OpenHMD for headset support. Outdoor testing would need a headset with on-board tracking (no lighthouses), like the Quest.
VR control systems, biometric auth, and swarm teleoperation (2022)
By 2022 we were working on the VR control systems more seriously. The idea was that the pilot doesn't just fly the drone — the system knows who's flying. TARS already had published work on behavior-based biometric authentication in VR — identifying users from how they move in a headset, cross-system auth that works across different VR hardware, and motion forecasting from controller and head tracking data (this line of research won multiple Best Paper awards at IEEE VR, AIxVR, AIVR, and MMM). We wanted to bring that into the drone pipeline: use VR teleoperation data — wrist orientation, head pose, controller trajectories, the way a specific person flies — as a biometric signature for authenticating who has control of the drone. If you're flying a drone through VR, your movement patterns are already being captured; the question was whether those patterns are distinctive enough to identify you, the same way the lab had shown VR motion is distinctive enough for authentication in other contexts.
Beyond single-drone teleoperation, we were planning swarm teleoperation — one operator controlling multiple drones through VR simultaneously, or at least issuing high-level commands to a swarm and monitoring from a first-person or bird's-eye VR view. The interface would let you switch between individual drone perspectives (see from any drone's camera) and a third-person overview reconstructed from the collective sensor data. The Crazyflie SDK's swarm support made this tractable for indoor prototyping.
We were also thinking about mobile manipulation through gesture-controlled swarms. The idea: instead of flying one drone with joystick-style inputs, you use hand gestures and body movement in VR to direct a group of drones to collectively pick up, carry, or position objects — the swarm as a distributed manipulator arm controlled by natural human motion. You point, you gesture, you shape the formation, and the swarm responds. This connected back to the lab's broader HRI work — the question of how humans and robots coordinate physical tasks — but now with a swarm of flying units instead of a single arm or hand. None of this shipped as a finished system; it was the research direction we were building toward in 2022, on top of the physical stacking and connection work from 2021.
Natural language drone control and the Culture (2023)
In 2023 I started prototyping a natural language control system for drones — talk to the drone in plain language and have it execute spatial commands, report status, ask clarifying questions. This was always the original intent behind the project. The whole reason I wanted to build modular drones in the first place was the Independent Drones from Iain M. Banks's Culture novels: machines you talk to, that talk back, that have personality and opinions and a sense of humor.
In the Culture, Drones are full citizens — sentient, with legal rights equal to the Minds that run the ships and Orbitals. They communicate through aura fields: colors that shift with mood (red for pleasure, green for friendliness, blue for formality, grey for frustration). They range from plain, functional forms to wildly ornate — some build sand sculptures, some argue about ethics, some are sarcastic and territorial about their personal space. The point is they're not tools and they're not assistants. They're participants — they have preferences, history, a style of being in the world. The relationship between a Culture citizen and their Drone companion is conversational, mutual, sometimes argumentative. That image never left me. When I read those books in the summer of 2020 — over thirty of them — the inspiration for everything that followed was seeded there.
The problem in 2020–2021 was that language models weren't good enough. GPT-2 existed but couldn't reliably parse spatial commands or hold coherent multi-turn dialogue about a physical task. By 2023, GPT-3.5 and GPT-4 changed that — you could give a model a system prompt describing the drone's capabilities, spatial context, and constraints, and it could parse “move to the table on the left and hold position” or “form a line with the other two drones” into structured commands. The prototype I was working on sat between the language model and the flight controller: natural language in, parsed intent and spatial parameters out, translated into waypoints or formation commands that the drone (or swarm) could execute. The idea was that you shouldn't need to learn a controller mapping or a gesture vocabulary — you just say what you want, the way you'd talk to another person, and the system figures out the execution.
This is also what connects the drone work to the personoid thread from the TARS page. A Culture Drone isn't just a voice interface stapled onto a quadcopter — it has an identity, a way of speaking, a persistent memory of past interactions. The natural language layer was the first step toward that: once the drone can understand you and respond, you can start giving it personality, preferences, and something like a disposition. Not consciousness — we're not there — but the kind of expressive, conversational presence that makes the difference between a tool and a companion. That's the long arc from Banks's fiction through the TARS lab work to here: modular bodies that can be built, repaired, and recombined, with a mind — or at least a persona — that persists across embodiments and talks to you like a colleague.
Flight control and PID
A PID controller keeps the drone at a target state by reacting to error — how far off it is from where it should be. P (proportional) pushes harder the bigger the error. I (integral) gets increasingly impatient the longer the error persists — it handles steady-state drift, like going up a hill. D (derivative) slows the correction down to prevent overshoot. One way to think about it: three people moving a couch on ice. One pushes toward the target (P), one gets more and more frustrated the longer the couch is in the wrong place (I), and one pushes back when the other two are about to send it flying past the mark (D). Individually they're flawed; together, with the right tuning, they solve the problem. We used Navio2/ArduPilot and BetaFlight for the PID layer; tuning was done through mission planner and the BetaFlight configurator, and the tooling remained a bottleneck throughout.
Lab context and timeline
Early 2021: parts were coming in, and the immediate focus was getting the Jetson Nano and Raspberry Pi on the network — Anthony on the RPi4, me on the Jetson. Drone footprint target was about 18 inches square. By 2/14/21 we were still waiting on the Navio2 delivery. 3/30/21 was a long lab session where we dug into the physical connection prototype: Velcro for now, hard clasps later; Spencer was on CAD, Anthony and I were on Pi setup and mapping the controller to the base station via Mission Planner. Software stack was C++, Java, and Python for object detection and computer vision; MATLAB for matrix work and visualization; ROS integration still to be defined. Regulations: indoor flight was open; outdoors would mean FAA Part 107 and recreational rules; swarm and industrial use were far-future thinking.
Generative design and complexity by stacking
The whole point was that the design is generative: you derive different drone variants from the same paradigm, and stacking is how you get complexity. Each unit does one simple thing; stack them and the capabilities combine. We wanted a universal, modular baseline — and eventually a more polygonal geometry that would allow connection along every axis, not just vertical.
Current limitations
Software tooling — tuning and mission planning especially — was a constant bottleneck. Velcro needed real validation under load and in flight. And the Navio2/Jetson incompatibility forced dual-Pi setups on the first prototypes.
Future directions
- Stacking and linking in other directions — not only vertical stacking but connection along multiple axes.
- Universal joint — passive latch with every side symmetrical so that any face can link to any other.
- Power modules and thrust modules as stackable units that integrate with the same mating system.
- Swarm potential — autonomous coordination of heterogeneous stacks for collective tasks.
Vision: seed factories, space, and sky
I wanted this line of work to point toward a self-assembling, bootstrapping seed factory — on the Moon, or on an asteroid — where all materials can be composed and modularized so that a distributed robot could be formed aerially. The same idea of universal mating, stackable units, and heterogeneous capability applies: if every part can connect to every other, and units can dock in mid-air (or in microgravity), you get structures that grow from local resources and reassemble into whatever the mission needs.
That paradigm could be adapted toward space systems. Maybe even this century we see frigate drones — large, reconfigurable platforms built from modular pieces — and cities in the sky: persistent aerial or orbital structures composed of the same kind of composable, stackable, and robot-assembled units. The lab work here is a step toward that: prove mating and stacking in the air, then scale the idea up and out.
Related: TARS Lab · TARS at Clarkson · MosaicDrone (separate project)