The AP Manager looks great! I've backed it.
Improve your flight-safety by adding redundancy with the intelligent bridge between two independent running autopilots in your RC-model
Universal, reliable, flexible, future-oriented, this is the AP-Manager.
Designed for the use of two independent running autopilot-systems in your RC-model.
For safety reason and testing purposes.
A must have for the serious commercial or private RC pilot and a step forward to a secure flight for you and your RC-model.
NEW: Extra feature for TRANSFORMER UAV (e.g. multicopter --> aircraft and back)
This is the AP-Manager:
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.
How it works?
AP-Manager provides the best safety for your aircraft, in case of malfunction in one autopilot system. If the primary autopilot system fails, the AP-Manager automatically switches within fractions of a second to the secondary autopilot system.
However, the switching can also be done manually by remote control. Hence the AP-Manager is the perfect companion to test the most recent updates or new parameter upgrades for your autopilot system.
Due to an intelligent control system, only one telemetry module is required (except DJI autopilots). The Data of each autopilot system can be monitored and changed during the flight separately. In addition, different types of autopilot systems can be operated alternately. AP-Manager is compatible with any autopilot system. The only requirement to an autopilot system is that it produces a periodically recurring signal like I2C communication or CAN bus to determine the state of health.
Currently, the autopilot systems:
- Ardupilots 2.5 / 2.6
- PX4
- Pixhawk
- DJI NAZA V2
- NEW: DJI A2
- MikroKopter Flight Ctrl ME 2.1
have been tested successfully.
Basically there is no reason that other autopilot systems from other manufacturers won’t work. The board has been designed that all ports are compatible with the common used autopilot systems.
Different configurations
NOTE: No designates orientation for the AP-Manager is needed
What is included?
- AP-Manager Board
- straight 3-pin header rows
- User Manual (online for download)
- Software (online for download)
- ...
What is coming next?
It is not possible for us to test all possible systems and setup configurations combined with all variations of vehicles. For this reason we offer our ongoing adaption of the software to the wishes of the customers. The desires, priorities, or problems of the customers will be analyzed in a discussion forum to adjust and improve the AP-Manager and its software.
For the discussion forum check our website: www.GIZMOtec.eu
Technical Specification:
- Width: 40 mm
- Length: 65 mm
- Drill hole distances correspond to APM 2.5/2.6, as well as PX4 and Pixhawk
- Weight: approx. 20g
- Temperature range: 0°C to +50°C (32°F – 122°F)
- Supply voltage: 5V (+/- 5%)
- Separate or external servo power supply possible (for example, for high power servos)
- PPM Input and decoding in PWM for 8 channels
- (16 channels with a second AP-Manager board in preparation)
- ...
Comments
sooo, what happens about one controller being armed and the other not being armed?
Gerard, another very good point. This is why I just don't see how this is a workable solution. At the very least, it would require changes to the Ardupilot code, which would make sure both processors are running somewhat in parallel. One of them would have to know that it was a slave to the master controller, and then would have to know when there was a hand-off. And then all of that logic brings with it a bunch more complexity and uncertainty.
I'm thinking about using it on a 'transformer' VTOL that I've been working on for a while. Combination quad/airplane built from scratch. The multi-rotor part can fly on it's own or inside the Talon airframe.
I'll post some video if anyone is interested. I might even do a Kickstarter for it.
#4 too in a limited way, but then it would apply only to the controller itself, not a power failure as a whole or a battery failure.
Thinking about it some more, I really wonder how they think this would apply to autonomous missions, which is the point of an autopilot and not just a stabilizing controller. You'd have to load the same mission on both devices and apply the same parameters on both. Then on takeoff you need to make sure that both are in agreement that all failsafe conditions are met to allow takeoff.
After that, you need to be sure that both gps's record the exact same position, so that the navplan in both devices advances to the new waypoint and not have the other fallback autopilot move all the way back to some missed waypoint in the plan if it switches over.
I agree, I really don't see this as a solution to any problem we currently have. At best, it moves the single point of failure somewhere else. At worst, it's extra complexity, and will bring with it more problems than it solves. For example, if you try this with Arducopter, I virtually guarantee it'll crash if you switch processors mid-flight. Because the redundant one will sit there building up false I-terms, which will go active when you switch. Also, this adds quite a bit more complexity to the system, and increases the odds that users will make more setup errors.
As others have pointed out, processor hangs are very, very low down the list of failure modes. In my estimation, it goes something like this:
1) Pilot aviating erros. (ie: CFIT)
2) User setup errors (ie: bad params result in undesired operation)
3) Propeller failures
4) Power supply failures
5) Motor failures
6) ESC failures
7) Code bugs (would not be caught by this device)
8) Hardware failures (ie: gyro or baro chip glitches)
9) Process hangups
#9 is the only one this device helps with, and is quite rare.
I really have reservations whether this is a good solution. It looks like it's mostly targeted at power and processor failures (it checks whether commands are issued), but it wouldn't be able to verify whether the commands themselves are correct or when the actuators have a failure, cases which are much more common.
The other disadvantages are that you add a lot of weight and volume to a multirotor with this solution. Double the GPS, some more stacks, all the extra wiring, double the autopilot and then this board. That's another 80-100g at least. The worst is that all that extra hardware increases your current consumption, which increases the load on voltage regulators, which significantly increases the probability of a brownout in the first place.
The difficulty of redundancy on small vehicles is that there is no one on board to disambiguate and the amount of information you receive through telemetry is limited, because it treats only one autopilot at a time. This is why redundancy works in full-size aircraft, where the pilot has much more information available to make a proper decision and more knowledge. Doing this correct 'automatically' is a really hard topic.
@Hugo: they opted for the fixed funding campaign on indiegogo by the way, so it's an all-or-nothing request.
the danger that a esc fails is higher than the FC.
it is a very interesting thing. the commercial flying in Austria is prohibited without redundant systems.
Mikrokopter has presented as a system.
sorry my english is very bad
Moving the single point of failure from a device which is widely used with a mature code base that anyone can review (peer review) to a new device which is not widely used, is likely closed source and hasn't got the code maturity is a step backwards.
The better way to address high availability in a circumstance like this would be to move everything to a cluster computing based approach wherein the two (or more) autopilots monitor one another and arbitrate for hardware access. This is the approach favored in both complex and simple high availability computing solutions, it should IMO be the approach favored for APs too
While it is true that the single point of failure moves to another device this is surely better than not having it. It is likely that something along these lines will be mandated, especially for commercial operation of UAV's. I find this a little odd personally as its not mandated to have two engines in all small aircraft.
I really like the motor fail algorithm in the video as well.
Perhaps we will see an algorithm to deploy an airbag below our craft upon detection of a certain descent rate as well.
The failure modes it protects interest me also. It seems the main protection is against some kind of software edge or corner case that caused the main AP thread to crash as it's reliability physically doesn't seem to be any different then a well designed AP board.
That has me thinking that there must be some way for a watchdog to run on some of the newer boards that could perform a reboot of the main flight software. Right now an in flight reboot causes a loss of the aircraft. Could the accel/gyro initialization be saved in non volatile memory at each boot? Combining this with the software checking for positive airspeed and/or high GPS velocity and low HDOP at start up could allow the autopilot software to detect a start up in flight and attempt to keep flying after a reboot (with perhaps a default to RTL mode)?
Just a thought
-
1
-
2
of 2 Next