Near Loss in Tall Grass

UAV completely hidden in the tall grass

UAV completely hidden in the tall grass

This weekend I went out with a friend to fly my quadcopter UAV.  It had been several weeks since I started working on the lighting project for my UAV and I’d not had opportunity to do any flying since. I still don’t have the lighting relaying the control board status, but I do have the new lights installed, with both of the right arms wrapped in green and both of the left arms wrapped in red.

I’ve been flying the Ardupilot firmware 3.0.1 since I put the APM into my quadcopter. In general I’ve been happy with the solution, but I’ve had problems with it’s loiter function and sometimes return to launch causes the copter to take off in odd directions. I do not have the optical flow sensor installed on my unit and so the loiter function is purely based on GPS signals.

I’ve been reading the release notes on the release candidates for the Ardupilot firmware 3.1 and decided that since I didn’t know why my 3.0.1 copter wasn’t flying well, I might as well live dangerously and see if the 3.1rc4 did any better.

I checked the box in Mission Planner that I wanted to use the beta software, it refreshed itself and offered to let me load the 3.1rc4 firmware. After doing that, I went through the initial setup and calibration of the compass, accelerometer, and throttle settings. Then we went to try to fly the copter.

Initially things seemed very good. The new firmware rotates the motors when they are armed, which is a nice safety and status indication. The takeoff seemed smoother than most of my takeoffs have been, with the initial trim seeming to be perfect. I could release the right stick entirely and the copter was hovering in place with throttle control alone. Changing the switch to loiter mode also had it holding in the right position.

Problems seemed to happen after about five to seven minutes of flying. The return to launch and loiter functions seemed to become significantly less stable with erratic horizontal movements.

During the first flight with the new firmware after several minutes of comfortable flying I put the controller into loiter mode and handed the transmitter to Brett so he could see how it flew. I noticed that I’d obviously not configured the firmware to correctly monitor the battery power because Mission Planner was reporting 0.00v. Things continued well for a couple of minutes but then he started to have problems controlling it, RTL was not bringing it back towards us, and loiter was not causing it to hold position. He told me that he was making the decision to land where he was in the field and I confirmed that was the best thing to do. I have no problem walking a distance through a field to find a copter, but would not want to lose the copter in the trees.

Mission Planner Display of Flight

Mission Planner Display of Flight

Measuring some of the distances using the ruler in Google Earth show my copter was 160 meters away from us at the farthest southwest point, and only 20 meters from the trees. When Brett set it down, it was about 120 meters from where we were standing. We were flying visually, I have no cameras installed on my UAV right now.

I thought I knew where the copter had gone down, and so told Brett to stand in place and I’d go retrieve it. After walking a large distance and not seeing any sign of the device I turned around to see if Brett could point me in the right direction. He pointed me in one direction but I was still not having any luck. Communication was made worse because I’d left my phone back where we were flying from and was now standing over 150 meters away.

I realized that carrying the transmitter would have been a good idea because I could arm the motors and possibly hear them thrashing the grass, or even attempt to take off the unit to be able to zero in on it’s location. I went back and retrieved the transmitter, and Brett decided he could assist me from the air with his HexCopter. He’s set up with First Person Video and also has a GoPro Hero3+ Black on a brush-less gymbal mount. He was confident that he’d be able to quickly find my brightly lit QuadCopter from the air.

I went back out walking around the field, and he soon joined me virtually via his UAV. The video of our searching is on youtube. It was an overcast day and the grass had never lost the moisture the morning fog left it coated with. It’s possible to see the tracks where I walked because of the darkness where the grass has been disturbed.

After all of the manual searching, we were not able to find the copter. Starting up my computer again I was able to reestablish communication with the copter and read it’s reported GPS coordinates.  Brett entered the coordinates into an app on his iPhone and it took us to within 15 feet of the device and I was able to find it by the noise of the rotors attempting to move the grass when I tried to raise the throttle. The grass was thick enough that my motors would still not spin, and not much noise was made.  Even standing and looking down on the unit, it was easy to lose it in the grass.

I have overlayed the Brett’s search path and my flight path in Google Earth and it appears that he never went exactly over the top of the copter. Here are two different angles on the complete flight profiles.

Path of two UAVs with an overhead perspective

Path of two UAVs with an overhead perspective

Path of two UAVs showing the elevation

Path of two UAVs showing the elevation perspective

The path of my UAV switches colors each time the mode is switched between flight modes. I have configured Stabilize, Loiter, and Return to Launch. The relative horizontal speed of travel is indicated by the distance between the points on each line. Closer points indicate slower movement. Brett’s search path generally moves slowly and all of the points are close together. He nearly exhausted his battery in approximately 8 minutes of searching.

I have spent a lot of time sailing and one of the things leaned is a proper man overboard drill. During a proper man overboard drill it is one person’s responsibility to do nothing but keep pointing at the person overboard. Holding an arm outstretched pointing makes it much easier to keep track of exactly where the person is. To someone who has never done a drill it seems like it would be easy to keep track of a person or relocate them, but it is not. Losing a UAV in a field is not the life and death situation that losing a person overboard in cold water may be, but it is a reminder that you should have a plan for proper recovery when things go wrong.

