Fully Autonomous Plane

The thinking man's plane!

By HappyPaul55^[a]

Contents

Introduction

Goals

Goal 1 - Learning to Fly

Buy a plane

Take some lessons

Return notes and knowledge

Goal 2 - Installing Hardware

Buy required items

RPI

Gyroscope sensor

GPS Module

Camera

Proximity sensor

P2P Wireless

Trim excess wires and remove unwanted weight

Add the devices to the plane

Get each sensor into our program we can read and control

Write the information to file

Check the information for bugs

Goal 3 - Processing Data

Gyroscope

GPS Module

Proximity sensor

Camera

P2P

RPI

Goal 4 - The First Flight

Take off

Take over

Flight

Landing

Landed

Finish

Goal 5 - The Second Flight

Teaching to take off

Teaching to land

Teaching to turn

Goal 6 - Tweaking/Improving

Goal 7 - Downgrading/Improving

Goal 8 - The End

Goal 9 - Going one step further

Using the RPI

Without the RPI

Technical Jargon

Files & Programs

Locations

File-types

.CAP

.KML

.LOG

Programs

autoplane-ailerons

autoplane-buggeroff

autoplane-camera

autoplane-errors

autoplane-gps

autoplane-gyroscope

autoplane-manager

autoplane-proximity

autoplane-tracking

Constants

MinSpeed

MaxSpeed

MaxRotation

NormalRotationIncrement

MaxRotationIncrement

MaxFlightTime

CommandTimeout

Creator

Version

ChecksumSalt

ProxPollRate

GryoPollRate

GPSPollRate

LandingDistance

Error Management

Parts

Credits

HappyPaul55

Raspberry Pi Foundation

Linorics

st599

flipdewaf

Fred Nightingale

You?

Questions & Answers

Why lots of programs?

What happens if there was a full system crash?

It’s not legal!

Is it a Fly-over-wire (Fly-by-wire) based?

Is the Gyroscope capable of keeping the plane level?

Now it’s my turn, What programming language do you think would be best for this project and why?

Development & Programming

Call for developers

Functions that need to be created

getSpeedFromPoints

getBearingFromPoints

The aim is create a fully autonomous plane capable of flying from point to point including waypoints in between. The plane should be capable for flying for half an hour on its own power supply and house enough space to hold additional modules which are unrelated to the flight of the plane.

The build should be goal driven and be built in sections with tests along the way.

The first goal is to learn how to fly a plane. This will give us the knowledge and steps required to fly a plane. We should be able to take off, turn and land the plane without any accidents.

1. Buy a plane

1. First we need to buy a plane. The plane should be electric, lightweight and house enough room inside for our hardware and additional modules.

2. Take some lessons

1. We then need to learn how to fly a plane so that we can correctly teach the computer to safely control the vehicle.

3. Return notes and knowledge

1. We should return notes on how to fly the plane in normal conditions and windy conditions^[b]. If possible knowledge on the plane reacts when wet we would be desirable

The second goal is to install all the required hardware and get the raw data to the RPI in a format our program can understand.

1. Buy required items

1. RPI

1. Model B

1. For testing and debugging

2. Model A

1. After completion, uses less power, longer flights

3. SD Card

1. 8GB, 16GB or 32GB so we can log everything to file

2. Gyroscope sensor

4. To keep plane level
5. Controlled in flight corning and rolling
6. Speed

3. GPS Module

1. Location tracking and targeting
2. Speed^[c]

4. Camera

1. Record flight
2. Possible usage for collision detection

5. Proximity sensor

1. Long Range: Prevent crashing into objects in front
2. Short range: Prevent crash landing

6. P2P Wireless

1. Receive update commands
2. Report failures, warning and completions

2. Trim excess wires and remove unwanted weight

7. Lighter the better
8. Longer flights

3. Add the devices to the plane

1. Try to keep the centre of gravity throughout the plane set to the Aerodynamic center. (26% according to an anonymous commenter)

4. Get each sensor into our program we can read and control

1. Nothing has to done with the data. It just has to be able to updated regularly

5. Write the information to file

1. Each sensor will have its own file
2. Dates and times will also included in the name
3. Example file /logs/autoplane/2012-03-13.GPS.log

6. Check the information for bugs

1. If any errors go back to step 4

This goal will get the data from Goal 2 and create useful information from it using our software.

1. Gyroscope

