Lessons Learned from Drone Development

Firefighting Drone Research Program

In partnership with local municipal firefighters and academic researchers, we developed and tested a semi-autonomous companion drone capable of indoor search-and-rescue operations with machine vision. This project included development and testing of a novel thrust configuration, custom development of UI/UX, hardware development, firmware development, software development, embedded systems design, PCB design, feedback control systems, and sensor data acquisition.

Firefighters have approximately 10 minutes to search a burning building for survivors and must put themselves at considerable risk to rescue survivors, if any. Visibility is often severely impaired during these situations, and firefighters often crawl on their arms and knees to see under the smoke and to look for survivors. In addition, as the fire progresses, floors and ceilings can weaken and become a deadly, but unseen hazard. Our goal was to build a remotely piloted aircraft capable of assisting firefighters in smoke-filled buildings. An effective solution must be low-cost, easy-to-pilot indoors without much training, and assist in finding survivors and hazards in smoke-filled rooms.

Project Description

Figure 2: One of many custom PCBs that were designed and produced during the course of the project

Over the course of 18 months, our multidisciplinary team developed a drone system that is suitable for rapid iteration and testing of various sensors, control schemes and payloads so that research on this topic can advance on a reliable platform.

Our team was comprised of expert engineers with specialties in each of the following disciplines:

  • Mechanical Engineering
  • Aerospace Engineering
  • Electrical Engineering (Software)
  • Electrical Engineering (Hardware)
  • Robotics and control systems
  • Drone Piloting

This project involved most of our core competencies. In the process of developing these systems, we used many of our expertise, including:

  • CAD design and simulation
  • Simulation in virtual environments
  • Parts design and fabrication, including 3D printing
  • Custom PCB design, fabrication and testing
  • Software development
  • UI/UX Development
  • Digital signal processing
  • Feedback control systems
  • Troubleshooting
  • Failure analysis
  • Project Management

What We Did

For this project, we designed and built most of the major systems and subsystems, including:

Airframe – comprised of the motors, propellers, enclosures, and appurtenances required for a flyable drone that can lift the payload of sensors, receivers, transmitters and other electronics required to meet the project objectives.

Piloting – comprised of the radio transmitter and receiver, and the flight controller that allow the pilot to direct the drone’s movement. The piloting system also includes feedback from the Pilot Assist Control System and its display.

Figure 3: “PIlot Override” Control Scheme, with hypothetical obstacle in northeast position

Collision Avoidance Sensing – comprised of a number of different sensors whose measurements were processed and used to detect obstacles and passed to the Pilot Assist Control Program

Pilot Assist Control (PAC) – this system received raw pilot input from the piloting system and data from the collision avoidance sensors, then modifies control output to assist the pilot by avoiding collisions and maintaining stability.

Figure 4: Control Flow Diagram for the Pilot Assisst Control System

Telemetry – This system captured data transmitted over Wi-Fi to create a Heads-Up Display (HUD) that could inform the pilot of the corrections being made to the aircraft as well as to indicate sensor data. The HUD displays the real-time IMU accelerometer data, drone velocity, and drone height all in the form of time-based scatter plots with dynamically ranging axes. By the end of the project the telemetry GUI was showing the following:

  • Overhead map generated by the 360 points of the lidar
    • Option to show the ultrasonic cones instead of the map
  • “Stick-position” for both sticks of the remote,
    • showing actual stick position from the pilot
    • showing “corrected” position from the pilot assist control system
    • Actual numeric values for throttle, yaw, roll and pitch were also printed
  • All 10 ultrasonic distances (later dropped after abandoning the ultrasonic option)
  • Top/Down distance and respective correction amounts
  • Graphs of Roll/Pitch/Yaw

Figure 5: Screen Capture of the Telemetry HUD in action

What We Learned

