How I Developed the Scout Flight Controller, Part 10: Future Improvements

This article is part of a series documenting the development of a custom quadcopter flight controller from scratch. For a list of the other related articles, please refer to the introductory article found here.

And just like that, you can build your very own quadcopter flight controller firmware, just as I covered in the previous ten chapters in this series.

I’m very proud of what I accomplished in building the Scout flight controller from the ground up. However, especially compared to the modern day consumer drones like those made by DJI, my combined hardware and software package is quite rudimentary! There are many improvements/extensions I’d like to add to the design in future iterations:

Angle Mode

In the previous chapter on quadcopter flight dynamics, I explain the two primary modes that a multicopter flight controller can operate in: rate (or “gyro”/”acro”) mode and angle mode.

When a multicopter is in rate mode, its goal is for the aircrafts rate of rotation across each of the three axes to match the pilot’s desired rate of rotation across each axis. In other words, in the absence of any pilot input, the quadcopter will dynamically vary the level of thrust to each of its motors to continue maintaining the aircraft’s current orientation. As the pilot applies pitch/roll/yaw input, the motor thrusts are adjusted to achieve the desired rate of rotation.

When a multicopter is in angle mode, its goal is for the aircraft to achieve and maintain a specific angle to the ground, as specified by the pilot. In the absence of pilot input, the quadcopter will recover from an angle and attempt to maintain a perfectly level orientation to the ground (parallel to ground). As the pilot applies pitch/roll/yaw input, motor thrusts are continuously adjusted to achieve a “translated” angle to the ground.

The Scout flight controller I developed implements the rate mode scheme. While this mode is viewed as the more “advanced” form of flight and is preferred for performance-oriented pilots, it is far from easy to use for a beginner. Angle mode is far easier to pick up and intuitively understand, and the “if you take your hands off the controls it will level out and not crash” is a tremendous “safety” feature.

The reality is angle mode is significantly more complicated to implement. While the actual code may not be tremendously different (perhaps another 100 lines), integrating noisy accelerometer data into the equation (rate mode only uses gyroscope while angle mode uses both gyroscope and accelerometer) could be daunting.

In future iterations of my flight controller, I’m hoping to have both rate mode and angle mode built in. The pilot can use a toggle switch to switch between the modes either while stationary or perhaps even during flight.

Battery Voltage Indicator

As mentioned in the previous chapter on taking flight, Scout has no means of knowing the state of charge (battery level) of the onboard 4S LiPo battery.

This isn’t a problem for the small controlled flights I took my quadcopter on. But for anything more, a battery level indicator would be very important. A simple inexpensive battery voltage indicator could be installed onboard that constantly monitors the voltage of the 4S battery pack.

Firstly, a battery level indicator would make the quadcopter significantly safer. During small test flights, my battery completely lost power two or three times. I found that performance degrades for a short period of time and then suddenly the power goes out completely and the quadcopter tumbles out of the sky. With such little (or no) notice, this is a safety hazard. By knowing when the battery gets to dangerous levels (i.e. below 20%), I would know when to ground the aircraft to avoid any hazards.

Secondly, by knowing when to land the drone due to low battery, I’m preserving the life of the 4S LiPo battery. By discharging to extremely low levels like I originally was (below 12 volts on 4S), I’m reducing the potency and lifespan of my battery.

Position Hold

Along with the addition of the angle mode mentioned above, greater “autonomous” capabilities would be of value. More specifically, the components required for a sort of position hold capability. In my Scout Flight Controller, the only consideration that the flight controller makes when determining what level of thrust to apply to each of the four motors is the rate of orientation (attitude) change. If the quadcopter is also aware of its position in space (latitude and longitude) and altitude, we could also develop a program that would use these as inputs as it aims to maintain a position in three dimensional space.

First, the quadcopter would need to know its location — latitude and longitude. For this, it would need an onboard GPS module. GPS modules are inexpensive today and easy to work with. The primary challenge here would be getting a latitude and longitude with precise accuracy. The inexpensive GPS modules are fairly inaccurate (off by a meter or more at times) at their best. This would be unacceptable for this use case. A high-resolution GPS module would be required that is capable of accuracy of perhaps a foot or two at the very most. I have not investigated, but there must be a way to accomplish this with either A) a higher-resolution (probably higher cost) GPS module or B) mixing together signals of multiple GPS modules to get an accurate “average”.

Secondly, the quadcopter will need to know its altitude. An inexpensive barometer can be used to determine the ambient pressure the quadcopter is experiencing and this can be converted to an altitude. Similar to the GPS accuracy problem, I’d imagine it would be challenging getting an accurate enough reading within a few inches of altitude.

With both an ability to know its latitude, longitude, and altitude, we could, in theory, develop a program that also strives to maintain a specific point in 3D space, similar to what DJI and other drone companies have done.

Dual Flight Controller/Flight Computer System

The Scout flight controller is a Flight Controller. A flight controller is a system that is purely intended to run a high-speed program that routinely and rapidly determines what levels of thrust to apply to each motor to stay airborne and comply with the inputs of the pilot.

A flight computer is a system built on top of the flight controller and inputs commands into the flight controller. While a flight controller is purely focused on staying airborne and stable flight, the flight computer operates at a “higher level” and can be focused on things like obstacle avoidance, position hold, waypoint missions, communications with ground, etc.

Nicholas Rehm has a fantastic video explaining the differences on YouTube:

https://www.youtube.com/embed/PlKeFj5teo4?si=6MCRu-3CqqTsBLAI

As a future project, I’d like to develop a dual system. While the flight controller code would not need much of a change (Scout with some alterations), a flight computer would directly integrate with the flight controller and control things such as position hold, radio communications, telemetry capture, etc. All of this is currently not achievable on the flight controller alone due to resource constraints (needs to run quickly, not enough processor speed headroom to support).

Controlled Landings with Ultrasonic Range Finder

Many modern day consumer drones, including most made by DJI, have an ultrasonic range finder on their underbelly. This range finder is capable of measuring distance to objects below the drone (the ground) and use this measurement for controlled landings. When in a certain proximity to the ground (say, 5 feet), the maximum speed of descent is lowered and continues to lower as the drone gets closer. This allows for a more controlled and precise landing.

With the proximity to the ground (altitude measurement at low altitudes), controlled landings, and perhaps a form of altitude hold, is achievable.

Communications

As discussed in depth in the previous article on the RC controls, a radio transmitter and receiver is exclusively used to control the quadcopter.

This means that the only transfer of data between the ground and the aircraft are control commands. As the drone system becomes more sophisticated (features described above are introduced), the ability to maintain data communication while flying would be massively beneficial.

During flight, the drone can transmit data such as telemetry, battery level, etc. Conversely, the pilot, using another system, can deliver various commands beyond just roll, pitch, yaw, and throttle. For example, the ground can deliver waypoint mission commands for the drone to follow.

Without investigating heavily into how this could be accomplished, it seems that Bluetooth may be a solution. While Bluetooth would only allow for this communication in close proximity, it is a well-understood protocol that is also commonly implemented and available in microcontrollers/computers.

Running Lights

Running lights onboard the quadcopter will assist with navigation and also look very cool. A simple strand of WS2812B individually addressable LED lights will be plenty. The drone’s flight computer could also use this to transmit messages optionally as well.

Next Chapter

Next, along with sharing all of the code required in this project, I’ll share some bonus code — code that I never ended up using but can easily be used in other projects.

Thanks for reading on!