Unmanned Arial Helicopter Project

Sean Reynolds, Brad Schenck, Ryan Johns Washington University in St. Louis seanreynoldscs@gmail.com, schenckb@gmail.com, raj3@cec.wustl.edu

Abstract
This paper presents the practicality of using embedding devices to autonomously fly a remote controlled helicopter. The goal of the project was to determine if cheap embedded devices could maintain a stable hover when used on an inexpensive toy helicopter. We discuss various design decisions and challenges concerning hardware, software, and flight control algorithms. The problem of unmanned flight proved more difficult than expected but the project served well as a proof-of-concept that truly autonomous flight could be obtained using mounted sensors and embedded devices.

1.1 1.2 1.3 1.4 1.5 1.6

War in Iraq Dangerous Jobs Undesired Tasks Efficient Tasks Entertainment Research for others

2. Related Work
Several attempts have been done in the past. The problems are that most of the helicopter projects in the past are not complete and or too expensive to be practical.

Through the use of mounted sensors, the embedded device responds to the environment and corrects its flight in real time. The challenges of autonomous flight are similar to that of remote controlled cars or other devices, but the added challenges of a helicopter are enormous. The Helicopter has a much more reactive system than that of other devices. The way we monitor the environment is through the use of an inertial measurement unit (IMU). The inertial measurement unit is a device which incorporates the use of accelerometers and gyroscopes to give accurate readings of the way the helicopter is moving through space. The accelerometer is a 3 in 1 device, in that it incorporates all three axis into three different pins representing x, y and z.

2.1

DiyDrones

http://diydrones.com/ Diy drones is a forum of amateur engineers posting projects related to unmanned aerial vehicles. There are many videos and how tos for amateurs to collaborate.

1. Introduction and Motivation

There are many things in this world that humans need to make computers do. Up till now computers have slowly been replacing remedial tasks in the workplace and home. The transition these days is that computers are handling more complex jobs in the same environment that we work in.

Most of the projects posted on diy drones deal with airplanes, but some utilize the stability of blimps, and one project on this site uses a helicopter called a TRex. The blimp projects would be much easier to control, and

becaue of their slow speed, any unwanted drift would be virtually unnoticeable. The airplane projects are obviously all outdoor projects. The frames for the airplane projects are typically more expensive and some of the planes used are over 10 feet in wingspan. The TRex project on this site is very promising. It uses the TRex helicopter frame for flight. The TRex is a helicopter which is just over around 1000 fully assembled. It is a light battery powered aircraft with a flight time of around 10 min. It can do upside down maneuvers as well as the most tricky of Chaos maneuver. The TRex has the ability to invert its blade pitch. This allows it to hover upside down the same as it can normally. Helicopters like the TRex are also able to carry a significant payload. This would be the ideal frame for a continuation of our project, one we can show the systems working.

found us by our Google Code site, and wanted to work together on our projects. Toward the end of our project we contacted them again to find out how far they had gotten. As it turns out their project was placed on hold. Due to budget issues, but they were starting it up again next autumn. He was very interested to know about our accomplishments and pointed us toward the hardware they had their eye on. Future collaboration between SJSU and WASHU is completely optional, but very open. They were very willing to collaborate.

2.3

Viacopter

Viaopter is a site dedicated to unmanned helicopters. It is the project site for the TRex project from Diydrones, but it has other project links and source code as well. The parts that they use are not as advanced as the equipment we used for our project. The accelerometer pictured below is around one cubic inch in size where as ours is the one square inch. The extra weight of sensors like this ultimately means that the desired payload such a s camera must weigh less. The projects from Viacopter seem to be on hold. It appears that they were able to make it work, but then could not find a way to make money from it and simply posted what they had and gave up. Their source code is available but we did not use it. Future extensions of our project should look heavily at other projects such as this to provide a utilitarian heads up for expansion of our project. We are very much inclined

On diy drones, the TRex project uses older style sensors which are much larger and more expensive. They even tape a full camera onto the front. It is clear that they did not have to consider weight in their project.

2.2

SJSU

After we had posted out google group and google code site, another team from SJSU contacted us asking for help. We Told them about sparkfun and we were somewhat apprehensive to give over too much detail about processor choice or sensor choice but felt it was nice enough to tell them about Sparkfun.com. The gentlemans name who contacted us was James Pham. He wanted to know which helicopter we had chosen along with our choice of micro controller. He

to advance this project and push it past the stages that Via copter was able to reach. Projects like ours and Via copters have a much greater potential for income than via copter was able to utilize. Projects such as aerial photography alone would more than pay for parts and time. These ideas for income are detailed in the last section of this paper.

communication with Xbee could be understood and utilized for our helicopter project in the future.

2.5

Automation and robotics research institute

