Well, I feel like this will be one of these sentimental entries, but not entirely. I would like to present my journey with quadrocopters, or drones in general. I first started to invest in drones when I was at my university. The passion developed in 2012 when I was defending my Bachelor’s degree and I decided to make a thesis about it. The topic was ‘Filtering and validation of measurements from accelerometer and gyroscope in Matlab/Simulink for a quadrotor flying robot’. In this blog post, I will tackle different aspects, namely software and hardware (mechanics and electronics).

This blog post is a bit different from the others. This is mainly due to the fact that I would like to present you my journey with a drones, especially with quadrocopter.

The first time I thought it might be fun to create something that flies was around 2010. Around that time, I decided to build a quadrocopter. At that time, it was not as popular as it is now. As a very first attempt, although a conceptual one, was to use Atmega8. However, I had little memory of what I had in the plans. Then I looked at Atmega32. However, it came in DIP-40. The package was too big. Then, my attention was caught by Atmega328 which was a revised version available in the same package as Atmega8 but with more Flash memory. I thought it was, but I discarded that idea and I am glad I did. Do not understand me wrong, I spent some time with Atmega8 writing drivers for e.g. HD44780 LCD driver in assembly, but fortunately it did not stick. For a few years before that I was playing around with Atmega and obviously it was my first choice. I started looking for something more powerful because I had “big” plans. It was about that time that I came across STM32 microcontrollers. Oh my! It was something, I could use advanced timers, the clock frequency was much higher, and there was DMA! At that time, I focussed on STM32F103C8 or CB. I don’t remember which one it was. I did some testing; although it was based on ARM Cortex-M3, it did not have hardware support for floating-point operations. That was not an obstacle because now the higher 72MHz clock compensated for that. It was the first time that I did not have to worry about performance and doing fixed-point calculations. I went with floats at full speed. Soon, it turned out that basic flight controller implementation was not a big deal.

The first flight controller implementation was pretty simple and very limited. I knew I needed these functions to take my UAV in to the sky:

• input signal acquisition and filtering,
• PID regulator,
• AHRS system,
• output signal generator.

Input signals

Back then I had a HITEC Optic 6 transmitter and some 40MHz receiver. The receiver gave a PWM signal and what was required to do was measure the duty in order to obtain the controls. I have implemented a ‘chained input capture’ procedure to measure all input channels with minimum impact on the MCU.

PID regulators

As already mentioned, with STM32 and even Cortex-M3 I did not have to worry about fixed-point arithmetic and losing performance. I went with the floating-point implementation of PID. During the first trails, I have realised that a simple PID implementation is not enough. It was mainly due to lack of wind-up. I have added this and some more features, such as filtering the derivative term and the PID controller being ‘usable’, making the drone fightable 😉

AHRS system

This part of the system was basically my pitfall. I tested different approaches; the simplest ones did not work as expected. Finally, I have decided to go with Kalman filter implementation. In retrospective, I can now tell that it was a bad decision. You might ask. The answer is not that straightforward. First of all, Kalman filter is a really good fusion filter and works pretty well when it is tuned properly. And this is the requirement, it has to be tuned well, otherwise its performance is not that superior. I have spent a lot of time on this one, but finally with no small amount of effort I was able to make it work properly. Well, my bachelor’s thesis was about it. In my thesis, I was able to compare different filters, Butterworth filter,, moving average, Kalman filter and filter fusion. As it turned out, I even reinvented a complementary filter! I was surprised that a simple fusion of low-pass and high-pass filters can give such good performance.

Output signals

I guess it was the simplest part of this venture. I was generating plain PWM signals which at the beginning were PWM servo signals. However, I wanted to increase the frequency, so I started experimenting. It should be noted that it was not the time for blheli ESCs. If I remember correctly I used SimonK controllers which were capable of working on higher rates. Currently, there are standards that are digital; thus the throttle value is sent in a series of bits. Moreover, you can directly influence the rotation direction or read some telemetry from the ESC like instantaneous current.

Microcontrollers