1. Using the Gyroscope information we need to figure out how much we have to alter the aileron to reach our target rotation.
2. For this goal the target rotation will always be level and should be able to keep the plane flying in a straight line.^[d]
3. This should be tested by rolling the plane on whilst still on the ground. Results should be visible

2. GPS Module

1. For this goal we should be able to tell it a way point and the program should be able to work out the distance, and rotation need to fly to the point.
2. This should be tested by taking the plane to different places and keeping the waypoint the same.
3. Another test will be keeping the plane in the same spot and telling it different waypoints.

3. Proximity sensor

1. To prevent a crash landing the proximity sensor should fire a warning when the ground is less than LandingDistance away.
2. To test this the plane should be picked up avoiding the sensor and moved slowly to the floor. This test should be repeated on different materials and grounds. Including; Wood, Concrete, grass and soil.

4. Camera

1. The camera should be set on a timer and be able to take key snapshots every X seconds.
2. If the picture is 90% or more black it should fire off a warning.
3. Test should be completed by slowly moving black paper in front of the camera 5 cm away from the lens.

5. P2P

1. The plane should be able to receive commands from a command center.
2. Commands should include;

1. Kill Switch
2. Remote control
3. Update waypoints
4. Power-off
5. Poll

2. Commands should be set with a checksum to prevent against any attack

7. RPI

1. All programs and tests above should all run at the same time. If the CPU reaches anything above 80%, optimization must be done before the next Goal starts.
2. The RPI must be fully protected from all possible damage, including;

1. Water
2. Light
3. Shock
4. Temperature
5. Power surge

This is the part where the plane gets to have its first semi-autonomous flight from point to point.

1. Take off

1. First we have to get the plane up in the air

2. Take over

1. This is where the RPI gets control over the plane
2. This has to be done in a clear, windless day over open land.
3. The kill switch and takeover commands must be ready in-case of an error

3. Flight

1. The plane should be able to fly itself to the landing point which should be a straight line.

4. Landing

1. The plane should be take back over control by the command center.
2. The command center should land the plane.

5. Landed

1. Everything should be written to file and the kill command should be sent.
2. Pictures should be take for anything that is possible broken

6. Finish

1. Everything should be checked and all the files should be looked at for any possible fault. If there is any fault it should be fixed. When fixed the test should run again until no bugs or faults are spotted.
2. Also if weight balance needs to be changed it should be moved to the nose of the plane to increase handling which may slow down the plane a little, but this isn’t a bad thing.^[e]

This is where the plane learns to take off, land and turn.

1. Teaching to take off

1. In Goal 3, Stage 1 we set the target to level. Extra lines should be added to support climbing and descending.

1. The target rotation should never be allowed to increase unless speed is great then MinSpeed.^[f]
2. Equally the plane should never be allowed to land if speed is more then MaxSpeed. Unless battery flight time is less than 10%

2. When the plane receives its first way point it’s allowed to start the propeller.

2. Teaching to land

1. The plane should automatically get ready land when it’s heading towards its last way point.
2. The plane should decrease its speed to MinSpeed + MinSpeed / 3
3. When the proximity sensor reaches LandingDistance meters speed should drop to MinSpeed
4. When proximity sensor reaches less than ~1/2 wingspan; speed should fall to 0 mph and the nose should be pulled upwards.^[g]
5. When speed reaches less than 5 mph power to the propellers should turn off.

3. Teaching to turn

1. In Goal 5, Stage 1a we added more lines to support climbing and descending. This time we add support for rolling.

1. To calculate roll it should be: target rotation + target rotation / 3
2. The rotation should not be aggressive. IE Jumping target from 0° to 33° except when recovering from excessive roll. See below.^[h]
3. Roll should never be more then MaxRotation or less than -MaxRotation. Same applies to pitch.
4. Roll should never take place when the proximity to the floor is less than 1 metre.

Everything should be in place now. It just needs testing and tweaking.

1. First we shall go through Goal 4 again just to be on the safe side

1. If everything goes well continue otherwise fix whatever is wrong

2. Now we let the plane take off and land on its own

1. As before, get ready to take over in case something goes wrong

Now that everything is working on a Model B we need to replace it with the Model A and get everything working again. When the plane is capable of flying on its own again the MaxFlightTime can be increased because there will be less power consummation. This will also make the product more affordable to other who follow in our footsteps.

When the project is fully completed the source code to all programs should be released to the public under a share-and-share-alike licence. Pictures should also be put up along with any diagrams. The final thing to do would be to inform RPI and the local news.

