Auto-pilot project, please comment!

[gustabmo]

Hello,

With not much previous experience, some friends and I decided to embark on an auto-pilot project.

The main objective right now is to be able to fly r/c to infinity and beyond, and when the radio signal fails, the auto-pilot takes control and brings the plane back home.

So the idea is:

- just one sensor: a GPS (no airspeed, gyro, barometric altimeter or anything like that)

- when you turn it on it acquires a GPS signal and sets the (only) target waypoint to where you are right now + 50m of altitude

- auto-pilot receives 4 input channels from the rx: on/off, rudder, elevator, throttle

- on/off channel when on a constant high state turns the auto-pilot off so that it just lets the rudder, elevator and throttle signals from the rx go straight to the servos+ESC; it should be such that when the rx looses signal this means turning the auto-pilot on, the same could be done by moving a switch on the tx

- rudder: could be programmed with only 3 positions: neutral, left and right; slight variations of for instance neutral making a wide turn, would make the plane fly to the target waypoint in a zig-zag route, but would work nonetheless

- elevator: the auto-pilot would just let it in a fixed trimmed position; the plane would be pitch stable (=forward CG) and this trim position would give level flight with 50% throttle, for instance... slight variations from this won't be a problem; in order to try to actively control the elevator would require an air-speed indicator so not to stall the plane, wouldn't it?

- throttle: would be used to maintain altitude; that stable elevator trim position (see prev paragraph) would allow the auto-pilot to increase throttle in order to go up, and decrease in order to descend... simple as that; altitude would be controlled by GPS altitude, not very precise but we don't plan to fly low... there will always be a quite large altitude margin from the ground

- roll control would be given by a generous dihedral angle (EDA)

Comments?

Will the low update rate of the GPS be a problem? We're eying a 32 channels 5Hz GPS (http://www.sparkfun.com/commerce/product_info.php?products_id=8266).

Are we overlooking any basic problem?

Tks a lot,
Gustavo

[Gary Warner]

I'm not actively involved in UAV flight, but I am involved in flight stability control systems using embedded processors. I'll share a thought or two.

Everything sounds good in theory, yet I think the UAV guys will have things to add. My thoughts are with the flight transition from in-range to out-of-range. RC systems don't just die and fall off the face off the earth when the signal gets weak. They tend to receive interference that worsens until all control is eventually lost. Seems to me that a 'glitch detector' could be used to set out-of-range detection and activate the autopilot. Also another option is to turn the transmitter off while control is still 'ok'. Something else, which you may have already figured out, once the system (auto pilot) is 'on' it must be in a latched condition since turning back to the waypoint will soon re-establish a good signal. Think about how and when you'll return control back to the ground pilot and when, where and how.

The rest of the system seems sound, though I wonder if you're going to incorporate a rate of turn from the GPS? It's easy data to get, but if you just use a fixed amount of rudder to start the turn, holding this until the desired heading is found, the plane will likely be at an unusual attitude by the time a 180 turn is completed. Without an attitude gyro or roll rate input you'll need to monitor the heading data from the GPS and tend to turn in more of squared off sections of a turn. Sounds crude, but this is an effective way to turn using only GPS data.

The altitude control by GPS and engine control is sound theory. Usually the biggest challenges in doing so is avoiding oscillations that are too aggressive or not effective enough. Chanced are, with simple code logic, you can get an embedded controller to handle this job within reason. Do you all have WAAS in your area? If you do it will help a lot with the altitude accuracy. Either way, I suspect this will be the hardest part of the control system feedback loop. The heading corrections seem to be a very fast loop compared to altitude using throttle only. An elevator input is the opposite - it's much faster.

You should well be able to get away with a 1Hz GPS system if you want. The system control loops (heading and altitude) will end up being long enough for you to process GPS data at 1Hz for a simple project like this. Also, that GPS receiver you mentioned defaults to 38400bps com rate and the configuration is not kept when the power is turned off. Are you willing to code the controller to send a setup everytime it comes on if you want different settings than the deault?

As I said alluded to before, control loop response curves will be the biggest challenge after the basic coding the controller.

Good luck and keep us up to date on the project!

Gary
--

[alexcmag]

Gary,

I am helping Gustavo with this project.

I already have an old smart decoder project to filter the interference from "good signal" and activate auto-pilot if there is not a set of usefull signal each second. I tested it with GWS R4P far over the range (300m+) and on heavy interference conditions and had full control all the time, except that response time increases as interferences begins to invalidate most PPM packets.

When using a downlink the error rate can be send to the pilot using the audio channel so the pilot will know he's almost out of range before it happens.