I have already written that I have considered Atmega for the quadrocopter. There are already projects that build the flight controller based on this platform and it works quite decently. I have decided to use STM32F103C8 or CB. Not long after that, I switched to something more powerful for two reasons. The first reason was quite obvious. I needed more resources, such as Flash and operational memory. The second reason was strictly performance-orientated. I did not necessarily want to go with the STM32F4 family, but I wanted a FPU (Floating Point Unit). Fortunately enough, there is the STM32F3 family, which comes with Cortex-M4 and has a hardware FPU. I went to the ST MCU selector and put some filters and picked STM32F303CC. It has 256kB of Flash and 40kB of RAM, which is plenty. It also comes with a ton of timers and can be clocked up to 72MHz.

There are commercially available flight controllers that are classified by the ST microcontroller families, like F1, F3, F4, and so on. It is easy to identify which MCU is actually located on a PCB or at least know what ST MCU family it is. What is interesting, I soon discovered that the exact same STM32F303 microcontroller was used for F3 flight controllers. Who would have thought?

Hardware design

In addition to writing my own firmware, I also designed my own PCBs. The first boards were manufactured using the ultraviolet (UV) method. Unfortunately, I cannot find any photos of that one. Scratch that :D. I found it! It turns out that I had it in my Bachelor’s thesis. Below you can have a look.

The PCB was mounted on a rotary encoder for data acquisition and testing. Back then, I used IMUs attached to the main PCB as a module. The reason behind it was that I was unable to achieve enough high quality for the QFN type of package, so I needed to use it as modules. However, it was the first and last time. The new versions of the PCBs were designed by me but manufactured by an external company. This way, I was able to put everything on a single board.

It even had a holder for button battery for the RTC clock. Why? I absolutely have no idea 😀

There were several different designs for my flight controller. To be honest, even to this day I still find that some things could be done better and I am in need of additional features.

Here is a first ‘compact’ version of the flight controller.

What you could immediately notice is that there is no IMU sensor; neither on top nor on bottom of the PCB. It was connected via external module.

As it can be seen there was even a micro SD card slot. The card there is outstanding 2GB micro SD card. It was used to log flight data for further analysis.

This flight controller PCB has a build in IMU. It also had different features like barometer, gesture sensor and MEMS microphone. The idea was to use this board for different purposes like control of some external devices or voice activated controller.

However, one of my last designs (the one above) turned out to be a good candidate for a fixed wing controller for my RC planes. When I switched from a PWM based RC receiver to a receiver supporting Fport, it was clear that now I need to have an Fport proxy to facilitate all of available channels. Fport receivers are based on LoRa modules and the small and inexpensive ones have limited number of PWM outputs for RC servos. With the so-called Fport proxy, I was able to access all the PWM channels, thus increasing the number of available channels.

Mechanical design

The story of mechanical design is as bumpy as it can get. The initial designs involved square aluminium profiles. To fit these profiles, they first had to have a cut in the middle to fold them together. To make the connection permanent, I used fishing thread and cyanoacrylate glue. The resulting connection was very strong and reliable (to some extend). Below, you can see a broken frame where it was cut.

Subsequently, I stopped cutting the profiles to fit them together, and it worked well. The connection was also reliable. However, as you might expect, the construction had a serious drawback. It was able to transfer vibrations from the motor quite well. These vibrations strongly interfered with IMU measurements. You might recall a post I wrote about where I used a mechanical low-pass filter made of additional weight and a soft sponge attached to the sensor.

There were other constructions involving plywood in which I attached drilled aluminium profiles with screws that time.

Around that time I finished assembling a 3D printer. Some construction log can be found in another blog post. This was indeed a game changer. I started by printing base plates. You can have a look below. They were to replace plywood and could be printed exactly to the design.

These printed ‘springs’ were really nice fit for this small quadrocopter.

As you might expect, I also started to print a full frame for the drone. There were multiple designs, smaller and larger.

Some had arms printed separately and mounted with screws; others were complete frames. The 3D printer allowed me to test different designs and it was a great experience. However, the frames were not strong enough. After a few crash landings 😉 they had to be replaced. The experiments with different approaches were quite good but still not indestructible.

The next frames I tried were carbon frames available commercially. Despite the fact that they were considerably thin compared to the frames printed with ABS or PLA, they were rigid and unbreakable.

You could make a serious dent or break them, but I have not. Until now I have stuck with carbon frames but I am still eager to make a fully printed frame for a small quadrocopter.

Hope you enjoyed reading this blog. If you have an interesting story about drones, consider sharing it by leaving a comment.