Drone Flight Area Control is a scalable drone management system which allows users to efficiently delegate tasks to fleets of varied UAVs, that was built for Hack Arizona and won best overall, best in software and third in drones.

What It Does

Drone Flight Area Control, or DFAC for short, maintains a list of drones and tasks, and sends drones out to those tasks in the most efficient order. The drones and tasks can be monitored and managed through the DFAC web interface, which allows the user to visualize the layout of the tasks, keep track of the drones and their current tasks, and add, modify, and remove tasks. The interactions with the DFAC backend, however, are limitless. Data is exchanged via HTTP GET and JSON, so there are many innovative possibilities for managing the drones and tasks. This also means DFAC can be used as a scheduling and control backend to existing applications.

This software was written by me and a friend of mine in 36 hours, all the drones you see are simulated using SITL.

The UAV Challenge Technical Committee today announced that the venue for the 2016 UAV Challenge Medical Express competition will be Dalby, Queensland, Australia. The Base for the event will be the Dalby Model Aero Club (DMAC). A rules update was also launched today, with Version 2 of the rules now available on the Medical Express Page. A full list of changes to the rules can be found on page 5 of v2 of the rules document. Finally, it was announced today, that the date of the Medical Express event has been pushed back by one week (to 27 September 2016), along with the due date of the Deliverable 3. Please see the Medical Express page for further details.

I have started a new group for discussion and sharing of information concerning the Outback Challenge, I feel it is important to share as much as possible here in a centralized location in order to help everyone. I have started a discussion concerning Deliverable 1 my hope is to get as many as possible posted for future people to see what they look like and to see the wide array of ideas that are presented, and just to share with others to get feedback.

The UAV Challenge Technical Committee can report that they have completed their deliberations regarding the Deliverable 1 (D1) technical reports from the 2016 Medical Express teams. In total, 59 teams were given a Go decision and progress to the next phase of the competition. Well done to those teams and bad luck to those that did not make it through.

I am participating in the UAV Outback Challenge and wanted to calculate the MTBF of the APM 2.6+ for use as a standalone fail safe device. 

MTBF is a standard measurement of failure rate in the Engineering world, it is normally represented in Hours, or failures per Million Hours. From Wikipedia: 

Mean time between failures (MTBF) is the predicted elapsed time between inherent failures of a system during operation. MTBF can be calculated as the arithmetic mean (average) time between failures of a system. The MTBF is typically part of a model that assumes the failed system is immediately repaired (mean time to repair, or MTTR), as a part of a renewal process. This is in contrast to the mean time to failure (MTTF), which measures average time to failures with the modeling assumption that the failed system is not repaired (infinite repair time).

Why do we care? 

MTBF is an important indicator of reliability in a system, the higher it is the less likely it is to fail.

How do you calculate it? 

I looked at the schematics for the APM 2.6+ and exported the Bill Of Materials (BOM), used this tool to calculate the MTBF of all the items according to the ANSI/VITA 51.1 standards assuming the operating temperature was 60°C (very Conservative), and that ther were the most unreliable class of devices (Consumer Grade), and for more specialized items (ICs and such) I looked them up on the manufactures website (here is an example, the 3.3v level shifter for the MPU).

After finding all these values I input them all into a spreadsheet, and classified them by Subsystem, and if the item was critical for that subsystems operation. (For example LEDs are critical to the LED subsystem, but not critical to the USB UART subsystem)

I then took all the components in every subsystem that were critical and totaled up the MTBF (assum any faluare of any part would cause a total system failure, using the formula: total MTBF = 1/(1/1st MTBF + 1/2nd MTBF + 1/3rd MTBF ect...)) 

This gives the following MTBFs for the following subsystems:

We can then use that data to total the MTBF for the entire APM to be 61664.5 Hours (7 Years!), however not every one of those systems are required to maintain level flight, as far as I am aware only the following subsystems are required to continue to fly, MPU, 3.3v Regulator, AT2560, and PWM Input/Output Giving us a MTBF of 173218.9 Hours (~20.7 Years!)

Take everything I have said here with a grain of salt, as I am not a professional, in addition most of these failure rates were calculated, and the calculations might be a little off, or the manufacture data might be overestimating the true lifetime of their products. I have attached the Excel sheet I have used to calculate these values in the hopes someone might spot some mistakes I have made or find it useful in the future.

Download the Spreadsheet

The deadline has now passed for submitting Deliverable 1 documents to the 2016 UAV Challenge Medical Express. We received 64 D1 documents from teams from all over the world. The Technical Committee will now get to work reading through the documents and assessing teams for the Go/No-Go decision. This process is likely to take 2-3 weeks.

More information can be found on the UAV Challenge website.