Home
There are a couple of ways to understand a drone build
- Components and Connectivity - What are the components and how are they connected?
- Processes - What is going on and how are the processes affecting each other?
We also go into more detail on the repository architecture as it runs on the general purpose computer.
An example list of materials can be found on this spreadsheet
This code in this repository runs on the general purpose computer. The flight control board runs the betaflight firmware. The electronic speed controllers run the (BLHeli_S firmware](https://github.com/bitdump/BLHeli) that came preflashed.
We can break what's happening into the usual control and estimation formulation.
User Input: The user indicates a desired state for the controllers.
Control: Controllers figure out how to bring the craft to the desired state.
Plant: The physical quadcopter that responds to the lift generated by the motors and propellers, gravity, and external disturbances like wind.
Sense: Sensors measure some aspect of the quadcopter state or the environment.
Estimate: Estimators infer the true quadcopter state from noisy or incomplete sensor data.
The specifics of these processes, specifically of the control, sensing, and estimation depend on the type of flight and what the user is trying to control.
During "acro" flight, the user requests roll, pitch, and yaw rates.
During, acro flight, no computation actually happens on the general purpose computer, it simply forwards commands to the flight control board.
Roll and Pitch are together known as the vehicle's "attitude". During attitude flight, the user requests roll, pitch directly instead of their rates of change. The user still indicates the yaw rate. We add a roll and pitch estimator and controller to carry out the user's command.
In the near future, the drone will have the ability to estimate its position in world coordinates (i.e. relative to its start location).
The software running on the general purpose computer is divided into separate processes running concurrently instead of a single process running sequentially as would happen on a microcontroller. You don't want to run the general purpose computer like a microcontroller. A microcontroller would do a better job of that.
A sequential program would run as something like the following
while True:
read user input data
read sensor data
estimate state from sensor data
compute control output from state
This would work just fine if each step in the program didn't take time to complete. Of course each step does take time to complete, so as we move through the program, the information from earlier in the program gets old and stale. More concretely, we could recompute the control output as soon as any of the user input, or state estimation completes. To do so, we opt for a parallel architecture, now the program is divided into several programs that run concurrently as follows:
# User input module
while True:
wait for user input data availability
read user input data
write user input data to database
# Sensor communication module
while True:
wait for sensor data availability
read sensor data
write sensor data to database
# Control module
while True:
wait for new sensor or user input data
compute new control command
write new control output to database
# Flight control board communication module
while True:
wait for new control command
send new control command to flight control board
Note that each smaller module now has communication to and from a central database, which brings us to redis.
Redis is great. Redis decouples software modules without adding too much latency, allowing you to write software modules relatively independently and even in different languages, say if you maybe wanted to write the communication modules in C++ but a higher level path planning control module in Python.
If redis doesn't scale well to many handle input/output from many concurrent processes, we can consider other interprocess communication strategies and libraries, specifically ØMQ or a raw shared memory interface.
