The most dangerous part of your multicopter is the software.
Ask anyone what is the most dangerous part of their multicopter/aircraft, the chances are they’ll tell you the propellers. Whilst that is an understandable reply, it is wrong, the real danger is the many thousands of lines of computer code in your flight controller that will definitely have some bugs.
Every day you use systems tested by entire teams of testers.
Whilst you may not realise it, every system you interact with in your daily life has been tested, typically by teams of testers at various stages whilst the system has been developed, for example, the mobile phone in your pocket, the mobile network it connects to, the web browser you use and the web services you interact with.
As multicopters can injure people, the importance of software testing for flight controllers cannot be stressed enough.
Every piece of software has some bugs.
Every piece of software has a degree of bugs, software testing is not there to produce bug free software as that aim is all but impossible, it is there however to identify and remove the most serious and most obvious bugs.
There is every chance a software bug could injure you.
Every time you plug your battery into your multicopter it is the software code that is stopping those razor sharp carbon fibre propellers from arming and slicing into your buttery soft skin.
In fact here is a snippet of code from one flight controller controlling just this behavior:
So be in no doubt the moment you power your multicopter, your safety and the safety of those around you all depends on the code in your flight controller having been thoroughly tested, your multicopter is a flying chainsaw capable of making an unsightly human smoothie.
If you find that new firmware releases of your flight controller introduce serious or obvious bugs, especially if this happens time and again it is a clear sign that proper software testing is not taking place, in a nutshell it is time to consider changing your flight controller.
SDLC the jargon you need to know.
Now for the boring part, but hold on, don’t go away as we’ll keep it simple…
Testing is an integral part of an SDLC (Software Development Life Cycle), software coding is a structured process that is delivered following one of many available methodologies, any reputable company delivering software should be following a methodology and should have that audited, there are recognised accreditations for meeting such audits. In simple terms it is a process and set of rules that should be followed.
A poor Release Note/Changelog should ring alarm bells.
Part of the SDLC is providing a release note, this should be complete, i.e. nothing should be added or removed from the firmware without it being in the release note, if you spot features being added or removed without appearing in a release note then change to another flight controller as it is a sure sign of a slack and dangerous disregard for process.
A release note should always detail bug fixes and where present, new features, both should be clearly separated so as a user you can make an informed choice about whether to apply a firmware release or not.
Flying in manual mode will not save you.
In your modern flight controllers flying in manual will not necessarily save you from serious software bugs, the manual mode is really a pretend manual, in effect there is less interaction with your inputs but there is still code being executed.
Finally, complacency can kill.
To date the multicopter industry has been fortunate in that there have been no deaths, incidents involving injuries are few and relatively minor, but if users continue to accept poor software the inevitable outcome is an incident that will be serious, do not accept bugs, challenge manufacturers, challenge them in public, on forums, on Twitter as well as via e-mail.