2.4

Paparazzi

Paparazzi is an open source collaboration on unmanned aerial vehicles. It is based out of Germany where they gave their first keynote presentation just over a year ago.

The ARRI projects are based out of Texas in the USA. The project is also using the TRex helicopter. The project over uses hardware, with utilizations of motherboards, canbus and wifi, the project is limited greatly to airframes which can support large amounts of weight. The problem with a system like this is that it reduces not only the effective payload capacity, but it also limits mobility. If this project weight can be minimized then the overall maneuverability would not be compromised, and the TRex airframe would be utilized to its maximum potential.

The uav Paparazzi project is only designed only for the outdoors. It only uses planes but they detail all of the hardware they use for this project. They have advanced systems for collaboration amongst multiple craft as explained below. The project is only designed for outdoors because it uses thermal sensors to detect the planes pitch and roll. When the aircraft takes it temperature inferred readings it compares the two sides and the front with the back. If it detects that there is a temperature difference between the two sides they are able to adjust the flaps so that the plane balances back out. This only works because there is a measureable temperature difference between the earths surface and our atmosphere. This approach has MANY many issues. The fact of the mater is that a temperature difference is not always accurate. When approaching a cold front for instance you dont want to be able to approach with disreguard for that cold fronts obscure temperature difference. The project is only designed for airplanes, and to accommodate for the way that they fly through the air. The way that a helicopter works is fundamentally different than that of a plane, but the fundamental principles of sensor feedback and correction in real time remain the same. This project has to balance the temperature difference from the sensors on the wings and correct for that with flaps. The helicopter project needs to take a measurement of the accelerometer sensor and adjust the corresponding servo for correction in that direction. The bottom line is there is a lot from this project that could be utilized. Everything from sensor correction methods to integration of multiple aircraft into one seamless application for control, down to the radio

As you can see the TRex airframe is able to support a much larger capacity than our CX2. This means that once our system works it will be able to yield much greater results on airframes such as the TRex. The ARRI project began its work on a swivel arm which would allow the helicopter to move in a very restricted way in side of a 5 foot radius without crashing. This is much like our training skids. This radius arm would restrict the way the helicopter moves a great deal, but once a systems was developed which would yield good results with the radius arm, it could then be removed from the safety harness and tested in a live scenario such as a mobile computing lab.

3. Problem
As we transition from a world where computers are on a desk to a world where computers occupy the same space that we do; several issues arise.

3.1 3.2 3.3 3.4

Harder problems are easy to automate. Subconsciously easy tasks are hard to automate. Helicopters are hard to fly. Project Setbacks

Before we could mount the sensors on the airframe, we had to get an idea of the values they would output. To do this we installed the microcontroller and a 5-in-1 accelerometer and gyroscope on a breadboard. The 5-in-1 sensor unit contains a 3 axis accelerometer and a 2 axis gyroscope. We monitored the sensor readings as we manually mimicked helicopter movement by sliding and tilting the breadboard around the table. Once we had a handle on the sensors readings we were ready to mount everything on the helicopter and begin developing a hovering algorithm. We decided to focus first on the aileron and elevator servos while we maintained control of the throttle and rudder via keyboard inputs. Our first algorithm used a simple linear mapping between sensor value and servo position. For example, if the x-axis accelerometer indicated the helicopter was moving to the left, the aileron servo was set to move the helicopter back to the right. This 1-to-1 mapping immediately exposed a major problem we were going to have to deal with. There are significant vibrations throughout the body of a small, lightweight helicopter like the one we were using. All these vibrations were causing the sensor reading to jump all over the place. The effect of the rapid spikes caused the servos to also jitter wildly. We attempted to cancel the effects of vibration by buffering the sensor input readings by maintaining a running average of the last n readings. This gave us the net change in direction and effectively eliminated the effects of vibrations. Once the vibration problem was solved, another problem began to surface. We were using accelerometer readings directly to manipulate the necessary servos. The problem was that if the helicopter began to drift at a constant rate in any given direction the helicopter would not automatically correct itself. This is because the acceleration of the helicopter was constant even though it was still in motion. The apparent solution was to integrate the acceleration values to determine the velocity of the helicopter and to integrate again to get the distance travelled per given time period. Integration is a computationally intensive operation and we were worried at first that the microcontroller would not be fast enough to perform the integration in real-time. Our fears were never realized however as the microcontroller seemed able to keep up. We began testing the new integrating algorithm but quickly realized that the weight of the helicopter was affecting our tests. The helicopter did not have enough power to lift itself along with all the additional hardware and wiring we mounted onboard. As a result, the helicopter was forced to fly very near the ground

4. Plan Dissection
We set out on a very ambitious goal. We set out to have the helicopter fly itself completely. The project was originally divided up into several stages, each of which is discussed below.