I liked your idea of starting the turn with some rudder throw and adjust it to set a rate of turn. It seens to be far better then using a fixed rudder throw, so I will follow your advice.

Some GPS modules (SIRF based modules) have the option to use SIRF protocol, wich already have rate of turn and rate of climb data. The 1Hz module I tried has it. NMEA data does not, but at 5Hz it is not difficult to calculate.

We don't have WAAS here, but the 5hz module has 32 channels and its specification is for 3m precision.

The 1Hz module I tried has 10m horizontal precision and 30m vertical precision, but at short periods the information is not so bad. I tested speed, heading and altitude information and they are not "random" at short periods. The precision is not so good, but if I move it 3m east and 3m up the latitude/longitude/altitude information changes according to it. Of course if I get a trip get back to the same place coordinates will be within the 10m/30m range.

Of course will try a lot withing radio range (less then 500m with full receiver) and at sufficient altitude to switch back to manual control if the autopilot does something wrong.

[Gary Warner]

Sounds like you all have been thinking this through very well.

I was reading the datasheet on the GPS and seems there is 'either' a 4800 baud data rate or 38400 baud rate as the default. I can't find where the distinction lies. I can assume that in the 1Hz rate, it defaults to the 4800 and in the 5Hz rate it's at 38400 baud, but I didn't see that per say.

Your project sounds like fun and it might be what I need to get me interested in doing one like this too. Since I have a lot of experience in sensor/controller attitude control, I'll probably be using a system that only uses the GPS for map-of-the-earth navigation and sensors for attitude control.

So you said you've done something like this before? What was the task and how did it work out? What worked well and what (if anything) failed to work well?

Oh, and about the rudder control for a turn...

Modulating the rudder to a varying degree of deflection works well, but to keep things simple I was saying that a fixed amount (all be it small) could be used, but to just set target headings that are, say, about 5 or ten degrees ahead of the current heading. As the new target heading is found, centering the rudder and allowing for a bit of time (1 or 2 seconds) and then repeating the sequence of short heading changes until the final heading is found, will allow for a simple one deflection setting of the rudder right and left and of course center. Again, it's crude, but in a stable ploy airframe it's effective. Oh, and once the final heading is found, abridge the reactions to short fixed time deflections of the rudder, allowing for only minor heading changes.

[alexcmag]

Gary,

Somethings are made before, but not on an UAV.

After a few crashes due to glitchs at low altitude in the past I made the smart decoder around three years ago to avoid interference on the places I've flying.

The GPS module was used in a friend's student robot project this year. It was a small robot that must navigate through a grass field, so it was not possible to navigate with stepper motors to make precise turns like many simpler indoor robot do.

Good electronic compass were too expensive for the project and simpler are not precise enough, so the solution was start from a known position, keeping the robot moving and use coordinates, heading and speed to control motors on a route to cover all the grass. The GPS module specification was 10m horizontal precision, obviously not enough to a good navigation on a 50x50m field, so we tested a lot to know how precise it was to follow a course and on our tests it was enough to cover all grass field without problems.

Of course if follow the same coordinates one hour later the GPS error will make it to do the same pattern, but at a different location.

On the robot we also used DIY ultrasonic range sensors with a MCU, car alarm transducer, MAX232 as driver to activate the transmitter with 16Vpp or more instead of 5Vpp from MCU, amp-op and comparator to read the echo and a port on the MCU to read echo back and calculate distance. It was enough to get good measures from small objects from 3cm to 3m, so I am planning to use it for an automatic landing system in the future.

After the robot I started to think more seriously about making an autopilot and was researching pressure sensors for altimeter and pitot-static air speed, 3-axis magnetometers from Honeywell to sense attitude, infrared sensors for reading horizon and detect possible obstacles like montains on front, and so on.

When Gustavo asked about this simpler approach we decided to try it first, at least to learn and have an extra security feature on airplanes, and now we're trying to check other ideas to improve the project and avoid basic errors on first tries, since embedded code are harder to debug at flying field.

I'm also coding a simple simulator with basic physics to test the algorithms, at least enough to do the control/response loops to work well enough on first test.

So, any suggestion is welcome. Yours are noted and will be used.

[Gary Warner]

