Loading

Safety first : A guide to robust autonomous flights

December 20, 2016 by Eva Pagneux
Share on facebook twitter

Not having to pilot a drone is a key component to drone commercial and consumer usage. We’ve seen more and more solutions taking-off, however raising some safety concerns when there’s no pilot in cockpit. We’re sharing here 3 good practices of our development process that allows Squadrone System to guarantee reliable, robust and safe flight.

On our first project, called Hexo+, the first self-flying camera for consumers launched in 2014, one of the biggest challenge to bring the first drone that is NOT piloted to the public was to ensure that it could actually fly reliably without the user’s intervention, never requiring piloting skills. Getting a fully autonomous system means that you need to trust the technology (hardware + software) and rely on sensors.

 

True autonomous systems required qualified sensors

Taking care of the basics sensors and material drawbacks is more complex than it seems. We faced many sensor limitations and issues during the development of Hexo+. In the civil aeronautics field, the best sensors are selected for their reliability and extremely good performances. Nevertheless, those sensors are very expensive, heavy and redundant, not suitable for a consumer facing product aiming at making aerial filming accessible to all. We therefore looked at consumer-affordable sensors, delivering acceptable performances, but with some limitations that have to be known.

When controlling the drone with a remote control, the human pilot always counteracts the drawbacks of the sensors of the drone. For instance, it is known that compass typically drifts while in flight. Under RC operations, the pilot constantly controls the yaw of the drone to maintain its heading and the performances of the system are not affected. In a fully autonomous system, a compass’ failure induces the drone to perform fast and large circles (called toilet bowl effect) leading to serious crash and potential damages. The same observations can be made when a motor is getting lost on the system, when a propeller is broken, when any other sensors is not perfectly working. Truly autonomous systems need to rely on sensors and have capabilities to counter-act in case of sensors failure.

Sensors and material limitations are one component to master in the development of a safe device, unfortunately they are not the only items that can go wrong on an autonomous system, that’s why we took it to the next level.

 

Risk analysis – anticipating the worst case scenario

At the origin of the development, we built a risk analysis matrix, with a description of the risk, the likeliness to happen, the consequences of it happening to make the inventory of all possible safety issues a user can encounter.
From a sensor failure, to motor breakdown to GPS loss, worst case scenario have been tackled by safety features implemented in the drone and the app, they’re called Failsafe behaviors.

dfdfdfdfdf

 

At Squadrone System, we are convinced one of the key of adoption is the robustness of the system. Indeed, to make a technology acceptable to use around your family, your property, your business, people need to build trust in the system, that is why creating safe and robust drones has always been at the heart of all our developments.
Our background in developing critical software for aeronautic applications allows us to be extremely aware of the failures possible and able to anticipate them. We leverage this experience to build fault tree analysis in our evaluation of risks, foundations for the construction of reliable hardware and software systems.

Continuous test through development

According to Les Hatton, professor at the University of Kingston in London, problems linked to programmation errors cost up to 150 billion Euros per year, in Europe only, and as we embed more and more code into systems to make them smarter, this number will rather increase in the coming years.
Once some features are programmed, all the code is run on a simulator inside the company. When it gives satisfactory results, those software tests are then always run by the simulator thousands of time and it is time for real external tests to validate the real behavior of the feature. We conduct both unitary test, where each functionality is tested individually, and integration tests to make sure the development executes as planned without affecting the rest of the code. Finally, global validation tests are performed by our test team. The objective is to validate the whole behavior of the complete system, looking at the potential interactions between all the functionalities. We apply a thorough real life tests methodology, testing each individual feature on a multitude of cases and locations, then combining features and errors to test the reaction of all behaviors together.
A study led by RMIT University School of Engineering and published in Aerospace states that researchers looked at 150 reported incidents between around 2006 and 2016, and found that 64 percent of incidents were because of technical problems. In most cases, they found that broken communication links were to blame.

By applying a detailed and intense real life testing phase, our methodology has proven to bring up some issues that we wouldn’t want consumers to experience. With drones, it’s always better safe than sorry!

Developing a complete intelligent systems requires deep understanding and mastering of all the components of the system. Taking the time to anticipate all scenarios, especially the worsts, and thoroughly test the whole solution in different situations ensure a safe and robust system, dramatically improving user experience and eventually, allowing all drones opportunities to take off.