I spent a good few months working on and off on the drone. Almost every day I’d get a nice little package in the post from China with a component or such like in it. Unfortunately, the last few things I received still sit unused.
After I’d solved the basic architecture of the drone system in as far as how to get easily updatable algorithms both on board and on the ground, things got harder. I made initial rapid progress building the drone using fairly standard hardware and getting a software framework in place. Then it came to testing and fine tuning.
As a basis for further development I wanted a drone that could reliably take off and hover a small, safe distance from the ground. This proved much harder than expected. After analysing the C source code for Cleanflight I created a PID loop for altitude hold. Using both the barometer and the ultrasonic sonar (HC-SR04) I attempted to get a reliable altitude value. Even this proved hard as both sensors have their limitations.
The barometer in the NAZE32 is accurate to a few centimetres but this goes out of the window when the pressure changes caused by enough thrust to lift 600g of drone off the ground start. I calibrated an offset curve based on thrust and this helped but there are always phase differences caused by the delays between reading the sensors. Another problem with the barometer is that it drifts quite fast due to weather conditions though this is fairly easily rectified by reseting calibration before takeoff.
The ultrasonic sonar also has severe limitations. Firstly it is quite slow to read due to the speed of sound. It requires accurate timing to ascertain correct readings and this is hard on a raspberry pi without a realtime operating system. Another limitation is that it returns unreliable readings without any measure of error if the reflecting surface below isn’t perfect. Lastly you need to use a bit of trigonometry to workout the vertical distance to the ground when the drone isn’t perfectly horizontal. Again this suffers from phase differences between reading the drone orientation and retrieving sonar distance updates.
Overall the fusion of these two sensors with their limitations and noise require some sophisticated mathematics, Kalman Filters - not something that I have much experience in. I did try but the roundtrip time between the laptop to update code, charging the LiPo batteries and heading back to the trampoline testbed was too long. Also, the stakes where high - worst case the drone propels itself vertically, out-of-control into the sky only to disappear or drop hard destroying it. Less bad but more frequent was drifting into the netting at the side of the trampoline, getting a blade trapped and toppling to the (soft) base to smash another blade or two.
Another input into the altitude calculation is integration of the acceleration sensors onboard the NAZE32 flight controller. These are very accurate and low noise but even so integration rapidly introduces cumulate error as you need to integrate once to go from acceleration to velocity, and then once more to integrate from velocity to position. Things like this really make me think about the Theory of General Relativity - why does the universe only allow us to directly measure acceleration but not velocity or absolute position?
Things get worse, i.e. the errors are amplified when an unreliable altitude reading is fed into the PID controller. The drone starts with no knowledge of how much thrust is required to balance against gravity. This depends upon factors such as the drones weight and the voltage from the battery. Rapidly determining a hover thrust is critical to stable functioning. In steady state it’s easy and quick to determine the correct thrust by comparing thrust levels against vertical acceleration (usual sensor reading phases differences not withstanding). The balance point of the drone for hovering feels like a knife edge between free fall and just over 1G acceleration upwards with full battery. Both of these are equally scary when you have many, many hours of work waiting to destroy itself.
The lesson I have learned is that pure software is so much easier. Usually the stakes are low in that you can easily create a test and development environment, and you can learn in a safe place knowing that bugs and misunderstandings can be corrected with nothing lost but time. Hardware and real world is not so forgiving.
If you want to give something like this a go then take a look at the code I created in GitHub.
I hope to get back to this project as some stage but for the moment it gathers dust.