Now that the plane is stable and out in the public we need to do something extra. Using the spare Model B we should build something to add to the plane which has nothing to do with the flight of the plane.

To make more use of the data we collect the two RPIs should be put in sync. A program should be created to merge the two KML files created to make it easy to read later on.

1. Weather logger

1. A USB stick that monitors humidity, temperature and dew point
2. Link: http://goo.gl/zPhfu

2. Time Lapse

1. Using an alternative camera you can create a long lapse video.

3. Heat sensor (Spy Camera)

1. Using an infrared camera you could monitor the temperature below

1. Fly a Flag

1. You could fly a flag at the end of the plane for sponsorship, fun or because you can

2. Transportation

1. Okay, it’s not big enough to carry a person but if you for your phone, letter or other small item. You could send the plane to collect the objects using the spare space.

Aileron: The control panels at the ends of the wings which create a lift differential to Roll the aircraft

Command Center: Person or Persons’ in charge of the plane

GPS: Global Positional System

Gyroscope Sensor: The rotation sensor

Kill Switch: Turns everything off

RPI: Raspberry Pi

P2P: Peer to Peer connection

Proximity: A sensor which detects objects in the immediate view

Python: Programming Language

Waypoints: Geo Locations

To make things easy for new developers to latch on. Files and programs should be saved in an easy to follow and understand methodology.

All folders should have the prefix autoplane except when already in a folder that contains autoplane in its name. Files that control hardware should be under autoplane_build be named the friendly version of the hardware type. For example; autoplane_build/GPS.file-type Old versions of the file should be in a subfolder of the hardware friendly name. For example; autoplane_main/GPS/version_number.file-type

Cap files record wireless networks that are in range. These can be used as to find an access points for command center if the primary method fails.

This is the primary method of giving way points. It will also the primary output of autoplane-tracking.

These files host the result of every function our program runs. These can be useful for error correcting or improve code efficiency. They should be stored in /var/logs/autoplane/Date Time.Hardware.log. For example; /var/logs/autoplane/2012-03-13.GPS.log.

There are also 3 special logs. These are in the same folder and contain less information but are more important. These files are; warning.log, error.log and fatal.log. They may not always exist if there hasn’t been any errors of that type.

To prevent an all out crash each hardware device should have its own program. For example; to control the ailerons there should be a file called autoplane-ailerons. This allows for much better control over the hardware and also allows for much better error recovery. For example; If the GPS fails and gets hooked which prevents the rest of the program from running, the plane could crash because it wouldn’t be able to inform the command center or revert to another source of information.

All the programs listed below have a set job to perform. They all (except autoplane-manager) also check to see if the autoplane-manager is process is running and if it isn’t the programs will try and start it. An error will also be logged every time one of the programs notice that autoplane-manager has crashed.

This program will read from the GPS, Gyroscope and Proximity results and react by changing the ailerons if needed.

An Easter egg like program that will get the plane to fly in a random direction within one mile of its starting place. It creates a random KML file with random points and gets the plane to use it as if the user gave the instructions. Good for testing.

This program will take snap shots as and when requested. It will also fire off warnings and errors if required.

This program is responsible for handling of all errors. This program main use is to prevent re-writing of code in the other programs. This reduces overheads and lets the programs focus on their main job.

This program will poll the GPS every GPSPollRate for a location and fire off warnings and errors if and when required.

This program will poll the gyroscope every GryoPollRate. If there is a magnetic compass on-board the plane will also work the relative results. This program will also fire off warning and errors if results bypass limitations.

This program is the kill of all the other programs in this package. It monitors the other programs and checks that they haven’t crashed. It also monitors free space, available RAM and individual statistics for all processes. It listens for commands from the control center and takes action if any commands are sent.

This program will poll the proximity sensor every ProxPollRate and fire off warnings and errors if required.

This program uses data from all the other programs including autoplane-manager saves the information into a KML file. The KML file can then be used to see what was happening at any given point in the flight, mainly to be used in Google Earth.

A few constants to prevent abnormal flights

This is used to calculate when to start moving the ailerons during take off. It’s also used to calculate how fast to go when landing.

This is Maximum the plane can fly at. Also used to calculate cruising speed.

Value: 50.This is the plus and minus degrees of allowed roll.

Value: 2. When rolling we slowly increment the degrees by this much. Unless we have go past max rotation

Value: 10. This is the maximum degrees of difference when rolling.

