Fully redundant drone

Hi everyone!

I'm doing this commercial project where reliability is a MUST. I'll be investing a lot of money on top-notch parts, but I had enough mishaps (and read about many more here) to know that even great motors get out of sync, and great ESCs fail, brownouts can happen, issues with the power module, GPS glitches, RX/TX glitches, etc, etc...

Given my background in IT infrastructure, I believe the only way to have any hope of real reliability is through redundancy (at least as far as the machine is concerned). So I set out to design a multirotor that can stay in the air if any of the parts fail (except of course for the Pixhawk or an Arducopter bug)

I thought I'd run this design by you guys and see if you can find any flaws with it or something I could improve.


See my diagram below:

3691158325?profile=original

- I'm thiking of going with a custom-built X8 frame with coaxial motors. That by itself should add considerably to the reliability, given that most hardware faults are ESC/motor related. To make up for some of the loss of efficiency on coaxial props, I'll use slightly larger diameter and pitch props on the bottom.

- As the diagram above the 4 top and 4 bottom ESCs will be connected to redundant power distribution boards, even if one of them fail (unlikely, I know) the X8 will become a quad and it can land safely.

- I'm also using redundant power supply to the Pixhawk via both a power module (connected to Lipo A) and a BEC from one of the ESCs (connected to Lipo B). This should prevent brownouts from causing crashes.

- I'll be using redundant GPS modules (one of them with a compass). This should give me redundancy in both the GPS and compass, since the internal compass was activated in 3.2.

- I'm also thinking of extending the redundancy to TX/RX by using both a regular FRSky TX/RX while having droid planner remote control connected and displayed on a Nexus 7 mounted to my TX. This way I can turn off the TX in case of glitch and use the droid planner virtual TX feature. This should also help me in case of bad interference on 2.4 Ghz, because the telemetry will run on a completely different frequency.

- Power everything through two high capacity lipos. One connected to the power module, and the other to the secondary PDB. Both with their balance leads plugged into a voltage alarm set to 3.6v.

I know this is a bit of an overkill for most applications, but this project will depend on the reliability of the craft.

So what do you guys think? What would you change about it? Looking forward to listen to your feedback :)

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • I think this is a valuable topic although my comment is not direct germain to your project. Since sensors are so cheap these days why not use three of everything and a voting system? Devs are wrestling with what to do with two gps, why not add a third to determine the failed unit?

    Then three flight controllers with an election system for master.

    We need to move to higher reliability to get real work done.

    • @Mike - I agree that drones need to become much more reliable before they can be really useful. However, there is a difference between system performance and system reliability.

      The issue with GPS is that the performance is inadequate to ensure that a drone never flies into something (like the ground). It doesn't make any difference how many of them are polled, chances are that they will all suffer from the same mode of failure at the same time, such as losing satellites when flying near a building, and they can't prevent the drone from flying into obstacles. This is a problem for a high reliability system because the data from the GPS cannot be considered as "reliable" since it doesn't inherently prevent the drone from crashing. It can only be used, when available, to establish the approximate location of a drone and is therefore part of a navigation system, not part of a critical safety system.

      In industrial plants, the rule for reliable sensors and control systems is that they must inherently prevent the plant from getting damaged or blowing up. In addition to these, other sensors and systems will help to improve plant efficiency. Insurance companies don't care about the efficiency related systems since they generally tend to push the plant closer to the edge of failure rather than making it safer. Instead, they charge premiums based on how good the safety systems are that prevent damage and loss of life.

      One of the key characteristics of a reliable sensor is that it directly measures the phenomenon that affects safety. Using the GPS again as an example, it doesn't measure how far from the ground a drone is and therefore it is not considered to be a suitable sensor for detecting and preventing drone crashes. Instead, sensors based on radar, laser, ultrasonics, stereo vision and so on do directly measure the distance from the drone to the ground and can therefore be used in a high reliability system.

      IMHO, the biggest problem facing the non-military drone industry today is a lack of understanding about what makes a drone fly reliably. The idea that cheap barometric altimeters, accelerometers and GPSs make a reliable drone is fundamentally flawed. Drones need to be reengineered from the ground up so that each system and sensor first and foremost prevents crashes. Thereafter, the commercial mission becomes so much easier :).

      • The GPS is a valid example because the Devs are trying to determine how to evaluate which GPS has more valid data when two are used. These days I use two different GPS one with the US satellites and one will all the other satellites to gain some differential.. But the only reason MR are popular today is because of the cheap sensors. We have a limited availability of tools and using entirely different systems for backup is nice but not practical from my seats. But the sensors we use are cheap enough to add three to get a consensus as to whether the data is valid or not.

        What Hugo was after is valid as an attempt to start solving the problem.

  • You could do a bit of overkill and add LTE...

  • Hi Hugo,

    knowing that this is an old topic, but eager to know what the status of your project is?

    I am building an redundant setup also (and yes, I have been in IT to long also) and trying to have not a SPOF...

    Thanks,

    Pascal

  • Hi Hugo, taking this opportunity to punt our own products for a moment - we've done some high rel work for both industrial and aircraft applications and one of the key requirements for SIL rated systems is to use a different technology for the backup system. The argument is that if the same technology is used for both the primary and backup systems then it is more likely to suffer the same mode of failure. We sell a lot of laser altimeters to critical system applications, and many installations use two barometric altimeters AND two laser altimeters. That way you get technology robustness, failure redundancy and statistical confirmation based on 3/4 or 2/3 results.

    • Hello Laser Developer,

      Nice info, so the SIL rated vehicle that use one of your products will also use another laser from a different manufacturer for redundancy ?

      • @Paul - No. It has to be a different type of technology altogether. For example, GPS altitude, barometric altitude and laser altitude represent three different types of technology that provide independent altitude measurement. Using all three would be the minimum necessary for a high reliability design but some people double up on each of these so that they can handle single sensor failures as well. 

    • I have been considering sonar or other more accurate way of altitude measuring than the barometer. But my project will have a payload underneath that is likely to get in the way of whatever signal is emitted, no way around it, really. Thanks for the suggestion.

