Hi,

 

Open source autopilots are widely used in the RC toys. I tried 3DR's pixhawk. It seems to be quite okay. There are also other open source autopilots.

The commercial autopilots are always used in commercial unmanned aircraft. They are somehow much more expensive than open source. I’m wondering what are commercial autopilots’ typical advantages compared with the best open source autopilots for conventional fixed wing usage. Could anyone give any hint on that?

 

Best,

Anna

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

Join diydrones

Email me when people reply –

Replies

      • Thanks, Gary.

        Shall I say that the commercial autopilot typically won't have more advanced algorithm than open source autopilot?

        What is commercial autopilot company's work? Just directly using or slightly modifying from the algorithm from open source, purchasing reliable hardware, assembling hardware with good quality control and making it easy to use?

        Would you classify 3DR's pixhawk as cheap board with poor installation and having fail rate significantly higher than commercial autopilots?

        • I've only worked with the non-commercial variety, most recent Pixhawk and some APM2, but am using these in an industrial environment. I'm by no means an expert, especially in commercial APs, but share some thoughts.

          I don't think there are Open source commercial grade APs. This seems sort of like a redundant sentence, but I wonder why? The commercial AP environment I think by definition must be somewhat more "quality controlled". This is not to say the the non-commercial don't have some kind of quality control in their root development environments. However with Open Source, you open yourself to uncontrolled modification. Anyone can take the "source" and do whatever he wants. This of course opens the field for uncontrolled error.

          The "legislation" of course points ever more towards safety, control and certification for authorized commercial operations.

          However, a comercial operator obviously thinks "business". This means that consistency, safety, and performance are most important. The true commercial operator, maybe because of the laws, but more because of performance and liability, will put great efforts into utilizing the best he can find.

          In our operations, that means having a professional team from the ground up. Others perhaps rely more heavily on base equipment.

          With our approach, we are certain we can obtain the results we desire. We know the weaker points of our equipment and focus on efforts to circumvent failures and adapt the product to the task or probably more correctly the task to the product. As mentioned here, APs like Pixhawk are very solid in themselves. Perhaps they don't have quadruple redundancey or mil-spec sensors, but the Open source invironment provides 1) a robust development community resolving problems associated with this "shortfall" and 2 ) opprotunity to go in and hand pick our own adjustments if we don't like the direction the open community is taking. And although the margins are usually larger in the commercial field, having a lower cost hardware component, opens development opportunities that might not otherwise be available.

          If I produced a commercial grade autopilot, I wouldn't feel too comfortable throwing it out to the general public. It's my name and my reputation, which could be thrown into any piece of flying junk. As a matter of fact, our autopilots ONLY go into our hardware.

          So a commercial grade autopilot, especially if it is to be sold to the general public must manage a considerable number of safety considerations, not necesarily because it is of inferior physical quality, but more because it must face an uncontrolled and uncertain operational environment. Furthermore, because it is closed source, it enters a very complex configurability environment.

          The non-commercial APs obviously expect to face the same challenges except that 1) commercial performance is not paramount, and customers are far less demanding shall we say legally, and 2) Open Source permits specific configurability, so extensive configurability doesn't have to be built in and of course the customer is much more flexible.

          As I mention, just thoughts. Personally I prefer to work with something I know and understand, and adapt it to my standards. I know it must be used in a completely professional environment and dedicate the effort to assuring solid reliable platforms and failsafe software.

          Others, just prefer to pay for this ready made. But rely heavily on "others" to support and maintain.

           

  • I have done a fair amount of research on this subject. What my findings have shown is that even the very best grade of the Hobby Level AP have about 25-35% failure rates. The electronic components used are not milspec grade or of the higher grade components that perform and have very low failure rates. The cheaper AP's are even worse. No one makes much of a big deal about it since the price is so reasonable to begin with. Then when you jump up to a more professional grade and about 10x the price they don't fail and come with all kinds of warranty replacement, firmware upgrades, updates and extended customer service. These of course are NOT open source either. This is the other biggest difference.


    • Hi John,

      Well, I haven't done research, I've just been flying the things, and from 4 x APM 1.5 OilPan, 3 x 3DR APM 2.5, and 2 x APM 2.7 clones, and not a single failure as such.

      I've crashed quadcopters twice, once a propeller came off, once a power lead came loose.

      I had an incident with a quadcopter where I fitted a new camera, that badly interfered with my RC link.

      I've crashed three fixed winged aircraft, twice for forgetting to connect the pitot, once due to taking off before GPS lock.

      All of the above APM's are still functional.

      I've destroyed an APM 2.7, because of fiddling with an OSD, and reverse battery connection.

      So, once you take the fool out of the equation, a pretty good record, nowhere near your 25-35% failure rate.

      This is just my experience.........

    • John - if the primary difference is failure rate of the AP, is it possible to add a second AP as a "backup" that could take over in case of failure?
      • Yes. I know at least one commercial AP supports this. I heard about Pixhawk has it but it's not mature yet.

      • if you check out deep into Pixhawk , you can see we are heading in that direction.  :)

        - however, a true sanity check is difficult.

        Anyway: after reading logs and looking into problems for a few years, seeing operations of different companies, I can say that AP failure is *not* - even remotely, the main cause of crashes.

        Bad planning, bad setup, clueless tuning is .   There are lots crashed due to misconfigured failsafes, or bad understanding of simple airmanship, poor workmanship, bad soldering and other things that are barely hanging together, mounted with tape and glue.   How many do have redundancy on elevator ?  - how many does have current limiting per channel ?

        Then you have all the "best practice" vs "bare minimum"  differences.

        - if a flap-servo fails, and it continiously draws 5-6A  , will it's servo cable melt, and you loose all servo power, or  will power be cut to that one servo  after passing 4A for 1s  , and if it does, do the pilot have experience to know the symptoms and retract the working flap before it's too late ?

        Pilot error, both during mission planning and setup, is the biggest cause of mishaps.

        • Thanks for your experience. It's helpful. Any statistics or research to show the main cause of the unmanned aircraft crash? I'd like to read it.

          • The #1 cause of unmanned aircraft crash is user error, not hardware failure.  And it's by a very wide margin.

            I really don't know John Smith gets his statistic of 25-35% failure rate.  That's not even a useful reliability statistic, which makes me wonder if the data was actually collected properly.

            Reliability is commonly measured in Mean Time Before Failure.

            If one were to assume a 30% failure rate, it makes a big difference if that 30% is in the first hour, or after 1 million hours.  This is why reliability isn't measured this way.

            And I can tell you, that the failure rate of Pixhawk in the first hour is nowhere near 30%.

            • i agree with Rob, ive been using the pixhawk (after learning on apm) and I have only had successes, never a failure- 25% seems way too high- and I am truley amazed at the versitility and ability of the open source system. which of course is always getting better thanks to the contributers!