Value: 3600. In seconds this sets the maximum time the plane is allowed in the air. This can be used a double safe for battery limitations.

Value: 360. If we haven’t heard from the command center is this amount of time a warning shall be set off.

Value: . A semi-colon delimited list of names and/or companies.

Value: . The format is; Major, Minor, Release, Build. Separated by a decimal.

Value: . This is used to prevent hijacking of the plane. It should change with each release. Every minor should contain a big difference and every Major the checksum should be totally random from all previous releases.

Value: 0.3. How often in seconds should the device be polled for data. Used to check during landing.

Value: 0.2. How often in seconds should the device be polled for data. Used to keep the plane balanced.

Value: 5. How often in seconds should the device be polled for data. Used for tracking location and direction.

Value: 0.5. When the distance in metres is less than this value the final part of the landing sequence will take effect.

If something goes a bit awry we need to know. All information should be logged but errors are more important and thus have an extra log and also invoke functions to either, compensate, fix or report the error further. For example if an Fatal error occurs a text message to the user would be nice. Or if the engine fails, deploying a parachute would be a great money saver. The error table has being removed because useful text message based errors with allow quicker debugging and error checking. If you wish to use error code you’ll have to create your own folk.

Cheaper the better, lighter the better and if built in England, the better.

<td class="c6">
  <p class="c5">
    <span class="c24">Price</span>
  </p>
</td>

<td class="c2">
  <p class="c5">
    <span class="c24">Status</span>
  </p>
</td>

<td class="c12">
  <p class="c5">
    <span class="c24">Link/Notes</span>
  </p>
</td>

<td class="c6">
  <p class="c4">
    <span>£110</span>
  </p>
</td>

<td class="c2">
  <p class="c8 c5">
    <span></span>
  </p>
</td>

<td class="c12">
  <p class="c5">
    <span class="c0"><a class="c7" href="http://www.nitrotek.co.uk/cessna-ep-400-4ch-brushless-electric-rc-plane.html">http://www.nitrotek.co.uk/cessna-ep-400-4ch-brushless-electric-rc-plane.html</a></span>
  </p>
  
  <p class="c5">
    <span class="c0"><a class="c7" href="https://www.youtube.com/watch?v=CW74WlV7lCU">https://www.youtube.com/watch?v=CW74WlV7lCU</a></span>
  </p>
</td>

<td class="c6">
  <p class="c4">
    <span>£22</span>
  </p>
</td>

<td class="c2">
  <p class="c8 c5">
    <span></span>
  </p>
</td>

<td class="c12">
  <p class="c5">
    <span class="c0"><a class="c7" href="http://www.raspberrypi.org/">http://www.raspberrypi.org/</a></span>
  </p>
</td>

<td class="c6">
  <p class="c4">
    <span>£25</span>
  </p>
</td>

<td class="c2">
  <p class="c8 c5">
    <span></span>
  </p>
</td>

<td class="c12">
  <p class="c5">
    <span class="c0"><a class="c7" href="http://www.expansys.com/globalsat-bu-353-waterproof-usb-gps-receiver-sirf-star-iii-140985/?utm_source=google&utm_medium=shopping&utm_campaign=base&ito=1701">http://www.expansys.com/globalsat-bu-353-waterproof-usb-gps-receiver-sirf-star-iii-140985/</a></span>
  </p>
</td>

<td class="c6">
  <p class="c4">
    <span><a class="c7" href="http://www.expansys.com/globalsat-bu-353-waterproof-usb-gps-receiver-sirf-star-iii-140985/?utm_source=google&utm_medium=shopping&utm_campaign=base&ito=1701">£20</a></span>
  </p>
</td>

<td class="c2">
  <p class="c8 c5">
    <span></span>
  </p>
</td>

<td class="c12">
  <p class="c5">
    <span class="c0"><a class="c7" href="http://goo.gl/m8lsC">http://goo.gl/m8lsC</a></span>
  </p>
</td>

<td class="c6">
  <p class="c4 c8">
    <span></span>
  </p>
</td>

<td class="c2">
  <p class="c8 c5">
    <span></span>
  </p>
</td>

<td class="c12">
  <p class="c5">
    <span>Optional</span>
  </p>
</td>

<td class="c6">
  <p class="c4">
    <span>£40~</span>
  </p>
</td>

<td class="c2">
  <p class="c5 c8">
    <span></span>
  </p>
</td>