This was a great project and we’re very proud of it. We worked very hard, had a lot of fun and really exercised our engineering skillset.  Of course, every research and development project has its challenges and this one was no exception. We crashed and rebuilt out test drones dozens of times. We developed and tested quite a few variations for most of the major subsystems. Testing is one of the most hazardous portions of the project, not just in terms of risk of harm to people but also the complete loss of a vehicle and all the work that went into it. Therefore, it is important that steps be taken to mitigate the programmatic risks involved with flight testing. In addition, numerous things occur simultaneously during a flight test and it is hard to keep track of what actually happened in real-time. Here are some of the (non-technical) lessons that we thought were worth sharing when you’re working on a drone project.

Develop a flight plan – It is important that the team and pilot know and agree upon what the purpose of the flight is. Also, are there any maneuvers that are important to fly and are there some that need to be avoided. For example, when initially testing the side collision avoidance, can the vehicle be flown against a corner or should it be a solid wall only? Make sure that there are valid reasons for flying the vehicle and that the project will be advanced by doing so. Countless hours go into building a vehicle, it is not wise to risk a collision just to fly an aircraft.

Have a checklist – Prior to a flight test any team member might have done something to the vehicle to make it not flight ready. Examples include, cutting a wire zip tie to access wiring, removing most of the screws from a component, or leaving wires unplugged after bench testing. It is important that the vehicle is given a very thorough evaluation before the decision to fly is made. When preparing to flight test always know/check the following things at a minimum:

  1. Aircraft battery voltage
  2. Transmitter battery voltage
  3. Transmitter model (make sure the correct A/C model is selected)
  4. Check controls via receiver test, for both direct RC control and PAC
  5. Propeller tightness
  6. Wires away from props (physically grab any wires that are near the plane of the props and try to pull them into the plane of the prop. If they come anywhere close they need to be secured, to make sure they don’t get entangled during flight.

Keep detailed flight logs right after each flight – This one is very easily overlooked. After each and every flight take a few minutes for the pilot and observers to write down anything they observed about the flight, and also the settings and modes used during the flight. It is so much easier to look in a logbook and determine that last time a control mode with a certain gain was utilized, the pilot noted almost no vehicle correction, than it is to try to remember if it was 0.43 or 0.34 that caused the issue.

Pilot, practice switching command on a verbal cue from someone – Since the objective is to test electronic equipment that has command of an aircraft be prepared for very strange and bizarre behaviors to spontaneously occur. This means that the pilot needs to be prepared to take command of the vehicle back from the PAC at a moment’s notice. To prepare for this, try just flying a different vehicle around and when someone claps their hands throw a switch on the transmitter, just to build up that little finger response.

Do thorough static testing – to help reduce the occurrence of needing to resort to manual control of the vehicle, take the time to thoroughly test all of the flight plan indoors just prior to flight. Often times, things that worked the week before may no longer work, due to other modifications made in the interim. Almost all of the avoidance behaviors can be simulated and tested first on the ground. Again, there is no point in risking the vehicle, if it is observed that the throttle channel inexplicably drops out every time control is passed over to the PAC.

Communicate – During testing it is important for the pilot to know when they should switch over to the PAC. There were a few instances where the pilot switched over before control team was ready leading to some rough landings.

Test in a safe environment – Remember that the vehicle is potentially unpredictable and dangerous and a safe location should be selected. One of the failure modes that was observed during testing of this A/C was that after bumping a wall, the BBBK froze the last known command, full throttle, as the output making the vehicle slam into the ceiling. The assumption was that if it froze the BBBK would stop sending valid signals and the vehicle would just fall, not so!

Post crash analysis – Since crashes do happen, it is important to film every flight test if possible. If a crash does occur, take a few minutes to write down the events as you observed them, in addition to any possible causes, before talking to much about the crash with the other team members. Then as a team discuss everyone’s observations and event recollections, to try to determine a root cause. Don’t be too quick to rule a possible cause out. It doesn’t take much to bring down a vehicle, this is where having data logging comes in handy.

Be prepared to laugh – Crashes will happen despite the team’s best efforts, so be prepared to laugh about them, savor the moment and be prepared to rebuild.

Figure 6: The culmination of many hours of hard work, a drone that practically flies itself!