bishal / FIELD NOTES

Notes from a Bell-sponsored program

Warning drone pilots before a tip-over

By Bishal

Over a winter break I led a team upgrading a template drone. The part I built watched how far the drone was banking and told the pilot when it was getting close to going over.

4 min read · The drone, what I built, and how the alert reached the pilot

A four-armed carbon-fiber drone with exposed boards, antennas and wiring, sitting on a white table in a conference room with cables running off it and laptops on the tables behind.
The drone on a conference room table, early January 2023. Carbon-fiber frame, boards and a small fan on the top plate, antennas, and a lot of cable. I blurred one label on the top plate.

The problem was tip-overs in manual flight#

This is the drone I worked on during a winter-break program sponsored by Bell Helicopter, part of Textron. Bell invited me, and these photos are from early January 2023.

I was selected to lead a team, and our job was to upgrade a baseline template drone. So the first question was what to upgrade. The gap I found was manual flight safety. With a person on the sticks, aggressive maneuvers could end in dynamic rollover, which is when the drone rolls past the point of recovery and tips over. Pilots struggled with it.

That became the project: work out how far the drone is banking, work out whether that's getting dangerous, and tell the pilot while there's still time to correct it. I owned the software architecture, and I built the modules that calculated the banking angles and got them to the pilot.

What banking is, and why it tips#

This part is general physics, not a description of my code.

A drone moves by leaning. The rotors push straight out of the top of the frame, so when the frame tilts, some of that push goes sideways and the drone moves that way. Leaning side to side is roll. Leaning nose up or nose down is pitch. Those are the banking angles.

A drone tilted by its roll angleSeen from behind, the drone's body is tilted away from level by the roll angle. Thrust points along the tilted body, so part of it still holds the drone up and part of it pushes the drone sideways.levelroll angle φcenter of gravitythrustholding it uppushing it sideways
The general picture. Thrust leans with the body, so only part of it is still holding the drone up.

Only the part of the push that's still pointing up holds the drone in the air. Lean further and less of it is left for that job.

The center of gravity is the other half. Picture the drone pivoting over one leg. While the center of gravity is still on the inside of that pivot, gravity pulls it back upright. Once it crosses over, gravity pulls it the rest of the way down. If the drone is already rotating, or the motors are still pushing, it can get there at a smaller lean than you'd expect. That's the "dynamic" in dynamic rollover.

What I built#

The core of it was one real-time, safety-critical C++ module running on the drone's companion computer, which is an extra onboard computer for running your own code.

  • IMU data fused at 100 Hz. The IMU reports how the drone is moving and rotating.
  • Roll and pitch angles. The module calculated how far the drone was banking.
  • Center-of-gravity thresholds. It calculated these alongside the angles, to judge when a lean had gone too far.
  • Tip-over prediction. The point was to warn before the drone went over, while the pilot could still correct it.
  • Alerts over MQTT. They went through a telemetry pipeline to the pilot and the Ground Control Station with under 50 ms of latency.
The same drone from another angle on a wooden table, showing stacked carbon-fiber plates, small circuit boards, a cooling fan, red and black wiring and two long antennas.
Another angle, on a wooden table. Stacked carbon-fiber plates, small boards, a fan and two antennas. I blurred two stickers on the top of the stack.

How the data got from the IMU to the pilot#

Data flow from the IMU to the pilotIMU data is fused at 100 Hz in a C++ module on the companion computer. The module calculates roll, pitch and center-of-gravity thresholds, predicts tip-over, and publishes an alert over MQTT that reaches the pilot and Ground Control Station with under 50 milliseconds of latency.IMU datafused at 100 HzC++ module on the companion computerRoll, pitch, center-of-gravity thresholdsTip-over predictionAlert published over MQTTalert latency: under 50 msPilot and Ground Control Station
The alert path. Everything above the last arrow ran on the drone.

MQTT is a lightweight publish/subscribe messaging protocol. One side publishes a message to a topic and whoever subscribed to that topic receives it. That's how an alert got off the drone and in front of the person flying it.

A warning like this is only useful if it arrives while the pilot can still act on it. Getting alerts under 50 ms came down to two things: optimizing the C++ computation and tuning the MQTT publish rate.

How it went#

In manual-flight test trials, tip-over crashes came down by about 40%, measured across 20+ aggressive manual test flights. That's a result from those trials, with pilots flying hard on purpose, so I wouldn't read it as a general number for every drone and every pilot.

Bell also gave me a return offer.