One additional thought. If you are looking for cheap altitude sensing, try and find this (http://www.electronicproducts.com/ShowPage.asp?FileName=hlrc05.jun2005.html) sensor. At large quantities it's available for about 1 dollar US, probably has a one piece street price of $2-4, but I can't find them in one quantities. Maybe they offer samples. It's not temp compensated but it should offer good 'altitude hold' information.

BTW, let me know if you find them (or anyone else). I'd be very interested in getting a few.

[alexcmag]

Nice sensor, for altitude hold it seens to be pretty good really, and the manufacturer has a range of different sensors, including differential, temp compensated, ...

I did a search on distributors on my country and can't find any...

I'm planning to use MPXM2102 sensor from FreeScale: http://www.freescale.com/files/sensors/doc/data_sheet/MPXM2102.pdf

It is not as cheap, but is temp compensated.

FreeScale has the MPXA6115 sensor too, it is temp compensated and the output at full scale is 4.5V, making it better to use with MCU ADCs: http://www.freescale.com/files/sensors/doc/data_sheet/MPXA6115A.pdf

This last one costs R$54 in my country (US$26), £11.84 at UK for export, but can save from using an instrument grade amplifier.

[Gary Warner]

Oh, I miss understood your earlier post. I though you were going to use the GPS altitude data for engine/altitude correction. My bad.

Yes, the Freescale sensors seem to be the standard, for the cost. They are accurate enough to produce 'real' pressure altitude data. You can still back it up with the GPS for MSL altitude w/o fancy code math.

[alexcmag]

Oh, I miss understood your earlier post. I though you were going to use the GPS altitude data for engine/altitude correction. My bad.

Yes, the Freescale sensors seem to be the standard, for the cost. They are accurate enough to produce 'real' pressure altitude data. You can still back it up with the GPS for MSL altitude w/o fancy code math.

Not so misunderstood...

This first version will have only the "back to home" feature, that's why we will only use GPS altitude. It will be useful enough for Gustvo avoid loosing airplanes and for our friend Alexandre Cruz to make his First Person View flights safely.

BTW, Alexandre Cruz is looking for longer range radio, if you have some suggestions, we will appreciate a lot: http://www.rcgroups.com/forums/showthread.php?t=673321

We're planning to make this step by step, so we can get some results while adding more features.

Barometric altitude sensor, differential pressure air speed sensor and sonar range sensor (for landing) are on my plans, as does active flight stabilization.

Aerodynamic flight stabilization was choosen because most of our flight fields are near montains and simpler electronic stabilization systems like infrared or visible light (as Futaba and FMA does) will probably fail.

I hope 3-axis magnetometers become cheap soon :) Solid state accelerometers and gyros works for simpler applications, and I know there are some UAV projects using, but I don't thrust then for longer flights.

[Gary Warner]

I can't find the link, but I did find a 3 axis magnetometer chip that was touting quantity price of about $3. Again, I could not find them in small quantities, but maybe they will become available to us little guys soon.

Please keep us up to date in the landing system. I too have pondered the ultrasonic idea for the last 10 feet (or so) of the approach and landing. I've decided to put the idea behind me for now with bigger projects in front of me at this time. If you want to share any details about the Ultrasonic landing system I'd love to be involved.

[phubner]

Gustabmo and Alex,

I have the same goal for my project - a Return Home feature. I am using the the coincidentally named Propeller chip from Parallax for the design - it is very powerful and has been reletively easy to program (so far). I am using an external Garmin etrex GPS for now.

If you do choose this chip (which has 8 paralel processors for $20! Did I mention I like it?...lol) feel free to take my radio receiver code acquisition and servo control code from the user forums at www.parallax.com. http://forums.parallax.com/forums/default.aspx?f=25&m=179631&g=180854#m180854

I'm now working out the GPS NMEA capture and navigation. I'm using the $GPRMC string.

G/L!
Paul

On emore thing - Im not associated with parallax.

Paul

[docphi]

Paul,

Have you seen the new OSD from Hitt Consulting? It uses the Propeller chip and has a whole bunch of great features built-in. It natively supports GPS input.

http://hittconsulting.com/products/hcosd/

[alexcmag]

I can't find the link, but I did find a 3 axis magnetometer chip that was touting quantity price of about $3. Again, I could not find them in small quantities, but maybe they will become available to us little guys soon.

Please keep us up to date in the landing system. I too have pondered the ultrasonic idea for the last 10 feet (or so) of the approach and landing. I've decided to put the idea behind me for now with bigger projects in front of me at this time. If you want to share any details about the Ultrasonic landing system I'd love to be involved.

3-axis magnetometer for less then $10 is really a deal. Of course it will not "ready made" like the $400 units, but with some trigonometry to find direction and accelerometers to tilt-compensate and short-term correction and it may be quite useful.

This idea of ultrasonic range was born while testing on the robot. The excellent results (the echoes on scope were like radar targets) remembered me that ground proximity warning systems are radar altimeter, so a sonar altimeter probably works well at low altitudes.

I'm planning to set the last two way points as the final approach.

