My control board project

[Dan_Jones]

I have enjoyed watching the projects that the rest of you have made and thought I would share my own. It is a small UAV control board that has 6 DOF acceleration and gyroscopic sensors. I originally had a compas and altimeter on it, but those were to expensive because the data can be obtained in other ways.

The heart of it is a ATmega32 that uses GPS input for waypoint control. The last picture shows the first attempt but it was bulky and a bird nest of wires, so I etched the board and made a smaller version. I hope to install it on my GWS slow stick soon. The things that make this extra special are the code segments that control an OSD (on screen display) chip, and the ability to log data to a MMC card. Both are external and the connector pins can be seen on the board. The reason the OSD chip is external is because it needs to be shielded from the GPS. The GPS doesn't fix as well when the OSD is powered. Obviously this is way bigger than the final version because of the use of breakout boards, but it still isn't that heavy and may be suited quite well for testing and on-the-fly improvements. I also show the acoustic range finder installed. I was thinking of having it detect when the ground is near to shut the motor off for landing. Altitude information will be collected primarily from the GPS.

I want to also highlight the connection to the reciever. This minimizes the number of wires needed. It is made possible by the Sombra Labs Lepton reciever which has programmable pins, full range, DSP on or off, and retails for about $30 + xtal. The power is provided by Dimension Engineering BECs and the breakout boards are from Spark Fun. My intent is to manufacture this board as soon as possible, but the day job gets in the way. :)

[Wulffy]

Dude, I simply love V1. It is the epitome of a prototype - kudos!!!

Also, as a friendly suggestion, maybe you can put each of the ultrasonic transducers on pigtails, so that you can experiment with the longitudinal spacing on the bottom of the airframe. Back in the late '90s we experimented with an ultrasound altimeter on slower (real) airframes - a C-172 on floats and also an AS-350 A-star. In either case, we got marginal performance.

The power handling of the transducers limited how high they worked, and with the height limitation, the lateral spacing had to be close enough to allow the echo to hit the aft xdcr. We never found a good combination that worked well with a real aircraft's flight envelope. I haven't yet experimented with RC versions, yet...

[NorthwestWolf]

I looked at your choice of microcontroller, your v1 test platform and your selection of goodies from Sparkfun and boy is it similar to what I have in the works and planned for my autonomous vehicle project.

I too had planned to test my system on a SlowStick once it had passed all the checks on the rolling chassis...but my focus has shifted to AUV/ROV for several reasons, so obviously I'll be skipping the SlowStick as a test platform.

Please do keep us updated as you move along with your development efforts. It seems that you'd cleared quite a few hurdles already and put in a few nice extras to boot at this point. :cool:

[docphi]

Sweeeeet! I'll be first in line to buy one! :D

What are you using for shielding?

[Dan_Jones]

Wulffy,
That is interesting about the ultrasonic transducers. I am using a pre-packaged SRF08. It seems to work okay, but I haven't tried it in flight. I expect the GPS to get within 10 meters for altitude as well, so when landing I really only need some sensor to say that the ground is close. Spark fun has a single transducer that may work better as you suggested.

NorthwestWolf,
What is your platform now that you aren't looking at airframes? I have had one person interested in having something like this for a submarine. It would basically need to run a script, resurfacing to get GPS coordinates and then using inertial navigation between the fixes. This would need different pressure sensors and for me to stay away from electroltic caps since the electronics are usually immersed in an oil bath to deal with the pressure.

docphi,
As far as shielding goes, I am up for suggestions. I bought some small aluminum project boxes but I haven't crammed any electronics in them yet. I was hoping that tin foil would provide enough. There are also conductive sprays for the inside of plastic boxes, but I haven't seen them used yet.

[Wulffy]

Wulffy,
That is interesting about the ultrasonic transducers. I am using a pre-packaged SRF08. It seems to work okay, but I haven't tried it in flight. I expect the GPS to get within 10 meters for altitude as well, so when landing I really only need some sensor to say that the ground is close. Spark fun has a single transducer that may work better as you suggested...I may have not clearly communicated my 'suggestion': I suspect that you will not have the operational success that you are looking for if you go with a single xdcr. I'd be willing to put money on the fact that you will need two xdcrs to get the system to work with any forward momentum. What I was trying to elude to is that you may find that the stock spacing of the transducers on the SRF08 may only work for a speed range that goes from 0 to X m/s (the value of X is TBD based upon your results from testing). Where as, in the aircraft, you may need it to work from Y m/s to Z m/s.

