3D Robotics

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)

20140708044955-1.png?1404820195

This is the AP-Manager

How it works?

Different configurations

What is included?

What is coming next?

Technical Specification

Where will Fundings go?

Risk and challanges

FAQ's

 

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

20140615111841-Gruppenbild_Einbauarten_AP-Manager.png?1402856321

NOTE: No designates orientation for the AP-Manager is needed


What is included?

20140717031304-Bild1.png?1405591984

20140723031108-Softwarebild_b.png?1406110268

  • 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:

20140615130822-4-Seitenansicht_AP-Manager.png?1402862902

  • 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)
  • ...

E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Interesting thing. I wonder what happens if the AP manager board fails as I assume the inputs / motor outputs go into the board instead of the Pixhawk.

    I read that the people who developed the algorithm (the one that sacrifices yaw to keep the quad flying) above have copyrighted the code and are keeping it close to their chest, supposedly looking for a license deal. But since physics and logic can't be patented, there's nothing stopping anyone from reverse engineering it and bringing that feature to APM:copter.

    Do you guys know if this is on the roadmap?

  • Moderator

    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.

  • 100KM

    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

  • I have been wondering when something like this would be possible. I have thought that these little auto pilots could someday be used in personal flight aircraft, but there would need to be multiple redundant systems. This board is the first idea I have seen that brings this closer to a reality. Very interesting!!

  • There are beginning to be options in the event of a motor/esc/prop failure.

  • Pardon my ignorance but doesn't a system like this just move the single point of failure from the flight controller to the single flight manager device? I've seen people bring this subject up quite often but in my experience the flight controller is most likely the most reliable component in our systems. Motors, ESCs, props and the many solder points are far more likely to fail than any flight controller. Not to mention that no flight controller can keep a quad or hexa in the air in the case of motor failure. 

  • Another step forward in terms of safety. Exciting stuff!

    Obviously we still have some time to wait before anyone could responsibly entrust their lives to their open source autopilots. Still, I can't help but wonder just how long it will be before ArduCopter and what we see above might be combined with something like Rotorway's A600 Talon (~USD$100K) powered a TJ-100 turbine (~USD40K) - (example here or search JetExec).

    It is nice to think that sometime soon it might well become possible to build something not far removed from Boeing's Unmanned Little Bird for little more than it would cost to buy, house and maintain than a moderately prices sports car.

    Google
    Search the world's information, including webpages, images, videos and more. Google has many special features to help you find exactly what you're lo…
This reply was deleted.