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
snakeoil
sooo, what happens about one controller being armed and the other not being armed?
I see its only reuse being for a developer who loads an old safe version and a new work in progress. If something goes wrong they switch from beta -> safe to complete testing without a big crash.
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
Had it been a kickstarter I would have backed it. With Indiegogo they get our money even if the funding goal never gets reached and we never get our perks. Too many uncertainties, should have gone with Kickstarter.
-
1
-
2
of 2 Next