The value of Y and Z will be a function of the Xdcr Longitudinal Spacing, the Pulse Width, and the Pulse Carrier Frequency.

The height that the system will become operational, I think, will be a function of Power, Pulse Carrier Frequency, Surface Medium (Reflection Quality will be greatly affected by various characterists of the surface affecting the absorbtion & scattering of the Ultrasonic Pings).

One of the things that the system OEM (Ocean Motions) did during the development phase was to set the rig up to ping out the side of a truck, and drove up and down the side of a long warehouse to set up the Pulse Power, Pulse Width, Pulse Reception Frequency, Pulse Carrier Frequency, and Xdcr spacing.

Seeing as you have a rolling rig, maybe you could do something similar to see if you get the performance that you are wanting, starting out say 50' away from the building and approach it at a shallow angle, at speed, to see what the operational envelope is regarding the range/speed envelope with various spacing between the fore and aft xdcrs - ovbiously going with the stock spacing as it exists on the unit that you have on-hand, having the steering servo be the 'throttle' or 'elevator' control - depending on the method of vertical control during the descent/approach/landing phase of the flight.

I believe that there are a number of threads here at RCGroups that have used ultrasound (and laser) as a 'RadAlt' with varying degrees of success. I understand that the reflection medium can really have a real impact on the performance as well - i.e. water vs. grass vs. gravel vs. lakebed vs. paved, etc.

Also, applying frequency agility principles to the Pulse Carrier Freq, will aid in helping to reduce false readings from 2nd- or 3-time-around returns. However, I suspect that this may not be a problem seeing as ultimately you will be moving forward, so the likelyhood that you will see these erroneous returns is greatly diminished, I believe...

Good luck. I'll be keeping an eye on this thread. Keep up the good work.

-t

[docphi]

Wulffy,
docphi,
As far as shielding goes, I am up for suggestions. I bought some small aluminum project boxes but I haven't crammed any electronics in them yet. I was hoping that tin foil would provide enough. There are also conductive sprays for the inside of plastic boxes, but I haven't seen them used yet.


Dan,

I've got the same problem with my system. I'm using an EM-406 GPS and Bob-4 OSD. I've got some T-network filters and ferrite beads coming. I'll let you know what works for me.

[Dan_Jones]

Thanks for the explaination Wulffy! I'll be more mindful of the shortcomings of the ultrasonic transducer. It may be something like the compass where the functionality is good, but the overall implementation requires a better environment than is available on 90% of the landings. :) I can see many trial and error sessions headed my way!

Docphi, please let me know how your ferrites work! I am not allowed to work on the OSD at night and especially durring Grey's Anatomy because the circuit messes up the TV on channel 7.. I can see this needing to be fully enclosed in a shielded box with coax wires from the camera to the transmitter.

Minor project update: I got GPS data to be logged directly to the MMC card (FAT32!!) The only downside is that I have just about hit the mega32 code space limit. I may need to look at a ATmega64.

[Wulffy]

Thanks for the explaination Wulffy! I'll be more mindful of the shortcomings of the ultrasonic transducer. It may be something like the compass where the functionality is good, but the overall implementation requires a better environment than is available on 90% of the landings. :) I can see many trial and error sessions headed my way!...Pro noblem. I definitely do not know it all, but I do possess some semblance of knowledge every once in a while :) .

