The AutoPlane Project

Hello,

So, you"re intrested in developing a Fully Autonomous Plane. That"s great, so am I. I"ve teamed up with two of my friends. We have a goal driven approach for this project. Below is a list of the goals and there sub-goals. Remember before writing a single line of code, set clear your goals! No joke, it took me 2 hours to write an in depth action to action plan. This will save me hours of pointless trail/error/failure and removal of code and hardware.

• 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

• Replacing Model B with Model A

Goal 8 – The End

Goal 9 – Going one step further

• Using the RPI


• Without the RPI

I have a few questions for the community. What medium (250 metres) range Wifi hardware should I use. I"d like to be able to update the way points remotely and also take control via shell if all else fails.
Also, I plan to create different programs for each hardware device for stability. If one crashes the other can continue and recover the crashed process. Below is a list of programs I wish/started to create;

autoplane-ailerons
autoplane-buggeroff
autoplane-camera
autoplane-errors
autoplane-gps
autoplane-gyroscope
autoplane-manager
autoplane-proximity
autoplane-tracking

The problem this has gave me is that I don"t know how to let one program "inject" data into another. For example autoplane-manager will inject "addWayPoint 50,-1" into autoplane-ailerons. And autoplane-gps will inject "updateLocation 49.5,-2". I"m guessing something like echo "updateLocation 44,-2" > /proc/113/syscall? Where 113 is the process of autoplane-ailerons.

Also, I"m looking for someone to help code this project with us. As with all my projects I aim to release everything under GPL. Someone in the north of England would be preferable because then you can take part in the physical build if you wish.
I"m aiming to get it completed before the educational release of RPI.
If anyone would like to see my complete plan of action let me know and I"ll send you the Google Docs link which contains much more detailed plan of action

In summary, How do I inject data into one from another? What hardware should I use for Medium range Wifi? And, would you like to take part in development of the software or hardware configuration?

Thanks for reading
Paul
Email: PaulHappyHutchinson@gmail.com if you want to know more about the development or if you can PM or post a comment below.

Edit: Sorry for bad formatting. Not sure what happened.

Someone else will eventually point this out, so, I might as well do it now.  If you're talking about an actual airplane that can carry one, or more people, the regulatory bureaucracy is going to ground you permanently, or at least for a very long time.  As it is, they have to currently close down airspace for at least 15 km around an airport doing this sort of testing in order to prevent interference with aircraft carrying innocent bystanders (i.e., pilots and passengers).  Modifying a real aircraft in any way must be done by people certified to do so if it's a commercially-built aircraft.  If it's an experimental aircraft, it has to be at least inspected by qualified inspectors, and they're going to want to see a very detailed technical plan, along with all of the equipment designs, schematics, as-built drawings, etc.  For starters, WiFi isn't going to be anywhere near as reliable as you're going to need to do this properly for lots of reasons, starting with range/orientation and electromagnetic interference.  Plus, what happens when the aircraft inevitably does fly out of range?  How does it autonomously fly back to within range?  Obviously, a lot of GPS-based software would be needed, but, what happens when, not if, the GPS receiver fails?  What happens when, not if, anything fails, and especially more than one thing fails?

You would be much better off experimenting with a radio-controlled, electric-powered model aircraft, although it would have to be big enough to carry the R-Pi, batteries, and any other ancillary circuitry.  You would still have all of the "What happens when ... ?" scenarios listed above, but, at least you wouldn't have a real airplane falling out of the sky from thousands of feet when, not if, a problem occurs.  BTW, I wouldn't even begin with a model aircraft, I would start with a ground model vehicle and get that working in two dimensions, before embarking on three dimensions.  You could do a lot of troubleshooting even with an aircraft model mounted on a ground model vehicle, thereby saving money on crashing model airxraft, which is going to happen.  Going another level of abstraction, why not just do it all in virtual reality, since the R-Pi has such a great GPU and HDMI video output?  Once you get the simulation working, then you can start spending money crashing model aircraft.

