Hello flight-buddys,
it has been quiet for a while from GIZMOtec and the AP-Manager.
But meanwhile the project is finished and we are happy to present the AP-Manager with even more features and flexibility as a redundancy-board between two parallel running (different) autopilots.
Since, the requirements for the operation of unmanned aircrafts in commercial and semi-professional purposes have become more strict in some regions here in Europe, safety is important.
The AP-Manager allows you to operate your aircraft or vehicle safely by using two independent autopilot systems parallel. The AP-Manager is acting here as an intelligent bridge between the autopilots in your UAV system and switches to the alive autopilot, whenever one of the autopilots quits its operation.
Furthermore, with an onboard-mixer you can even operate your system manual, just in case both autopilots should fail (except for multirotors).
The AP-Manager has implemented electronic switches, which routes the servo outputs from the autopilots to a single servo output rail depending on the desired operation mode of the AP-Manager. The AP-Manager can be operated in “Manual-“ (semiautomatic) or “Automatic”-mode.
In both cases, the AP-Manager is monitoring the health status of the connected autopilots by checking the alive-signal of each autopilot and the servo outputs of the active autopilot.
This improves redundancy and therefore safety in case of malfunction in one of the autopilot systems. The AP-Manager switches to the second autopilot system and the operator is able to perform a safe landing.
On the board there is also integrated a PPM-decoder for manual (non-stabilized) flight.
With this decoder, you can directly feed the remote signals though the AP-Manager to the servos and motors (only possible for planes, delta-wings, helicopters and ground vehicles). This function is activated in case both autopilot systems are not working (Emergency state) to perform an emergency landing.
The AP-Manager is able to control up to 8-output channels. With a second board you can extend the system to use even more channels (NOTE: not implemented yet).
Additional benefits arise when using the AP-Manager in combination with autopilots from the ardupilot-family (by 3D-Robotics) in terms of switching the telemetry-downlink. It allows you to use only one telemetry module to monitor two autopilot systems separately. If the AP-Manager switches (manually or automatically because of a malfunction) between the autopilot systems, it also switches the telemetry automatically, allowing you to monitor the autopilot which is currently in command.
If you performing test-flights (e.g. with a new firmware on the second autopilot) you can easily watch the behaviour of the second autopilot via the telemetry switch, whilst flying on the familiar primary autopilot (with the old firmware).
One single PPM / PWM channel on your radio receiver can operate the different mode-selection solutions for the autopilots and the selection of telemetry’s.
You can use the most features when using a PIXHAWK or APM, but you can also use other autopilot systems. You even can mix the autopilots or stabilization systems, if it makes sense for you or for test purposes.
Dependent on your range of application for your UAV’s, the setups can be very different and various (type of autopilot, telemetry, esc’s, power-redundancy, remote control, vehicle, number of engines…etc.). Therefore, we prepared a configuration tool for doing the setups.
Some Features of the AP-Manager:
- Telemetry switch (for 3DR-family)
- Manual and/or semi-automatic switch between autopilots
- On-board mixer for traditional aircraft, delta-wing and helicopter on board (in case both autopilot fail)
- Wide internal power supply range 3,7-17V
- Configurable via software
- Future firmware updates possible
- Mixable with different autopilots
- Signal feedback outputs for LED’s or buzzer
- Digital output for feedback of actual state back to JETI receiver
- PWM-signals of active autopilot and parallel monitoring of alive-signal
- … etc.
For more information please check our website on www.GIZMOtec.eu , take part on our NATION CAMPAIGN or contact us if you have questions via office@gizmotec.eu
Thank you,
The GIZMOtec-Team
Comments
HI Robert
What are the updated news about the Redundancy Autopilot?
Hello Folks,
just some information about the progress with the AP-Manager.
We meanwhile offer a casing for the electronic board. If wished in different colours or even with your branding on top. Check: https://www.gizmotec.eu/product/casing-for-ap-manager/
Please do not miss our still ongoing "Nation Campaign" https://www.gizmotec.eu/nation-campaign/ where 1st customers in different countries can get a reduction in price for the first board.
If you are interested, you can also become an integration partner in your area, check: https://www.gizmotec.eu/integration-partners/
Finally, we also expanded the number of FAQ on https://www.gizmotec.eu/faq/
If you still have some open questions do not hesitate to send me an email on office@gizmotec.eu
Regards, Robert
@Manu B
Yes, this is always the question and one can drive it to the limit. EMI, humidity, brownout, temperature…etc. Here we are thinking more in a conservative way.
E.g. even that all electronic parts on the AP-Manager are specified in a temperature range between -20 to +80°C we leave it for the moment in the range from 0 to 50° until we have done our own temperature tests. Robert
@Veikko Vierola
Thank you, great. I did not know this and will read it. Regards, Robert
@Rana
Thank you, nice to hear....don't forget to assigne for the newsletter on our website to be informed with the latest news from us...:-)
@JB
Hello JB, Thank you for your thought and your constructive comments, I appreciate.
I can see your points and in most cases, I can agree with you. The statement is, the more parts I bring into a system, the more can go wrong is true, from first perspective. There have to be done a balanced scorecard in usable and necessary sensors for each single airframe. But at the end I think it is up to the commercial user of the UAV to have a solution for the aeronautical authorities and the insurances in each country, to bring his vehicle legally in the air.
About your list in risk priorities, I think you should put point 3. on top, then you can cross out point 1. and 2.
To use a parachute is also a good “final solution”, but again very dependent on the reaction time, altitude and speed. But the same here again, more parts can lead to more problems. I have seen it twice that the parachute was activated accidental on ground and another time during start. Both times a lot of things on the multicopters were damaged (cables, propellers, antennas, mount…)
With the onboard GPIO connectors on the AP-Manager we already have done some tests with a “PA-Manager” (parachute-manager). This is an extra small board what can be activated manually or when both autopilots should quit. But we defer this idea for the moment, because to activate something like this manually is relatively easy, but automatically you need to have a lot of extra input information (angle, time, speed, descending-rate…etc.), based on your type of UAV.
Regards, Robert
@Mark Omo
Thank you for your details. I think there is a misunderstanding in the function and purpose of the AP-Manager. This board is not running on the APM firmware. It is a complete different system, based on our own firmware with different functionalities.
So that the APM (what is not longer supported) does have an Atmel does not have any influence, link or context to the AP-Manager.
Robert
Really awesome product !
@ Robert
I was not in any way suggesting to go triple redundancy AP's etc, rather that if you did want to implement some sort of AP functionality check based failsafe, beyond the simple heartbeat failsafe that is implemented in this system, you would need to go for three AP's to do so.
My first comment was in fact that it is NOT a good idea to add even more components to make the systems more reliable, including another autopilot via your failsafe. I also said that I understand that there is a possible use for this for testing purposes, for example to test different hardware/software whilst being able to switch back to a known stable AP version, if that can be done fast enough, and the AP can manage to take control in time to sustain flight.
Simply put what is the intended goal of this system and how does it counteract it's own possible failures in order to achieve a more reliable overall system, especially if it cannot determine the actual control state of the autopilots themselves, against sensor failure etc. Further having the telemetry routed through the failsafe means there is a single point of failure for control for both APs.
There's also the question in what airframe will this be used and for what purpose, as the risk is directly proportional to impact kinetic energy (incl props etc).
From a risk perspective my priority would be:
Accordingly, a parachute released on heartbeat failure might prove more useful to meet these requirements as it physically controls the aircraft decent regardless of what hardware or software fails (the AP could even fall out, or loose a wing), provided the aircraft is operated at enough altitude for the parachute to be effective.
Overall I'm not sure that the failsafe adds any value to the reliability or safety to the overall system apart from for testing purposes.
@Robert Hoermann APM based boards are no longer supported see here:http://copter.ardupilot.com/wiki/common-apm25-and-26-overview/ and here http://plane.ardupilot.com/wiki/common-apm25-and-26-overview/, more info here: http://diydrones.com/profiles/blogs/apm-plane-3-4-0-released and here: http://diydrones.com/profiles/blogs/copter-3-3-released
-
1
-
2
-
3
of 3 Next