Take a peek at this thread (http://www.rcgroups.com/forums/showthread.php?t=591019) - it has some relevant dialogue. As does this site (http://www.robot-electronics.co.uk/htm/sonar_faq.htm)... l8r.

-t

[Dan_Jones]

I have a small update on this project. I decided to upgrade from an ATmega32 to ATmega128 due to the new need for lots of receiver channel handling. The new code can input and output up to 9 channels! This is all done in the interrupts so there is no dependance on the main loop. I also fixed some GPS code that overwrote buffers and clobbered my data. The latest prototype will now save GPS coordinates directly to the SD card in a format that Google Earth is familiar with! I will also be using google earth to generate the waypoints (via a KML file) and when that is saved to the SD card, I can read it using the ATmega128. That is the plan anyway. It is windy and rainy in Chico today so it doesn't look good for getting a flight in today, but the circuit now lives on my GWS slow stick. The basswood shelf is plenty strong and not that heavy. The slow stick handles it very well. I will need to upgrade to another airplane once I start adding the control circuitry because the slow stick is so slow, it literally flies backwards in a breeze. That just happens to be a state that I choose not to account for in my control algorithm!

Dan

[Tom Harper]

Dan,

LOL - Does it try to compensate with a 180?

[Tom Harper]

Dan & Wulffy,

I've been considering an ultrasonic beacon for glide path and distance to touch down. The idea is to have a ground unit at the desired point of contact. The ground unit simultaneously transmits an ultrasonic pulse and an RF pulse on one of SparkFun's 300MHz el cheapo transmitters. It seems that with free air, line of sight and aligned antennas the range should be around 100 feet. The detected range would be the difference between the received time of the RF and audio pulses.

Altitude would still have to come from sonar or GPS but I think the touch down point reference would be useful. Using two units and an A/N range scheme you might even get alignment information.

Tom

[Dan_Jones]

Hi Tom,
Flying backwards is a problem, but I doubt it will happen. Flying in wind where the ground speed is less than the GPS accuracy is going to be the big problem. Looks like I'll be relying on my inertial sensors more than I thought.

Targeted landing has been the topic of at least one other thread here. I have thought about this quite a bit too. It seems the easiest approach is to have the ground target emit something (acoustic, light, or RF) and the plane to aim for it. Infra-red emiters are common thanks to night vision spy cameras and it would be cool to have an IR directed landing. The problem is with the sun and other IR sources. The sonic pulses are probably the most feasable.

I don't know if I'm completely sold on the idea of landing on a particular spot. Managing airspeed seems quite difficult that way. Instead, I think it would be accurate enough to use GPS to guide it in as slow as possible.

Two years ago I was able to autonomously land a GWS Formosa multiple times using the Analog Devices dual accelerometer. Just that one chip gave enough sensory information to keep the plane level. Granted, it would only work while gliding, it did safely bring the plane in and land it from 100 feet up. All I did was cut the throttle and enable the accelerometer. The landing wasn't the smoothest I've ever seen, but I have definatly had worse...

[Dan_Jones]

The weather finally cooperated and I was able to get 2 quick flights in! Attached are screenshots and the actual data files. Due to the upload constraints of RCG, I had to rename the google earth files to txt. Simply rename them to .kml and double click on them to open in Google Earth. I only noticed one area on the long flight that was a little shaky and the GPS data would be hard to navigate off of, but that was because of the breeze. The slowstick flew at about walking speed at that point. Most of the time it flew as fast as somebody can run or jog. I did notice that one of the coils in my $17 brushless motor melted the plastic in the motor, so no more flights tonight.

I did change the code so that it only starts logging data once it has a GPS fix and aquires the time from the GPS signal. It then saves the file as hhmmss.txt so multiple flights can be logged on the same outing.

[Dan_Jones]

Well, today was my first attempt at autonomous control! And it showed! The previous code I was using for waypoint sequencing seemed to work perfectly when in a car, so I strapped it into the frankenstick and took off. I tried to fly straight to allow the GPS to get a directional heading, and then enabled the autonomous feature. Every time I tried to do that, it went into a very weird and scary spiral towards the ground. I was able to regain control before each impending crash.

The autonomous feature was only on the rudder channel. When it was in auto mode, I still had full control of the throttle and elevator. I was using an integral type of control that would slowly move the rudder a small amount each frame, but the spiral was instantaneous after enabling it. So it must be a trim or frame timing problem. Syncronizing the trim between the autopilot and the receiver may be my next tast. The other thing that might also be nice is to start the auto servo position at the same place as the last reciever frame had it instead of the standard 1.5ms center position.

Overall I am humbled and I have more respect for those who have managed to fly autonomously already. But at the same time I would rather have it not work than to have it work perfectly and not know why!

[voidpointer]

Dan,

I am currently at the same point as you are trying to fly my Easy Star in autonomous mode. You may have a look at my project page at http://www.voidpointer.de/easybot/index_en.html and try the visualizing software which is not linked yet: http://www.voidpointer.de/easybot/flightviz.jnlp (Java Web Start, requires Java >= 1.4)

I am using a PID control for all 3 axes with different parameters. The rudder seems to need a big differential portion for control. In addition the elevator control amplifies the effect of the rudder so it is best to control engine and elevator by remote and let the computer control the rudder only. This way I am slowly approaching straight lines. The next problem is flying predefined curves using the same PID parameters...

I also use a Sonar device (SRF02) for ground ranging but my experience is no good. The sensor works in pre-launch and in low overflight (1 - 3 meters) but talks absolutely nonsense in higher elevation. I will try to fix that by software.

I hope to find out appropriate PID parameters for autonomous flight within the next weeks but I am not sure it will work with my setup (GPS only - no IMU). Keep on testing - I'd like to hear from you.

Regards, Achim.

[Dan_Jones]

Achim,
Your project sounds very similar! I read through your website and it sounds like you have an excellent start. I am a little surprised that the ultrasonic sesors return nonsense when the plane is at altitude. I will keep that in mind when I get to that point. I would say we are both at the same point though. I am currently trying to fix my rudder control. With the frankenstick, once it starts to turn, it has the tendency to immediatly bank and make very sharp turns. Even with slow rudder movements it will not turn, not turn, not turn, then immediatly turn. That type of behavior is just about impossible for my circuit to handle with just GPS. In order to try to deal with that I wrote code that validates the GPS coordinates. 3 full seconds of 'different' GPS coordinates and < 30 degrees of turn each second are needed to make sure the airplane is moving fast enough to give me workable data. So far that works, but the control is still botched. The one thing that I also need to fix is the timing of information. GPS signals arrive about once a second. The servo needs to be updated 50 times a second and the gyro chip could be read that fast. How fast should the control loop run? Usually only as fast as the input. However, I would like to use the gyro to turn the airplane just a certain amount per second, limited by the GPS direction.

Do you also suspect that the turning problems you are having may be caused by the absense of ailerons? I do. In fact I am in the process of making a new wing that has ailerons just so I can focus purely on the waypoint sequencing. Plus, beng a software guy, the problem is always in the hardware!

[Dan_Jones]

For those of you who are reading this thread and have any interest in UAVs, You must download the visualization software that Achim posted. It is very well done!! Simply run the software and go to File->Download to get a log file from one of his flights. This isn't the thread to be posting this little advertisement, but Achim was modest about the app and somebody needs to jump up and down and say "Everybody look at this!!"

Achim, Very well done. I hope that you are considering releasing or selling the specifications needed for the log file so others can use your software to visualize their flights.

[voidpointer]

Hi Dan,
thanks for promoting my software. I did not intend to hijack your thread. I will prepare a short user guide and a log specification on my website. I think I will release the source code too, so that everyone can adapt it to his needs.

My attempt is to have a GPS update rate as high as possible. The u-blox SAM-LS makes 4Hz and you can tune it for 5Hz risking a gap in the data flow once in a while. The GPS update rate governs the control loop of the whole system, so the sensors are read every 200ms and servo position is set with that rate as well. When the system is in part-autonomous mode you can even remote control the non-auto channels with 5Hz which works good. I'm telling this to say that it is possible to control a slow airplane with no more than 4 or 5 calculations per second - if only the calculations are the right ones ;-)

In your setup the 1Hz GPS rate is surely too slow for the control loop. If the processor is fast enough I would suggest you to set the refresh rate as high as possible. You might extrapolate the GPS data to have a position estimate. But strictly speaking you have to let the gyro and accelerator readings flow into the position and attitude estimation. That's the difficult job with an IMU I wanted to avoid.

You mentioned the "not turn, not turn, not turn, then immediatly turn". I experienced the same. It looks like nothing's happening when I watch the motion in the viz software. But I reckon that it takes the airplane half a second to tilt until it can perform the turn. This reaction time is hard to put into a control loop. But you have the opportunity to measure the bank angle and to stop the movement at the desired angle. Of course it is good to have the airplane trimmed and use the trimmed servo positions as neutral values in the software.

I don't think that ailerons would make the problem easier. The plane might roll faster and more accurate compared to using the rudder. But depending on the V-shape of the wings one must add more or less elevator to perform the turn. Or do you want to compensate the roll movement with the ailerons and leave the heading control to the rudder? I doubt this would work.

About the ultrasonic sensors: I had a discussion in a german robot forum where we got to the conclusion that the sound of wind as well as other noise makes the sensor do a bogus reading. This effect could be compensated by comparing successive readings. If the values are close to each other the measuring is valid. I will try this when my new SRF08 has arrived.

Achim.

[Dan_Jones]

Achim,
Have you noticed that the 5hz GPS signal is to fast for your airplane? In other words, do sequential GPS readings sometime return the same GPS location? And does the GPS direction calculation sometimes provide erroneous results?

Right now my airframe is physically slow, causing the GPS direction to get confused occasionally and I fear that if I speed up the GPS it could lead to more problems. However, my real need for the UAV is to be fast and the 5hz will be a welcome upgrade once I get an airframe that won't tear itself apart at 3 knots.

Dan

[toxicmouse]

Dan,
i think that you have agood point with the refresh rate of the GPS, but the real problem is perhaps using the raw GPS data for making decisions.

say your plane moves at 10m/s, the GPS update is 1Hz, the accuracy on the GPS is 5m. in an extreme situation it is possible that the plane thinks it has not moved. also the planes' calculated bearing from this would be highly inaccurate. here the limitations of the GPS would dictate the necessary GPS refresh rate (assuming you are not averaging the GPS readings).

essentially, for a slow plane- a fast GPS refresh rate is useless, or worse than useless because it can confuse the situation. what is important is a more accurate GPS and/or a faster plane.

[voidpointer]

In most cases sequential GPS readings return different locations, even at 5Hz. That is what you can see in the graph. On seldom occasions I noticed a certain jump or drift in the position data. But if the receiver "sees" at least 6 satellites and SBAS is enabled the values are reliable and distance between sequential locations correlate with the measured veloctiy. However my software ignores heading values from GPVTG if velocity is below a certain threshold, like 1km/h. But this will only happen on ground or in strong headwind.

With the u-blox you get a PC software for viewing log data and configure the GPS. There you can choose from several platform models like Pedestrian, Automotive or Airborne. This configuration may have an effect on the validity of sequential readings. When my plane performs an accidental loop I notice the altitude values don't follow as fast as the plane falls and climbs. This could be because of the configured platform model.

It is true that GPS has a horizontal accuracy of 5m. With SBAS you can enhance it to 2-3m. But the locations will never jump 5m between two readings. You can have a look at the diagrams in http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=24254&postdays=0&postorder=asc&start=23 where I recorded the altitude and Lat-Lon values over 45 minutes. This shows that if you return to the exact launch location after the flight you may get a GPS location that differs in 5m from the first reading but you can rely on GPS when airborne.

Achim.

[toxicmouse]

i am not sure about the u-blox and its software, because i write my own software for the GPS. GPGSA has HDOP and VDOP (Horizontal and Vertical Dilution Of Precision) which gives a good indication of the accuracy, and thus reliability, of the GPS readings.

Achim, what are you using for processing the GPS data?

[Dan_Jones]

Your post prompted me to google the HDOP and PDOP values as I haven't written any code to handle them yet. I think they are mainly there to give you an idea of the location integrity due to satellite placement. The GPS displayed coordinates would still bounce around if I stood still with the GPS. If the satellites were all lined up in the sky the signal would be inaccurate as opposed to satellites that are scattered randomly. In any case, I should flash a red LED or something if the PDOP value gets too high.

[voidpointer]

I use the u-blox software only for configuration of the GPS module, e.g. for setting up the update rate etc. My Gumstix autopilot is written in C and parses and converts NMEA sentences all by itself. It works similar to the gpsd software for Linux. It also reads the HDOP value but does not use it yet for validation.

Usually the more satellites the GPS sees the better the accuracy gets. That's why my autopilot won't start if the number of sats is lower than 6 (showing a yellow LED :-). But once airborne you cannot stop if you loose sight of satellites. The autopilot software would have to provide a fall-back routine for those exceptional situations.