<td class="c12">
  <p class="c5">
    <span class="c0"><a class="c7" href="http://compare.ebay.co.uk/like/230728358990?var=lv&ltyp=AllFixedPriceItemTypes&var=sbar">http://compare.ebay.co.uk/like/230728358990?var=lv&ltyp=AllFixedPriceItemTypes&var=</a></span><span class="c0"><a class="c7" href="http://compare.ebay.co.uk/like/230728358990?var=lv&ltyp=AllFixedPriceItemTypes&var=sbar">sbar</a></span><sup><a href="#cmnt10" name="cmnt_ref10">[j]</a></sup>
  </p>
</td>

<td class="c6">
  <p class="c4">
    <span>£217</span>
  </p>
</td>

<td class="c2">
  <p class="c8 c5">
    <span></span>
  </p>
</td>

<td class="c12">
  <p class="c8 c5">
    <span></span>
  </p>
</td>

This project will/would never be completed without certain individuals and companies. Below is a list people I’d like to thank.

C’mon. I’ve got to give myself some credit. I wrote this detailed document for a plan of action, ordered the parts and that’s it so far.

The wonderful people at the charity company gave me the idea with their cheap £22 boards. The forums were thought provoking which gave me some great ideas for me to add, change and remove parts of the program and hardware.

Provided WiFi solutions for short range testing. Centralized and amplified router in the center of the testing area or repeaters around the perimeter.

Brought the Kalman filter and PID controller idea to the board. Also brought up the issue of a complete system crash.

Provided great in-depth information on how to use the data provided by the sensors.

Created lots of useful comments on this document. Provided quite a few insights as well. Overall helpful information.

Okay, that was cheesy but the message is there. You can help build this program by programming additional features, correcting bugs or by building and testing your own planes and providing feedback. You can contact me by e-mailing [email protected].

Well, this is a good question that I know has some debate behide it. The reason is to keep as many programs running at once each with their own little task. This way if any coding issue pops up (like a divide by zero), it will only crash that one program and only one piece of hardware will stop working. Furthermore the other programs can notice a crash and try and restore or compensate.

Good question, I forgot to think about this, so, this solution is an addition. I haven’t got a fully prove creation but I was thinking about using some form of timer that will get reset by the programs every time it completes a hardware request. When the timer reaches zero a parachute will set off and all hardware power will be forced turned of by breaking a switch.

An additional solution is to use a relay switch which will switch between RPI controls and standard radio controls.

First off, calm down dear. Secondly, please say in a question form. Thirdly, No! It’s not illegal as long as I keep my beady eyes on it and have a backup solution if it starts playing up. I’m in the UK, so if you’re doing a similar project please check your with your local authorities.

No, the command center subsection is to create extra features like live stream, live log, updatible way points and so on. The KML files should be placed onto SD card which will be automatically loaded upon start up. After the power on the plane will take off and reach its way point targets. No contact with the command center is required but for safety and curiosity I’ll like to keep to in touch.

To my knowledge, yes. But with clever boffins who read this, they seem to disagree. This is really an answer but more “it's what I know” sort of thing. I thought the difference between a Gyroscope and an Accelerometer was that the Accelerometer provided information relative to the plane. IE the plane is now rolling left... And the Gyroscope was relative to gravity. IE the plane is upside down and rolling right. I’d love to hear some comments.

Make comments by selecting some text, clicking Insert in the top menu and selecting Comment. Best answers with real meaning will be place here. Most development will be programmed in C++. Please note that if you create a project using your IDE, set your environment to ARM and get an emulator.

Okay, so now that most the grounds are set we (or I) need to start the development of the software. The programs should be Lightweight, efficient and to the point.

I love to program, I’ll admit it. This project is quite large and for it to ever reach completion I’d like to share it with the world. I could just put it on GIT or Google SVN and I will, but I’ll also like to have some great people right by my side, the core team if you like. I’d like to say I’ll pay you but to keep costs down, I won’t. ;) I will however buy you a drink at the pub after a test flight if you like.

I don’t hold the key to the wonderful world or Maths or Aerodynamics so I’ll list a few functions which are yet to be created which I may struggle with. I think most information is on this page http://www.movable-type.co.uk/scripts/latlong.html. Update: In fact all functions on that page would be useful.

Two points An array of points contain lat, long, alt will be passed to calculate an average. Return should be a float or false on error.

Using the same two points as getSpeedFromPoints, the function should return bearing from north. If heading east it’ll be 90. Return should be a float.