Of course the altimeter (barometric or a good GPS) will have a +-3m error, so last way point must be set somewhere near 1/3 of runway. If the altimeter is reading +3m error it will touch the runway at its beginning, and if the altimeter is reading -3m error it will touch the runway at 2/3.

When 3m over the ground the ultrasonic altimeter will start to get echo and will be able to cut the engine, flare and land, avoiding damage to landing gear or belly.

If there is no echo at the final way point, the firmware can abort the landing and go around for a new try, 3m below.

It is the theory, I will keep you up to date with the testing, but of course it will be the next step.

[phubner]

docphi,

I have seen it and I am using some of the same code for the output. Bean @Hitt is a great contributer and board developer. Me -- I'm a n00b. I've only been looking at it for a few weeks all told, but the community is great and I'm making nice progress too!

Paul

[phubner]

Alex,

Have you considered hacking a laser measure instead of sonic? you might get much greater accuracy.

I havent seen anyone do it yet, I'm just tossin git out there.

Paul

[alexcmag]

Gustabmo and Alex,

I have the same goal for my project - a Return Home feature. I am using the the coincidentally named Propeller chip from Parallax for the design - it is very powerful and has been reletively easy to program (so far). I am using an external Garmin etrex GPS for now.

If you do choose this chip (which has 8 paralel processors for $20! Did I mention I like it?...lol) feel free to take my radio receiver code acquisition and servo control code from the user forums at www.parallax.com. http://forums.parallax.com/forums/default.aspx?f=25&m=179631&g=180854#m180854

I'm now working out the GPS NMEA capture and navigation. I'm using the $GPRMC string.

G/L!
Paul

On emore thing - Im not associated with parallax.

Paul

It is good to know that Parallax is making more powerful devices.

First time I needed to use MCUs I was a long time without working with electronics and quoted BasicStamp, but the speed was not enough and the price did't help too, it was too expensive in my country.

I looked your code, it is really very easy to write programs to Propeller. I will check the OSD module also, this may be a good add-on four our friend to fly FPV.

I've made the NMEA decoding in C language for the 1Hz module, but later the GPS module was set to SIRF protocol, more easy to decode. NMEA is easy to understand and read, but a little hard to program since field lengths are variable, but probably Propeller has better support for it then MCU C.

[alexcmag]

Paul,

Have you seen the new OSD from Hitt Consulting? It uses the Propeller chip and has a whole bunch of great features built-in. It natively supports GPS input.

http://hittconsulting.com/products/hcosd/

I liked the modules, must be a good way to send data to the pilot, by just adding OSD before the downlink.

[alexcmag]

Alex,

Have you considered hacking a laser measure instead of sonic? you might get much greater accuracy.

I havent seen anyone do it yet, I'm just tossin git out there.

Paul

I checked laser devices too. Of course they are more precise in their range (since light speed does not change with pressure, temperature, etc. like sound speed) and the range is far better (some devices can measure up to several miles), but there are some problems too:

