What I learned from making my own drone (Part II)
Nickolai’s Substack
SubscribeSign in
What I learned from making my own drone (Part II)
Nickolai Belakovski<br>Jun 02, 2026
Share
In part 1 we left off with a video showing some semi-stable flight
However, as my mother would say, it doesn’t look stable at all. It just drifts around and crashes. And as much as she doesn’t appreciate how hard PID controllers are, she has a point. So the next step would be to figure out how to get a more stable and controlled flight. Eventually I was able to get to a flight that looked like this:
It’s much more stable and controllable (and yes my apartment is a lot cleaner 😅). There’s still some wobbliness and I’m not truly happy with how it responds to my control inputs, so there will be a part 3 where I dial those things in. For now though, I’d like to talk about how I improved the capabilities of the drone from that first version.<br>Tracking altitude, xy velocity, and heading
There’s three things that jump out as unstable about that first video, the altitude, the xy velocity (i.e. drifting left/right and forward/back), and the heading (notice how it lazily spins as it takes off).<br>Tracking altitude turns out to be fairly simple. Hobby level barometers are sensitive to pressure changes of as little as +/-0.5 Pa, which translates to about +/-5cm of altitude. It might even be possible to combine accelerometer measurements through a Kalman filter to get even more accuracy. Time of Flight (ToF) sensors can also provide altitude, but since they’re reflecting off the ground, flying over a cluttered area can cause bad readings if you don’t have the appropriate logic to detect jumps, and so it seemed like a barometer would be an easier, more robust solution.<br>X and Y velocity can be handled in one of two ways. Firstly I can simply connect some sort of controller, i.e. an xbox controller, and control the X and Y velocity manually. This is something I would want to do anyway in order to have some control over the drone. Secondly I could use an optical flow sensor to automatically control the X/Y velocity. These are not mutually exclusive, of course, but I decided that in the spirit of making small improvements I would start out with the controller and I would design my PCB to be extensible to allow for adding an optical flow sensor later on.<br>However it would be difficult to use a controller given the spinning behavior you see in the first video. Either the drone’s heading needed to be stabilized, or the controller’s commands needed to be converted into the drone coordinate frame. In either case the solution is to use a magnetometer.<br>In the following sections I expand on how I dealt with all three of these topics, including challenges that I faced along the way.<br>Barometers are noisier than you think
While the datasheet for my pressure sensor of choice, the BMP581, claims a relative pressure accuracy of +/- 0.4 Pa, and probably delivers it when the pressure is actually constant, the data it delivers when sitting on my desk paints a different picture.
The sensor is sitting on my desk in my apartment. My door is closed, my window is closed, and my AC is off. And yet we see three rather concerning behaviors. The first is the spikes around 10s, 22s, 60s, and others. The second is the slow drift which is most noticeable in the last 20-30 seconds of the graph. And the third is that when sitting still the readings range over +/-3.5 Pa, which translates to +/-35cm of altitude.<br>I decided to see if I could improve this by combining the accelerometer data. I built a little test platform that included the pressure sensor, the accelerometer, as well as a Time of Flight (ToF) sensor to measure distance to the ground to act as a ground truth for whatever method I chose to use to combine the two sensors. Ultimately I was able to develop and tune a Kalman filter to provide a passable looking estimate of the vertical velocity.
To get the estimate this good I had to modify the process noise and sensor noise matrices (Q and R) of the Kalman filter dynamically. When acceleration was low I would increase Q relative to R, i.e. increase my trust in the accelerometer measurements, otherwise I would increase R relative to Q and trust the barometer more. This worked reasonably well for estimating vertical velocity, but it was not very good for estimating altitude.<br>At the end of the day, in the interest of making progress, I decided to use the altitude as reported by the barometer with a low pass filter applied to take out some of the noise, and accept the consequences. Ultimately it worked fairly well and made flying the drone a lot easier by not having to think about the altitude too much, but this is something I’d like to revisit in version 3 to see if I can do better.<br>Trimming the center of gravity
As part of trying to “track” xy velocity I set about trying to trim the drone. Essentially I would hang the drone by a string in its flight configuration...