I should have:

  • Read the GPS coordinates from the ground station immediately after the UAV landed.
  • Had Brett point at the location the device disappeared into the grass.
  • Carried a communication device into the field with me so that Brett could have relayed directions to me without shouting across over 100 meters.
  • Carried the transmitter with me on my initial trip to recover the UAV.

Considering that nothing was lost but time, it was a good day of flying.

APM Status LEDs using a ULN2803 Darlington Transistor Array

Successful Evening Flying

Successful Evening Flying

As purchased, my QuadCopter/UAV came with strips of LEDs wrapping each of the motor arms wired directly to the power distribution board. When I plug the battery into the board, all of the lights come on. This is good for recognizing the orientation of the UAV but does nothing for recognizing the status of the control board.

The control board I am using is an ArduPilot Mega 2.5 including the GPS and Ground Station Telemetry. I often refer to it as the APM. The APM has several LEDs that blink to indicate various status information, which is useful if you can remember what they mean, but they are individual LEDs and hard to see from any distance. I have installed my APM on the interior of my UAV, which makes the LEDs only visible from certain angles.

I decided that I wanted the primary lights to be useful as status indicators.

Researching the topic I came up with two approaches. One is to use a Darlington Transistor Array driven directly from signal pins in the APM to control LEDs running at higher voltage and amperage than provided directly from the APM. The other is to have a device spliced into the serial telemetry link that interprets the messages being sent to the ground station, controlling and powering the LEDs appropriately.

An example of the direct driven version is shown on the Arducopter website. It also links to a board that is available from JDrones that can be used for the second version.  The JDrones board requires further hardware to be able to properly splice into the serial link. The JDrones hardware looks nice, and I may still go and buy it, but I wanted to try the direct driven version first. Part of my reason was cost, and part of my reason was wanting more experience with the DIY process as opposed to the Off-the-Shelf process. The JDrones solution would cost ~$20 for the first item and ~$10 for the second, while the ULN2803 chips themselves cost under 75¢. None of that includes the wiring or time involved, but most of this is related to the fun of learning so my decision seemed like a good plan.

The most useful post related to my decision was on the DIYDrones site. It’s over two years old but still relevant. This post on configuring the APM firmware was also useful.

Turnigy Waterproof LED Packaging

Turnigy Waterproof LED Packaging

Because I had banged up some of the original LEDs I also am replacing the strips with new LEDs that have waterproof protection and should provide slightly more impact resistance. Before working on this project I had priced individual LEDs and they always seem to be priced so that they cost close to $1 per LED. These LED strips sold at hobby supply stores are designed to be powered simply by applying 12 volts. They are designed to be cut at specific locations between each three LEDs. The hobby store I got them from sells them in 1 meter lenghts, providing 60 LEDs. The 1 meter strip is rated at 400mA at 12 volts, so that should work out to 20mA per segment.
My original lighting used 7 segments to wrap each arm. If the power requirements are the same it would have drawn 140mA per arm, or a total of 560mA for the 4 arms. By reducing to 6 segments per arm, I should reduce the power requirement for lighting below 500mA. This might be important because the ULN2803 lists its capacity as 500mA per channel.

Radio Shack DIP Project Board

Radio Shack DIP Project Board

Before starting my soldering I came across a radio shack board designed to take a DIP package and give multiple conductivity pads per pin. I decided that it was absolutely the correct tool for my first project. After getting a successful system, I could reproduce the system in a much smaller package, but this would be a good first direction. I found an inexpensive package of short servo extensions online and decided that I’d rather use those to connect the LEDs than build my own connectors or solder the LEDs directly to my project. This lets me change the device driving my LEDs in the future without resoldering everything.

My soldering skills are still not what I’d like, and I spent much time soldering the wires to the board. The finished product is not as nice as what I was envisioning before I started the process.

ULN2803 Mounted Radio Shack Board with wires soldered in place.

ULN2803 Mounted Radio Shack Board with wires soldered in place.

Back of Radio Shack Board showing the soldering.

Back of Radio Shack Board showing the soldering.

The two long leads going to the left are designed to connect to the signal pins 4 through 9 of the APM. The short lead on the left is supposed to connect to 12 volt power. The six short leads on the right can connect to six different 12 volt LED strips or indicators.

The board I used is designed to be able to hold a 20 pin DIP package, but the ULN2803 is only 18 pins. I used the pads for the top two pins to create a common 12 volt positive power pad to solder all of the LED leads together.

This project is not yet functional, and I’m not sure why.

I tested that the LEDS and power were properly connected by using a jumper wire and making content on the ULN2803 to the pins down the right side of the package and the ground pin on the package lower left. I was able to light up the LEDs individually using that method.

It has been suggested that I need to run the ground wire back to the APM ground plane for it to be able to send signals on it’s signalling channel. This makes sense to me, but I’m hesitant to do it because I don’t want to burn out my APM while experimenting with the rest of the electronics.