- It is not easy to work with laser, light is very quick, so the approach of measuring the reflection with a cheap MCU will not work. At 1m the light takes only 6.6ns to get back, it needs a very fast CPU to measure. Most modules can only measure distances over 5m or 10m;
- Good ready-made modules are more difficult to find and expensive;
- They need more power even on short range (they're usually built for longer range);
- Most modules are too heavy;
- I can't find the parts on a local store.

The ultrasonic module I built with my friend use a few common parts, is very light weight (less then 10g), power consumption is less then 30mA when operating and the range is enough to flare the landing of a small UAV.

Sound waves travels at around 340m/s, so the echo timing is around 58.8 microsecond for each centimeter. My cheap MCU can measure microseconds easily, so the error will be around 10% due to the speed change, but will be enough.

[awmeade]

why would you measure the the time to return of the laser to the UAV? surely you would use a height / displacement method with the laser pointing downwards at an angle, and a camera picking up the difference in dot position to give altitude?

not explained that well, but I'm thinking along the lines of how low altitude height control was mastered in WW2 with the Lancaster bomber when "Dam Busting" - a lamp on each wingtip shining into the centre of the aircraft's flightline. When the 2 dots merged - bang, you were at the required height.

For a UAV this would require a vision system of course and some code, both of which are beyond my capability! Just wanted to get that idea out there too.

Here's a link to a piccie : http://www.computing.dundee.ac.uk/staff/irmurray/pictures/spots-all.gif

[alexcmag]

why would you measure the the time to return of the laser to the UAV? surely you would use a height / displacement method with the laser pointing downwards at an angle, and a camera picking up the difference in dot position to give altitude?

not explained that well, but I'm thinking along the lines of how low altitude height control was mastered in WW2 with the Lancaster bomber when "Dam Busting" - a lamp on each wingtip shining into the centre of the aircraft's flightline. When the 2 dots merged - bang, you were at the required height.

For a UAV this would require a vision system of course and some code, both of which are beyond my capability! Just wanted to get that idea out there too.

Here's a link to a piccie : http://www.computing.dundee.ac.uk/staff/irmurray/pictures/spots-all.gif

This works, but there are some problems too.

A spread laser can have more power since it will not blind anyone, but a focused laser can't have more power than a common laser pointer.

A common laser pointer is easily visible at night or through scopes but is a little difficult to see at daylight with a camera. Imaging processing to locate the laser is not easy too, mostly using MCUs. Using a camera and imaging processing there is also another way to measure height without laser, radar or sonar. Using an accelerometer to measure angular speed changes and a camera it is possible to measure the image changes between two frames. Since we will know the ground speed from GPS the angular speed of ground is enough to calculate the altitude.

My friend suggested another interesting approach, to use a small infrared laser modulated at 38Khz (like remote controls) and a 38Khz optical sensor from remote control too, with a set of lens to make it only to see a small angle. They can be placed at a known distance and linked together on a servo so it can point both inner or outer until the receiver get the 38Khz modulation from laser. With the angle we can get the altitude too. It is more precise then my sonar but a little more complicated in mechanics (the electronics is simpler).

[skj]

One additional thought. If you are looking for cheap altitude sensing, try and find this (http://www.electronicproducts.com/ShowPage.asp?FileName=hlrc05.jun2005.html) sensor. At large quantities it's available for about 1 dollar US, probably has a one piece street price of $2-4, but I can't find them in one quantities. Maybe they offer samples. It's not temp compensated but it should offer good 'altitude hold' information.

BTW, let me know if you find them (or anyone else). I'd be very interested in getting a few.

SM5420 looks very similar to Lucas Novasensor NPP-301 which I use in my thermaling computer for RC-soaring.

RGDS
Staffan

[phubner]

Alex,

I'm was thinking about using a laser tape measure - one that works up to about 50' - only when my GPS's altimeter (barometric, not satellite calculated - I use an eTrex Vista) indicates I am in below that range. I really don't need this yet, but I am hoping to spur a few more creative thinkers on!

Paul

[alexcmag]

Alex,

I'm was thinking about using a laser tape measure - one that works up to about 50' - only when my GPS's altimeter (barometric, not satellite calculated - I use an eTrex Vista) indicates I am in below that range. I really don't need this yet, but I am hoping to spur a few more creative thinkers on!

Paul

50' is a good range. How are you planning to interface with laser tape measure? Does it have serial interface or something else?

[phubner]

I dont have a clear plan ye ton the interface. After I get my return home system running, I'll add this to the to-do list. There has to be a point to tap into the board (I'm looking at a straight Line laser Tape measure) to get at this data.

Paul

[zitron]

I've got one of these (http://www.sparkfun.com/commerce/product_info.php?products_id=639) these on my autonomous robot (non flying). It's got a 1 inch resolution for up to 255 inches (~6.5m).

You have a selection of interfaces, serial, PWM, or analogue. It works fairly well, although I can see a potential problem: it returns distance to the closest object in can detect in its beam, which is pretty wide for large objects (such as the earth :) ). So if you are flying over flat ground but there's a bush slightly to your left, it'll give you a false sense of being low. Also, the minimum range it can detect is about 18-20cm, anything less it'll still return 18cm. Other than that I think it'll work quite well, its cheap and light too.

-Z-

My robot (http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1173623665)

[alexcmag]

I've got one of these (http://www.sparkfun.com/commerce/product_info.php?products_id=639) these on my autonomous robot (non flying). It's got a 1 inch resolution for up to 255 inches (~6.5m).

You have a selection of interfaces, serial, PWM, or analogue. It works fairly well, although I can see a potential problem: it returns distance to the closest object in can detect in its beam, which is pretty wide for large objects (such as the earth :) ). So if you are flying over flat ground but there's a bush slightly to your left, it'll give you a false sense of being low. Also, the minimum range it can detect is about 18-20cm, anything less it'll still return 18cm. Other than that I think it'll work quite well, its cheap and light too.

-Z-

My robot (http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1173623665)

I don't believe the beam will be large enough to be a trouble, except if you're planning to land on a corridor.

Most ultrasonic transducers I seen have a beam with an angle of less then 30 degrees. That's one of the reasons most ultrasonic parking sensors installed on bumpers are usually in a number of four or more.

At 3m height it means you will measure a distance in a circle of around 1.6m diameter or so, but your runway must be larger then this one...