This reply was deleted.

Activity

gotham liked gotham's profile
15 hours ago
DIY Robocars via Twitter
RT @RoboticMasters: Monaco GP Circuit in the Donkey Sim (coming soon). Including buildings, tunnel and all! https://github.com/robotics-masters/sim-donkeycar-f1/tree/f1-tracks @diyr…
Wednesday
DIY Robocars via Twitter
RT @breadcentric: Here are the details of #AWSDeepRacer finals: https://blog.deepracing.io/2020/12/01/aws-deepracer-league-finals-2020-round-1-schedule/ #awsreinvent2020 #AWSreInvent https://t.co/ovqsjp8V…
Wednesday
DIY Robocars via Twitter
RT @breadcentric: #AWSDeepRacer League #awsreinvent2020 Open race is on Dec 1st - Dec 31st in three categories, 15 DeepRacer Evo (with LIDA…
Wednesday
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars It's just something that's easy to track with chroma keying. I ended up using different colors on th…
Monday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @TinkerGen_: "The Tinkergen MARK ($199) is my new favorite starter robocar. It’s got everything — computer vision, deep learning, sensor…
Nov 23
DIY Robocars via Twitter
Nov 23
DIY Robocars via Twitter
RT @roboton_io: Join our FREE Sumo Competition 🤖🏆 👉 https://roboton.io/ranking/vsc2020 #sumo #robot #edtech #competition #games4ed https://t.co/WOx…
Nov 16
DIY Drones via Twitter
First impressions of Tinkergen MARK robocar https://ift.tt/36IeZHc
Nov 16
DIY Robocars via Twitter
Our review of the @TinkerGen_ MARK robocar, which is the best on the market right now https://diyrobocars.com/2020/11/15/first-impressions-of-tinkergen-mark-robocar/ https://t.co/ENIlU5SfZ2
Nov 15
DIY Robocars via Twitter
RT @Ingmar_Stapel: I have now explained the OpenBot project in great detail on my blog with 12 articles step by step. I hope you enjoy read…
Nov 15
DIY Robocars via Twitter
RT @DAVGtech: This is a must attend. Click the link, follow link to read the story, sign up. #chaos2020 #digitalconnection #digitalworld ht…
Nov 15
DIY Robocars via Twitter
RT @a1k0n: Got a new chassis for outdoor races (hobbyking Quantum Vandal) but I totally didn't expect that it might cause problems for my g…
Nov 11
DIY Drones via Twitter
First impressions of the Intel OpenBot https://ift.tt/36qkVV4
Nov 10
DIY Robocars via Twitter
Nov 9
More…