4.1

Stable Hover

For the first stage, the goal was simply to get the helicopter to hover in one position with no human control. The first step toward stable hover is to emulate the controls received by the helicopters radio receiver. We hooked the receiver up to an oscilloscope in order to monitor the various electrical signals being emitted. The receiver has 4 output signals in total; throttle, aileron, elevator, and rudder. The signals for throttle and rudder are passed into a proportional mixing circuit onboard the helicopter which determines the amount of power to each blade required to achieve the desired lift and rotation. The aileron and elevator signals are sent directly to 2 servos that control the helicopters forward, reverse, left, and right motion. The stock transmitter uses pulse width modulation to deliver each of the four signals to the transmitter in a specific order. It turns out that the order only affects throttle and rudder as they require additional onboard mixing. The servo control library we were using to programmatically emulate the radio transmitter required some modification to meet the helicopters expected protocol. The default behavior was to turn all servos on concurrently and then turn them off as needed. We needed it to turn on and then off each servo in a particular order with no delay between when one servo turns off and the next servo turns on. Once we had the servo librarys behavior in sync with the behavior of the transmitter we were ready to map sensor input values to servo output degrees.

sometimes touching at one of the corners. The ground effect produced by this situation was disrupting the tests and we were never able to truly evaluate or fine-tune the new algorithm. Since the work had to be completed in a semester, time constraints prevented us from attempting the remaining three goals.

4.5

Project Progress

4.2

Forward Flight

For forward flight, the helicopter would be required to break out of stable hover, move in some direction, and then re-enter stable hover. For this stage of the project, the helicopter would have no way of sensing its environment and would simply fly a predetermined route before hovering again.

The project never made it out of the stable hover phase due to a number of reasons. First, there simply is not enough time in one semester to work out the incredibly complex nature of helicopter flight. Second, the array of sensors and control hardware required to react to any potential situation add too much weight to a small toy helicopter. Third, the small size and light weight of toy helicopters make them very twitchy in the air. Fullsized helicopters and even large toy models are much more stable in flight and respond more smoothly to flight controls. Even though the project was never completed, it was still a valuable learning experience. We learned how to analyze electrical signals with an oscilloscope. We also learned how to program an embedded device to read sensors and control servos. Most importantly, we had a lot of fun attempting a to solve a problem that humans can learn quickly but is very difficult for a computer.

4.3

Avoid Obstacles

Obstacle avoidance is the next logical step for an autonomous vehicle. In order for the helicopter to avoid flying into object it requires additional sensors. We were going to use several sonar sensors mounted around perimeter of the helicopter to tell us the distance and direction to the nearest object or objects. At this stage of the project we would have to move much of the computation from the microcontroller to a laptop due to the increasing processing power required to control the laptop during such complex movements. This change would be relatively simple because we were already using a Bluetooth module for wireless communication between the microcontroller and the laptop. During the stable flight phase of the project we used the Bluetooth module to remotely control the throttle and rudder and to monitor what was happening with the sensor inputs.

5. The Future of helicopter robotics

When completed, our project would change the way the world considers computers amongst us. Through cheaper unmanned computers, we would slowly but surely encounter a world where interaction with computers is more of an everyday occurrence.

5.1

Saving solders lives

As a solder is behind a brick wall, He hears gunfire then it stops. This is his time, they are reloading. The problem is that the aerial drones circling overhead are planes. He has this one moment to react, but he needs exact pictures from a precise location which can give him the details of where the enemy fire was coming from. We have today at our disposal technology which can save many lives overseas. What more could we want? Well the issue is that a plane is good for some things and bad for others. As our armed forces have noted, by development of helicopters in the first place, there are some tasks which are uniquely suited for helicopter deployment. With an unmanned helicopter set on a flight path to go up 50 meters and hover, giving aerial photography, the helicopter project becomes very advantageous. When you factor in the unique maneuverability that RC helicopters have in their dominated airspace, you can rest assured that that eye in the sky is there to stay.

4.4

Search and destroy

The final planned phase of the project was to have to helicopter seek out a target fully autonomously. The helicopter would be given a target that it would have to locate. We came up with two possible methods for assigning a target. Either the helicopter would produce a map of the surroundings on which we could designate a target or we would equip the helicopter with an additional sensor that could find another transmitting sensor placed somewhere in the environment.

Helicopters could be deployed from a backpack and take off vertically without the need for a runway. It quite literally could be your own personal eye in the sky and with a price tag of under 500$ this eye is worth every penny. The other great thing about the smaller helicopters is that they are electric. Without a noisy motor, it is possible to reduce the noise of an electric helicopter quite significantly. This means enemy units wont even know they are being surveyed until its too late.

