TheFlyingScotsDrone_NXP

Overview

One of the challenges with wildfires is getting people out of the way. The fires can move quickly and it is essential that people do not accidentally get caught in them. Typically this has to be done by a team searching the area ahead of the fire or using expensive aircraft. This can especially be a problem in places like California where there are many mountains and valleys as people may not be able to detect an approaching fire when in a valley next to it.

The idea is to use the NXP Hovergames (https://www.hovergames.com/) drone to search larger areas quicker than can be done by people and at a much lower cost than using aircraft. The key features that are required are a way to detect people and signal to them. The basic Hovergames drone kit does not have sensors or signals so these will need to be added.

The first challenge is detecting people. While sophisticated cameras with optical and infrared imaging could be used, an advanced computational resource would need to be added to handle this data. We opted for a much simpler system on our drone - we detect mobile phone signals. Since most people carry mobile phones, especially when out walking or hiking, this should be an effective way of detecting anyone in the affected area.

The second challenge is signaling to anyone in a danger zone. We added LEDs to the underside of the drone arms to signal and give directions to the people.

While this system was designed to support firefighters fighting wildfires it could also be used by Mountain Rescue to find people who are lost. One advantage of the drone works is that it works well in both light and dark conditions. This is especially useful in Mountain Rescue because it is not usually until late in the day that people are identified as missing.

Team

We are a team based in Scotland in the United Kingdom. The team is composed of an NXP engineer and 2 second-year University of Strathclyde students studying Electronic and Electrical Engineering and Computer Science.

Build

In general, we followed the NXP HoverGame instructions to build the drone. A short video of a test flight to check everything is working is here:

https://www.youtube.com/watch?v=vMSgXAb9Brs

One thing that is not included in the kit is the battery. It is difficult to ship LiPo batteries so one needs to be bought locally.

Battery

The drone supports using 3S (11.1 volts) or 4S (14.8 volts) LiPo battery packs. The type of battery needs to be configured in QGround control so the drone can detect the charge level of the battery.

A 4S battery was used because the higher voltage will allow the blades to run at a higher speed which may be useful. We selected a 5.26Ah battery to provide a large amount of power but the downside of the battery is that it is heavy at 466g. Since the battery is heavy, some Command-Tab strips were used in addition to the NXP Velcro belt to secure it to the drone.

After some testing, it was determined that a lower capacity battery which is smaller, lighter and cheaper would be a better option.

Customization

We customized our drone to make it special for our team. Since we are a Scottish team we wanted our drone to look like the Scottish flag (white cross on a blue background) so we painted the arms and top platform white. The R/C antenna rails (https://www.thingiverse.com/thing:3032922) were 3D printed in black rather than using the NXP orange ones. In order to clear the top deck the GPS antenna was moved to the rails (https://www.thingiverse.com/thing:980277). To complete the clearing of the top deck the telemetry radio was moved to the middle of the plates.

Sensing

The key feature of the sensing circuit is to detect mobile phone signals. Even when a mobile phone is not connected to the base station, i.e. it has no signal, it will still send out radio waves looking for a base station. It is the signals sent from the phone that we want to detect.

Rather than creating a circuit ourselves, we re-used an existing circuit: Circuit 1 (https://www.electronicshub.org/cell-phone-detector-circuit/). The output of the LED is connected to the FMU (Flight Management Unit) so it knows when a signal is detected.

Lights

We need some way of signaling to the people on the ground which direction to go for safety. The solution we chose was to put NeoPixel LEDs on the bottom of each of the arms. A green arrow can be generated to show the direction to safety. NeoPixels are multi-colored LEDs that are controlled by a serial signal. The NeoPixels give the ability to create any pattern and any color. There are tight timing requirements on the serial signal so a separate MCU was used to control the NeoPixels.

An Arduino compatible Teensy 3.1 was used to control the NeoPixels. The advantage of using the Teensy is that the Arduino tools can be used and there are NeoPixels libraries available, plus it uses an NXP MCU. The NeoPixels can be connected in a chain, however, using 4 separate strings allows for some redundancy in the system as a single fault only affects 1 string. The installed Teensy is shown below:

One challenge is dealing with different voltages. The NeoPixels are basically 5-volt devices and the I/O on the Teensy 3.1 is only 3.3 volts. A level shifter could be added to convert the 3.3-volt signal to 5 volts, however, we wanted to keep the drone light and simple. Some NeoPixels can run at 3.3 volts, however not all support it. It is possible to use the 3.3-volt control signal with 5-volt NeoPixels, however, this does not work reliably. Our solution was to run the NeoPixels at 4.7 volts since this allows a good overlap between 5 and 3.3-volt signals. The circuit is shown below:

The power comes from the main drone battery. A variable voltage power supply is used and set to 4.7 volts. A resistor was added to each of the NeoPixel strings to protect the Teensy. The power supply was mounted on the bottom of the drone as shown below:

A capacitor was added to each NeoPixel string to help handle any power surge because of rapidly changing NeoPixels. The size of the capacitor is not really important, it just needs to be located close to the NeoPixel string. One thing to check is the maximum current capability of the power supply and that it can provide enough power for the NeoPixels. The NeoPixels can pull a large amount of power when they are all on. The capacitor, which is circled, and NeoPixels are shown below:

The Teensy gets information from the FMU on which direction the green arrow should be displayed for the people on the ground. It does this by measuring the high time of a PWM from the FMU. The code for the Teensy is in the team GitHub repository: https://github.com/CyberLeader3000/TheFlyingScottDrone

A short video of the drone flying with some test patterns on the lights is here:

https://www.youtube.com/watch?v=nMVncmeBl9Y

Control

The drone is controlled by a PC using MavLink with the Python API. We used the MAVSDK with the JMavSim to develop the code. We tried using the simulator with Windows but found it was more stable on MacOS. The program takes a search point and uses it as the center of the search area. The drone takes off, goes to the search area, searches and then returns. It currently uses rectangles for the search pattern. A sample search pattern of 2 rectangles is shown below:

The code for the PC is in the team GitHub repository: https://github.com/CyberLeader3000/TheFlyingScottDrone

School of hard knocks

There were some hard landings because of the wind pushing the drone towards the road. Rather than endanger traffic the drone power was cut but this caused it to hit the ground hard.

The original landing gear pieces are not strong. Luckily NXP provides 3D printable replacement parts, on Thingiverse, that are stronger than the originals with the added advantage that you can print as many as you need.

Landing Gear T: https://www.thingiverse.com/thing:3822544

Landing Gear Top: https://www.thingiverse.com/thing:3860307

Future Work

There is never enough time to get everything done, however, there are some things worth adding in the future:

• The current system takes commands over the MavLink from a PC. When the software search strategy is finalized and optimized it would be good to migrate to running on the FMU on the drone to make it fully autonomous.
• When flying the drone manually it can be hard to tell which direction it is facing. We added caps to cover the ends of the arm tubes. An additional NeoPixel could be added to the caps on the end of each of the arms. This would allow a unique pattern to be displayed so the direction can be determined quickly.
• While it is typical for people to have mobile phones with them and we use this feature to detect people, their phones are not always fully charged. It should be possible to carry a small backup charging battery and drop it using a small parachute when people are detected.
• When a person is found it would be useful to communicate this information back to the operator. When the drones are out of range of the radio this is not possible. It should be possible to create a mesh or relay network to get a signal back over a longer distance.

Conclusion

The NXP HoverGames drone provides a great platform for experimentation and exploration of drone technology. We really enjoyed creating and testing our HoverGames drone to support firefighters and look forward to continuing its development in the future.