The first links building this style project were using a ULN2003 while I’m using a ULN2803. I’ve not figured out the difference between the two chips, but it’s possibly related to my problem.

Any suggestions as two what I’ve done wrong are welcome.

UAV and GPS Dependency

Last weekend I was attempting to have my UAV fly a couple of programmed missions so that I could get a straightforward video of what I was doing.

My mission was simple, and I’d run similar missions before so I expected this to produce a nice video. I would take off, fly a circle with a 50 meter radius at 100 meters altitude, move to another location and fly a second circle at 30 meters altitude, then return to launch. Here’s what it looked like in Mission Planner.

Things look good in Mission Planner

Things look good in Mission Planner

Things started well, but went haywire a few minutes into the flight. There were a few bobbles as is descended from the first circle altitude to the second circle, but I was hoping to let the on-board computer maintain or recover control.

The flight starts around 1:40 on the video, and things generally look good until around 4:50. At that point the UAV starts making some significant attitude adjustments. Around 5:10 it seems to have recovered and making the adjustments to go around the second circle. (At 5:35 the camera is pointed back towards the launch point and you can see two small dots on the ground. That’s the two of us monitoring the flight with the transmitter and a pair of binoculars.) It finishes the second circle around 6:30, at which it should have initiated the RTL, Return to Launch, phase of its mission. Unfortunately I do not currently have the UAV set to face forward during the RTL phase, and so it does not rotate towards the launch point, just travels in that direction. You can see it tilt slightly back, moving in the correct direction, for the first ten seconds until 6:42, but then it starts making huge adjustments to its direction, running the motors at full throttle. At 8:08 it hit the trees.
After the flight I downloaded the log file from the UAV and tried to analyse what went wrong. I was able to produce this picture using Google Earth from the resulting KMZ file.

Mission Gone Bad

Mission Gone Bad

I’m still not sure exactly what went wrong. I believe that the copter lost resolution on the GPS, simply based on the fact that the track never shows it going to the trees, and I don’t remember it doing as much spiraling as the KMZ would indicate. The KMZ file may be available at my home server but right now it does not appear to want to serve kmz or kml files.  The descent from the first circle towards the second circle appears smooth until it no longer needed to travel horizontally, At the point when it needed to only reduce altitude it seemed to circle and appeared to be much more unstable. Perhaps making sure that all programmed descents had much more vertical motion would produce smoother flights in general.

A few valuable lessons that I learned, in no particular order.

  • Stick to flying where there are no people nearby. Even at an RC airplane field with a few experienced people around, this could cause significant injury to humans or damage to property. When the copter was coming in fast towards the landing area, and obviously going to overshoot into the trees, completely losing the copter in the trees is much better than causing any injury or damage to someone else.
  • Be quicker to abort an automated mission and take manual control. I had handed my transmitter to a more experienced pilot while I monitored the automatic mission via binoculars. Several times he asked if he should take control of the unit and I told him that I wanted to see if the unit would recover itself. The early bobbles during the descent from the first circle to the second it recovered, but the RTL path was completely wrong.
  • Give the UAV plenty of time to achieve a reliable GPS lock before arming the motors and taking off.  According to what I’ve read, the launch location used for the RTL function is stored when you arm the motors, not when you actually leave the ground, or power on the entire copter. Landing and disarming the motors in a second location would reset the launch location when you re-arm them.

An interesting thing I’ve noticed by following the drone chatter on the hype meter is how much of a clash this is causing between the computer and robotics crowd and the traditional RC airplane crowd.

The traditional RC airplane hobbyists have been around for over 50 years, and have slowly been integrating new technology such has digital radios, electric motors, and Lithium Polymer batteries into use as the technology as become available. Historical fixed wing aircraft and analog transmitters required large open spaces for both safety and to make sure that there was no radio interference. Liquid fueled model aircraft produced large amounts of noise, and so added to the reasons of working in large open spaces.

The person coming into the UAV/Drone space often has no background in the RC airplane hobby itself and so has no history of the safety requirements and why they exist. Starting with a quadcopter and its capabilities is completely different from starting with a fixed wing aircraft. VTOL, vertical takeoff and landing, brings a confidence that this can be done in a small space, however misplaced that confidence may be. First person video (FPV) seems a natural extension to most new pilots and the concept of limited bandwidth is completely alien.

There are good organizations such as that exist for hobbyists, but the person getting into it from the computer side of things often may not even know about them, and an unattractive web site may cause lack of understanding of the benefits offered.

I would not have gotten into this at all if a friend that I’ve known since we were in 4th grade had not added multi rotor copters to his long standing hobby of RC Airplanes. He was telling me how much was available in the new systems, and showing me first person videos on his screen. The fact that he was using all of these digital systems, but his video was still analog, was what got me interested. I wanted to be able to record the entire flight digitally.

I’ve been extremely lucky so far, not having damaged anything or injured anyone, and not broken more than $30 worth of items on my ‘copter so far, let alone lost it entirely. I’ve still got plenty to learn, as well as learning to be much safer, but I’m enjoying the process so far.