purpose. With the use of highly mobile robots, we allow architects to dream of any structure they desire and allow the robots to work out the practicalities of the buildings maintenance.

5.3

Undesired tasks no longer take time

Currently there are many applications of robots designed to take care of our less desired tasks. Everything from a dishwasher to a laundry machine does just that. We are becoming accustomed to allowing computers and robotic actuators to handle our undesired tasks, but it doesnt end there. IRobot in Boston is a company which produces both military and domestic robots for specific purposes. They have a robot for instance which cleans your carpets. It maps out your room and detects dirt, and searches your floor for areas to clean without bumping into things. This is still seen by mainstream homeowners as a little odd, but it is defiantly picking up acceptance. Just imagine that while youre working, your house could be cleaning itself. This gives humans more time to produce more ingenious and artistic creations. IRobot also has a device which cleans gutters. Before they came along, you would be required to move a huge ladder from one end of the gutter to the other foot by foot, and remove leaves from your gutter. This device however gets deployed from one end and knocks the leaves out until it reaches the other end, where it waits for you to come and collect it. This means you only have to position the ladder in a constant two places rather than n (the length in feet places). Saving us time has become the newest market of the future. When we have more time we can do more, and ultimately that improves everyones life.

5.2

Saving lives in the workplace

There are many dangerous jobs in the workplace. Inspecting is one of the most tedious jobs that require a human. The problem with people doing inspecting is: we really only need our eyes. The rest of our body is in peril only to get and keep our eyes on the correct spot. For instance, bridge inspectors need to inspect for cracks in bridges over all of America constantly. This never ending job is quite dangerous requiring expensive equipment to get the workers to their desired heights. But ultimately they are just LOOKING for cracks. This is the type of a job that can be offloaded to a helicopter. Currently there are sensor networks monitoring bridge harmonics looking for disturbances in the wave forms they receive. However there are many false positives. And while reducing the number of places workers must look, workers must still look to inspect these places. The advantages of having a highly maneuverable aircraft to go and inspect these locations on specific flight patterns are quite substantial. A helicopter could be ready to fly in seconds, and on site in place in minutes. It could relay the video information to a human watching from a monitor in a remote location. This One human could be monitoring and deploying drones throughout the entire city! And only when a particular problem is spotted does a human life need to be secured in location and deployed to fix a dangerous problem. There are other tasks which automated robots are keen to do. Window washing is another situation where a precious life is hung in ominous positions. Robots which can reach remote locations and deploy specialized equipment can make this task much more efficient and much less risky. Today there are systems installed on buildings which use pulley systems to automate window washing down the side of a building robotically. The problem is that systems like this require a huge infrastructure and are expensive to install. Another issue is that they only work for highly uniform structures. So this removes the architects creative design for a practical

5.4

Things run more smoothly and save money

Factory workers, of the early 1900s, found when you make machines to do our tasks they get done the same way every time. We use machines constantly for consistency. They dont need to take breaks and they are able to do things for specific tasks that we cant do such as heavy lifting. With highly maneuverable robots doing our tasks we dont need to worry about them being tired. They can work reliably and consistently day after day. Imagine the extra level of assurance you can guarantee when we remove human error from things like inspecting.

5.5

Kids have more fun

With a helicopter system like ours, younger kids could enjoy the controls of a helicopter without having to worry about crashing. Our target system would be every bit as maneuverable as the RC helicopter, but would be interceding the controls to avoid obstacles and ultimately promote safety. The RC industry would see a new market of more expensive Devices in the hands of youth because parents would be more willing to allow their kid to fly a helicopter which is less likely to crash. They could sell a bolt on kit such as ours, on top of the existing platform to keep the helicopter safe in the hands of new pilots. Our system is essentially crash insurance.

5.6

Students get more education.

With our platform in mobility, students could step away from the more complicated hardware and focus on the creative software navigation. Students could learn more about optical sensors and interact with real world devices straight out of the box without having to worry about their control inversion taking the helicopter down with an unwanted crash. This type of an onboard system would allow researchers to tinker with, and see directly, real world applications of their most complicated algorithms. When we see these algorithms working themselves out we can notice new ways to improve them. We can get a deeper understanding of search space and ultimately allow more people to work on the most advanced types of algorithms. When the PC came to everyone home we saw an explosion of young developers taking advantage of the new tools it offered. The same could be true for these simple robotics. They would allow more people to start younger and develop more complex systems for today and tomorrow.

5.7

Summary

In conclusion platforms like the ones we have developed in the project enable people from both sides of hardware and software to come together and start from a common place working toward a more complex goal. They enable younger kids to play and design. They enable everyday people to have safer and more productive lives. They give our country an added way to defend itself, and they unlock the doors of tomorrow with the keys of tody.