I don't intend to be a wet blanket, I'm just pointing out some things you're going to find out about soon enough.  I do hope you pursue this, just do so safely.  Good luck!

lol. I'm pretty sure OP was wanting to control a RC model.

OP, are you planning on using the RPi to integrate with your flight sensors? If so, IMHO, wrong tool for the job. Have a look at existing Arduino based boards; much better suited. You may still be able to use the RPi in an executive function, but for capturing/acting on real-time sensor data and driving servos, it is not suitable. Have a look at ArduPilot.

Goal 3a - buy a shed load of insurance just in case you crash in to anything expensive.

Unfortunately you won't be able to do it as a hobby project.

If you are a billionaire then you might be able to but otherwise you can't.

To see why go to the CAA website and read CAP722

This only applies if you are in the UK but the rules are similar for other countries.

A few sparks flying around.

So, to clear the air.

It's an RC plane. Flying within the UK, miles away from any airport. It's all legal if you keep your eye on the plane.

The reason I'm using a RPI is because I want to aim also at the education market. I want to make the bare bones software and let the clever kids create creative (ran out of C's) solutions.

Also, it's cheaper to use the indivial parts. And, I've never (almost never) played with GPIO pins before and it'll also be education for myself as well as any copy cat.

nmcc said:

Goal 3a - buy a shed load of insurance just in case you crash in to anything expensive.

I have 3/4s of a mile to play with over a field just out side my backyard. So hopefully I'll be smarter enough not to fly during a football, cricket or bowls game.

Going back to the WiFi thing. It doesn't need to be in constant contact. Just every now and then send a heartbeat and possibly update way points and also while I'm at it, send logs for in-flight fault checking.

Hope that clears the air.

Paul

go do some research on the parrot ar drone - this may be a better platform and it already creates its own wireless lan over which you can communicate

First off "Love the idea".

I've done some research in the WiFi area. First off if we look at the out door range of 802.11g you get 300 ft max and with 802.11n you get 500ft max.

I can see two topologies for the wireless.

1.) Centralized, get one powerful router in the middle of the field running dd-wrt(open source router software). Possibly a wifi amp and better antenna.

e.g. http://www.amazon.com/Premiert.....B0030LVCD0

Limitation: Your range will be limited

2.) Grid Network, get some lower powered routers running dd-wrt and hook them together as repeaters around the field.

Cons: cost would be higher

As far as the programs talking to on another, if you dont want them inside the same process you could use UNIX sockets. I plan on doing this with an RC truck using a grid network.

I love this idea. Cant wait to see where it goes.

Have you seen http://www.diydrones.com loads of info on both equipment and capabilities , also info on what constitutes a self guided missle etc.

I don't know about laws in the UK specifically, but laws regarding UAVs in the US require the pilot to maintain visual contact with the craft AND have a dedicated controller to manually fly the aircraft in case of automation failure. Your current WiFi system probably won't allow you to maintain radio link at all times, so you may have to get a separate radio link just for manual control. Also, for what it's worth, I'm planning on making my own UAV based around the RPi (a quadrocopter not an airplane), and instead of using WiFi, I'm actually planning on using a mobile broadband card to allow me to fly it pretty much anywhere. Probably too hefty for your needs though.

You could use a Kalman filter and PID controller in the main code.

Why have lots of individual programs?

How is system redundancy achieved?

Few things to think about:

Weight: Obviously with aircraft weight is the enemy, try to keep this as low as possible. Extra weight will make it need to go faster to get off the ground (also accelerating slwer to get there, harder to control, slower in flight, use your batteries quicker, harder to land (and many others beside).

The distribution of the weight is also very important, you have to keep the static margin within the capability of the aircraft used (keep it balanced right) but dont be tempted to move small bits long distances to get the required centre of gravity. Remember that as you move things away from the centre of gravity to balance things the inertia goes as the square of the distance so sticking a weight in the nose will likely make the aircraft sluggish (but remember that this may be an advantage later on).

Control systems: You'll basically be doing FBW (fly by wire) to control the aircraft but I assume that you won’t need quadruple redundency like airbus use. Basically FBW means that you (orperhaps your guidance computer) will have to ask the control computers to gave you a certain outcome. In reality you will have to set it up to continuously look for an outcome.

There are many different controls on a fixed wing aircraft but there are only so many you are likely to use on a project like this. Pitch, Roll, Yaw and thrust, although you can probably forget about yaw for this aircraft

For many of the controls you will need fairly high speed PID control to effectively 'hunt' for the desired outcome. You then have to choose what outcome it is that you are actually looking for, this could be:

For roll:

Roll input equates to a target roll rate

Roll input equates to a target Bank angle (Better for navigation so I’d go with this)

For airspeed

Throttle position equates to a target airspeed (I’d go with this one)

Throttle position equates to a target acceleration

For pitch

Pitch input equates to target pitch change rate

Pitch input equates to target acceleration (G Loading) (I’d suggest this one, as its easier to make level turns which is very important)

There are certain basic pieces of information you will have to know to complete an automated flight:

Altitude (above ground level is a must to avoid crashes) There are a number of ways to do this, GPS is not one of them.

Pressure altitude

Bank angle (need a gyroscope)

G Loading

It is very complicated to allow an aircraft to be controlled by a computer, you have to break down all the processes that a pilot goes through to control the aircraft which involves a lot of feedback loops and different instruments in a very dynamic environment. If you want to know more please ask me.

Fred

By "Gyroscope" do you mean some kind of true level sensor, or an accelerometer?  The accelerometer doesn't tell you your pitch or bank angles directly, only their accelerations, it needs software integration to maintain a true bank/pitch angle.

I think you need one big program - you write one program to control the elevators/ailerons/rudder, continually reading sensors to achieve this.  Your direction to fly in takes a lower priority. (Robot subsumption architecture is one fancy phrase to google.)

Also, do you know any control theory? (PID control loops, etc. will probably be needed among many other things.)

If you don't have a lot of background in control theory, try Udacity. They have a free class on robotic cars that is running right now (http://www.udacity.com/overvie.....urse/cs373). All of the things you learn can easily be applied here.

This is why I love the open source community. Some many great ideas floating around.

I've created a public version of my goal plan which you can view on Google Docs.

You are all welcome to add comments. If you don't know how to use Google Docs, simply highlight where you'd like to comment, select Insert from the menu and click "Add comment".

What happens if there was a full system crash?

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.

Why lots of small programs?

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 there 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. Further more the other programs can notice a crash and try and restart or compensate.

Sorry if I didn't reply to your comment. I tend to read it and then write about it in my private Google Docs plan. I will update the public Google Docs every week until the project is completed.

Thanks everyone

Why use wifi at all? Why not 3G/GPRS and a basic external webservice that hosts a heartbeat data file. The the plane will heartbeat every few seconds and pick up commands from the web service. Then you could have controls on a mobile device that post to the same web service to update the heartbeat file.

And similarly the plane could post
Sensor data to the web service. You could write in logic to say power down if 3 heartbeats failed etc.

kghunt said:

Why use wifi at all? Why not 3G/GPRS and a basic external webservice that hosts a heartbeat data file. The the plane will heartbeat every few seconds and pick up commands from the web service. Then you could have controls on a mobile device that post to the same web service to update the heartbeat file.

And similarly the plane could post
Sensor data to the web service. You could write in logic to say power down if 3 heartbeats failed etc.

Hello,

I've decided not to use GPRS because I don't really have a clue about how to go about creating a lightweight "phone". I could use an old android phone but I'm already sticking my neck into the unknown and I don't want to push it out too far. If someone has extensive knowledge in this area then maybe I'll start to think about it. Also, I'm running out of inputs even if I wanted to. But, I'll keep an open mind if some has the required knowledge.

Thanks everyone

Paul

theres a plethora of mobile network units;

http://www.coolcomponents.co.u.....p?cPath=26

all quite lightweight....

viciouspenguin said:

theres a plethora of mobile network units;

http://www.coolcomponents.co.u.....p?cPath=26

all quite lightweight....

It's all very nice and well just adding stuff to it but it's not really the point of my project or the RPI project. I've already bitten of quite a lot and I don't really want to push it and make a bloated project that may never get finished.

Maybe i'll add it after everything else is completed.

Thanks for the link

Paul

I second the suggestion to go to DIYDrones.com and read about the ArduPilot (mega). They've been doing this stuff for years.

The RPi has a way more processing than the ArduPilot (way more even than the mega), but far less I/O (than even the original ArduPilot). The DIY Drones folks upgraded (to the mega) for more I/O at least as much, probably more, than for CPU.

Bottom line: RPi's meager GPIO pins will not be up to the task. Yet a simple Arduino does have sufficient CPU to handle the math.

One thing you need to be aware of, those small, lightweight "gyros" are rate gyros, not position gyros such as used in old-timey autopilots. They do not tell you what your attitude is, they tell you if you how fast you are spinning. And they drift. A few degrees per second is not really "bad." You need other ways to provide a vertical vector (accelerometers and some careful math) to correct roll and pitch drift, and a horizontal vector (magnetic compass or GPS heading) to correct yaw drift.

Also, you can not simply integrate the rates from the gyros independently. Make an airplane out of your hand and do the following comparison. From straight and level, pitch up 3 degrees per second for 30 seconds. Next, roll right 3 degrees per second for 30 seconds. Look at your hand. Should be fingers up, palm to the left. Got it? OK, try doing the rotations in the opposite order: From straight and level, roll right 3 degrees per second for 30 seconds. Now pitch up 3 degrees per second for 30 seconds. Is your hand in the same orientation? Fingers to the right, palm forward? Hmmm...how ya gonna fix that?

If the software crashes: If you're keeping a normal remote control it's wired to control 2-3 servos for the controls. The autopilot would have its own alternative wiring too.  You could select between the two with a (lightweight) relay so if the autopilot's power goes down the relay clicks off and the remote is connected back to the servos as normal.  This would be the manual switchover too, controlled by one channel on your remote.

(I know nothing about R/C radio gear by the way, I'm assuming you'll be able to control an on/off from a standard controller.)

By the way it might be simpler to leave the throttle connected to the radio at first.  The autopilot would just twiddle the ailerons/rudder/whatever to assist keeping straight and level.  Much less to do than build in all the navigation & take off/landing in one go.  (Still tricky though.)

Cookie Monster said: 

One thing you need to be aware of, those small, lightweight "gyros" are rate gyros, not position gyros such as used in old-timey autopilots. They do not tell you what your attitude is, they tell you if you how fast you are spinning. And they drift. A few degrees per second is not really "bad." You need other ways to provide a vertical vector (accelerometers and some careful math) to correct roll and pitch drift, and a horizontal vector (magnetic compass or GPS heading) to correct yaw drift.

I don't think that you can do attitude with accellerometers, at least not properly as if back pressure remains the same then a 1G manouver will be continued, look up stopped engine aerobatics on youtube and you'll see from the iced tea experiment why accelerometers might not like it. (although I'm willing to be proved wrong.)

A good Direction indicator should only drift 15 degrees per hour as the earth spins arount it.

Also, you can not simply integrate the rates from the gyros independently. Make an airplane out of your hand and do the following comparison. From straight and level, pitch up 3 degrees per second for 30 seconds. Next, roll right 3 degrees per second for 30 seconds. Look at your hand. Should be fingers up, palm to the left. Got it? OK, try doing the rotations in the opposite order: From straight and level, roll right 3 degrees per second for 30 seconds. Now pitch up 3 degrees per second for 30 seconds. Is your hand in the same orientation? Fingers to the right, palm forward? Hmmm...how ya gonna fix that?

As far as I can tell the beauty of controlling a fixed wing aircraft is that you can decouple the controls very effectively for "normal" flight, for aerobatic flight its a whole different ballgame but that is by the by although a simple code to go wings level would be a good one. Banking 90degrees or going into the vertical is not something that is done in general outside of being in the military or an aerobatic pilot or indeed a playstation pilot.

To turn you would simply have to bank to and stay at 30 degrees using one system whilst using the other system to maintain level flight, the harder you bank the tighter you turn with the limit probably being set by Max lift coeficient of the wings. If you were lfying a real plane you'd need to use the rudder to coordinate it properly but seeing as there is no passengers to make sick then it doesn't matter too much.

If it were me (and it could well be soon) I'd stat by using one of those polystyrene aircraft that only have control by 2 props and control steering and climbing through them. (more thrust=go higher, thrust differential = turn)

Fred

The more I think about it (I should be working) the more I believe that maintaining level flight is the most important and unfortunately the most difficult thing here. The difficulty is knowing how high it is at any given time, you are probably looking to have altitude data accurate to within 1ft to maintain within 5ft. Thats about 3.4Pa, if there is a pressure sensor that can do this ok then no worries.

Edit:BMP085 may be up to the job with a bit of damping from a rubber tube.

Fred

HappyPaul55 said:

kghunt said:

Why use wifi at all? Why not 3G/GPRS and a basic external webservice that hosts a heartbeat data file. The the plane will heartbeat every few seconds and pick up commands from the web service. Then you could have controls on a mobile device that post to the same web service to update the heartbeat file.

And similarly the plane could post
Sensor data to the web service. You could write in logic to say power down if 3 heartbeats failed etc.

Hello,

I've decided not to use GPRS because I don't really have a clue about how to go about creating a lightweight "phone". I could use an old android phone but I'm already sticking my neck into the unknown and I don't want to push it out too far. If someone has extensive knowledge in this area then maybe I'll start to think about it. Also, I'm running out of inputs even if I wanted to. But, I'll keep an open mind if some has the required knowledge.

Thanks everyone

Paul

I have an old 3g dongle that is no bigger than a usb stick. With the plastics removed it is tiny. It even has a built in micro sd card reader. I already wrote a script to dial 3g connections on the command line some time ago using wvdial its very easy. Then that provides the RPi with an internet connection. Im definitely going to get this working again as it will be useful for other projects too.

flipdewaf said:

I don't think that you can do attitude with accellerometers, at least not properly as if back pressure remains the same then a 1G manouver will be continued, look up stopped engine aerobatics on youtube and you'll see from the iced tea experiment why accelerometers might not like it. (although I'm willing to be proved wrong.)

You are wrong. Yes, I understand what you are trying to say. I am a licensed pilot and when I was working on my instrument rating my instructor would set a full soda on the floor between us, not touch it until we landed. If I slopped a drop I failed. The wings always lift "up" thru the cabin floor. Even banked 45 degrees.

However, even old vacuum instruments do drift and your HSI always self adjusts to what it thinks "up" is. If you perform an extended duration climb, the HSI will be a few degrees pitched down when you finally end your climb and drop the nose to the true horizon because it was adjusting itself to the new, nose up "level". In most cases, the rate of correction is an order of magnitude greater than the drift and yet not so great that any flight regime causes correction errors to accumulate beyond just a very few degrees.

Now, for the autopilot, (1) the mathematics take this into account and (2) you don't fly in a right bank along a straight line. When you roll right, there is a tiny error building in the assumed "up" but after a minute you are not going north banked right, you are going south banked right so the correction is being applied top "north" instead of top "south" and thus while you circle there is a small error but it cancels itself rather than accumulate.

Go to DIYDrones.com as I said before. This is exactly how they do this. 3x gyros, 3x accelerometers, and either GPS heading to cancel yaw drift (works OK for moving things like airplanes) or a magnetometer compass for 'copters which don't always have a forward velocity.