This reply was deleted.

Activity

DIY Robocars via Twitter
May 15
DIY Robocars via Twitter
May 14
DIY Robocars via Twitter
May 13
DIY Robocars via Twitter
RT @f1tenth: Say hi to our newest #F1TENTH creation for @ieee_ras_icra next week in Philly. It’s going to be huge! 😎 🔥 @AutowareFdn @PennEn…
May 13
DIY Robocars via Twitter
May 11
DIY Robocars via Twitter
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Noticed my car zigzagged in last run. It turned out to be the grass stuck in the wheel and made the odometry less accura…
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Test my car. RTK GPS worked great. Thanks @emlid for their support. https://t.co/EkQ6qmjmWR
May 8
DIY Drones via Twitter
RT @chr1sa: @kane That's @diydrones circa 2009. Still have a box of those Canon cameras that we used to strap into planes, just like this.…
May 3
DIY Robocars via Twitter
RT @chr1sa: Our next @diyrobocars race is going to be outside at a real RC racetrack in Fremont on May 28. Fully autonomous racing, head-to…
Apr 30
DIY Robocars via Twitter
RT @f1tenth: Our Spring 2022 F1TENTH course @PennEngineers is coming to an end with a head-to-head race as a big finale. So proud of our st…
Apr 26
DIY Robocars via Twitter
RT @DanielChiaJH: I wrote a thing! Throughout the development of my @diyrobocars car I've been using @foxglovedev Studio to visualize and d…
Apr 23
DIY Robocars via Twitter
RT @SmallpixelCar: My new car for high speed. Low body, everything ( @NVIDIAEmbedded Jetson Xavier NX, @emlid RTK GPS, IMC) under the deck…
Apr 23
DIY Robocars via Twitter
Apr 21
DIY Robocars via Twitter
RT @f1tenth: F1TENTH Race training setup @PennEngineers for our upcoming ICRA2022 @ieee_ras_icra competition. @OpenRoboticsOrg @IndyAChalle…
Apr 21
DIY Robocars via Twitter
RT @fatcatFABLAB: Proud to be hosting a restarted DIY Robocars NYC Meetup April 26. Come by if you want to talk about and race self-driving…
Apr 17
More…