AP-Manager is a board available now that allows switching between two Pixhawks or APM autopilots:
Product Description
The requirements for the operation of unmanned aircrafts in commercial and semi-professional purposes have changed fundamentally in the past years in Europe and worldwide. ( FAA ) The regulations will get even more strictly in the future.
Depending on the application, the weight, the purpose, the situation, the flight area, spectators and some more reasons, SAFETY is becoming increasingly important.
Single point of failure and redundancy became the keywords for permissions and certifications from authorities and insurances.
Among other parts inside a system, redundancy of the autopilot system is meanwhile mandatory to follow the rules. Especially multicopters are very instable in their flight characteristics when it comes to malfunction of the stabilization system.
We therefore developed a redundancy circuit board which is an automatic monitoring and controlling bridge between two independent running autopilot systems, a mutual protection in case of malfunction in an autopilot system. Even if both autopilots fail (power supply, freezing controller…), the forwarding of the control signals for a manual flight of the aircraft, Delta or Helicopter is guaranteed.
This system also offers the possibility to switch manually between two different autopilot systems to test different software and sensor setups. Another benefit of the AP-Manager is that only one telemetry module is needed to monitor data of both autopilot systems (except for DJI autopilots, here you need two downlinks, from each autopilot seperate).
AP-Manager is a safe attendant for flying and testing of your unmanned aircraft.
Comments
@Tom: I do not aggree - the single point of is very easy to avoid: simply move the switching logic into the ESCs. Some problems might persist (which FC is right?), but at least you have 6..8 redundant switches and a redundant wiring.
BTW, given that the above hardware is certified: it's a shame that a regulatory body feels competent enough to invent safety requirements, but obviously is unable to recognize if they are violated (the switch is a prime example of an SPOF)
Tom although I can understand the requirements need to be met for various countries, the fact remains that poorly conceived regulations do not make a good engineering solutions...! ;-)
The real risk, regardless of the perception of how technology could potentially mitigate the risk (like this AP switcher), is purely the result of impact of the aircraft with persons or property on the ground. The solution is simply reduce the resulting impact by limiting airframe size and weight, and then for everything bigger add extra controls, that actually have a positive effect, like proper pilot training, maintenance and manufacturer "responsibility" for their product performance to name a few.
This device originated from the regulative need in austria for a complete redundancy. Unfortunately there is no true redundancy for all components in a "multirotor" possible. The regulations require any uav 250g<5000g for any commercial use need a FC/motor/battery redundancy to fly in villages (NOT cities, not village centers... this is another point). Currently there is no RTF solution with all those requirements at reasonable cost (solo, phantom, typhoon...) i won't say it but it could point towards a restriction of uav in general. Even if you want to fly one you need to apply for a certification (insurance, redundancy, pilot name, description of uav...) and it takes 4-6 months to get your certificate which permits 1 year usage. Using a killswitch/parachute system is not allowed but IMHO the single best solution to redundancy and points again to regulations restrictions. Everything combined you now know why the price of this unit is twice as much as a ph and makes things even more complicated with a smaller user base for testing. I wonder who will pay if a huge copter crashes in the middle of a city and the point of failure was this unit...
Best guess is to wait till the EU regulations knock in. Maybe 3DR will at least invest enough resources to provide all information about their uav. Currently the pixhawk/ph2 are rated below the DJI Naza Lite as 3DR did not answer any questions about their product to the officials.
That's not my words, rather the answers from austro-control regarding a possible certification of a ph copter (2kg).
I still think the whole thing is redundant. ;-)
Every tool has a purpose, but this tools purpose is only to provide "confidence" for the uninitiated. Despite how it's perceived or marketed, it's not a redundancy that provides extra safety, rather it produces extra points of failure and potential user error in it's execution.
Orchestrating a failsafe to recover from a faulty autopilot, is up-side-down design and engineering.
Make a more reliable autopilot through superior design, stringent testing and quality control, and reduce the consequence of failure of the whole UAV system to insignificant. This includes the airframe platform used and all of the drivetrain airframe components. The best way to do this is to limit the UAV size say to under 3-4kg, and limit the propeller impact energies. You can't hurt anyone, or anything, if in the first place, the result of a catastrophic failure will not cause damage or harm. Then it doesn't matter if autopilot or human error (which is more likely) is the cause. Further to this, a platform of this size can easily perform most UAV tasks in LOS operations, where nearly all jurisdictions mandate "pilot" control anyway.
<cynicism>
Perhaps much of this technology is about humouring people who have irrational fears (and wield political power). It's a bit like the TSA feeling you up before you board a commercial flight. It probably adds no additional security in an objective sense, but it keeps a bunch of politicians happy because they can point out their "solution" to a risk to the great unwashed.
</cynicism>
This is an interesting addition, simple switchable redundancy is a significant step in making a secure system.
But the approach taken here is quite limited and is subject to single point failure itself that could cause a crash even if both Pixhawks are working perfectly.
A better approach to this kind of system is an intrinsic triple redundant system with voting.
At all times all three identical control units (with independent sensors) are performing all identical tasks and they each verify that the others are producing identical results.
When / if any one of them comes up with a non-identical result it is taken off line and an emergency condition is flagged so the operator can perform a recall.
There are still kinds of failures that can cause an ultimate failure at the output control switching, but the risk can be considerably minimized.
Also since different sensors are likely to produce not quite identical results, some margin needs to be built into the voting process.
But this is the system that Nasa has used since it was using 8080's and Z80's to put payloads and people in space and on the moon.
there were amazingly few failures of this system - probably a good thing!
Best Regards,
Gary
Exactly correct Patrick.
Most estimates put the percentage of crashes due to pilot error at 90% or more. Then you have power system failures. Instances where the operator reports "it just shut down in mid-air", and where the logs just stop, which could be a total power system failure, or an avionics failure, are very very rare.
This could maybe save some code bug crashes, but those are very rare, and in most cases, are better prevented if the pilot was simply familiar with manual piloting skills.
We should all be interested to go step by step into the direction
of certification. That will be a long road.
Thanks Chris for bringing this in.
I have a feeling of déjà-vu on these solution... seem that there is one every few month ?
In commercial aviation, half of all plane crashes are caused by pilot errors. We are talking here of highly trained professionals, so it is easy to extrapolate that in the drone business, the pilot/operator induced error should be a much higher rate. The next common cause is mechanical/electrical systems that accounts for 22% of the crashes. Considering that the autopilot is a subset of electrical systems, and based on what we can read as probable causes : Battery - Connectors - ESC , the autopilot malfunction must be way back in the failure list.
So you end-up adding additional weight and complexity to address a very small percentage of risk.
Is not the idea fundamentally flawed? Because the flight controller is just one element in a fully closed control loop. I see problems having a controller running idle, fed with feedback that comes from the action of the other controller. The I-characteristic could cause the passive controller to runaway as soon as the processing does not happen completely in sync (also time wise). Which is not given exactly in those moments when one would want to take a defective controller out of the loop...
Have ever transitions from a failed to a running controller been succesfully demonstrated usign this system architecture? Even if manually switched?
-
1
-
2
of 2 Next