All Posts (14029)
Sort by
- It's a "development platform", not a fully-featured working autopilot. Although there is firmware available for it, it's designed to be a standard hardware package around which you can develop your own autopilot code.
- The firmware comes pre-loaded, and works pretty much as advertised. I tested it on the ground, so it was hard to tell how well it actually stabilizes a plane, but the elevator seemed to respond properly to tilting. The rudder didn't, but that was probably because it was trying to turn the "plane" to a destination and I wasn't playing along ;-)
- That firmware is written in assembly, so good luck to you! It seems to do pretty much the basics of what you'd want an autopilot to do (and I mean basics--there's no provision for waypoints, and it's just a "fly home" autopilot at the moment), but if you want to tweak it you'll have to do learn PIC assembly (not super hard, but still: what's wrong with C?!)
- It includes a 4-degree-of-freedom IMU: two gyros and one two-axis accelerometer.
- As the two-axis configuration suggests, it's designed to control just two channels: elevator and rudder. A third channel is used to turn it on and off.
- It's got a good SiRF III GPS module on board, although you'll need to add your own antenna through the included SMA connector.
- At $299, it's not cheap. But when you consider that a simple set of accelerometers and gyros will set you back $109, the addition of GPS and a PIC processor, all nicely integrated on a board, is probably worth it. But it still seems about $100 overpriced to me.
- You need some additional hardware to work with it: the main thing is an ICD2 interface to program the onboard PIC chip and for debugging. That will set you back another $120.
- The documentation looks excellent, with a lot of theory on control and aerodynamics as well as a lot of help on PIC assembly language and development suggestions for the platform.
- Bottom line: this looks like a good, albeit expensive, way to learn about IMU-based autopilots. It's not really an autopilot itself yet, but could be made into a relatively low-featured one pretty easily. I think it's accurately described as a "development platform", so if you're in the market for that and can afford a $300 lesson, I can recommend it as a unique and well-made way to get started.
For the BS2p chip that we use, you need to insert the line "FTBaud CON 17405" and switch all the "Baud"s in the SEROUT commands to that chip to "FTBaud". I've updated both of the autopilot programs here that use the FT639 chip appropriately, so they should both work fine now. If you've been having trouble with the code, download the latest versions from that post, and see if this doesn't fix the problem.
Here's what's been tested so far:
1) Channel 5 turns the autopilot on and off
2) When in RC mode, the Basic Stamp passes through the rudder and elevator commands from the receiver to the servos. Jerkyness is minimal.
3) When in autonomous mode, GPS data is recorded, correctly parsed, and commands are send to the rudder and elevator servos.
Next to test: whether the waypoint navigation routines are working right.
The picture above shows the test setup with two servos, a RC receiver, and a GPS module. For GPS simulation, you just replace the GPS module with a USB-to-serial board, and then use GPS simulation software to generated the GPS data as described in this post. Here's what the setup above looks like with the USB-to-serial board replacing the GPS module:
This past week, I restarted the project, adding a mount for an SRV-1 Blackfin Camera board set, and writing the code to drive four servo channels - two channels for the E-flight electronic speed controllers, and two channels for the servos that gimbal the battery pack using a hobby helicopter swashplate. The servo interface is working quite well, and I have a slightly modified version of the java console used for the X3D which shifts the battery weight and controls the throttle. Horizontal translation is controlled by shifting the battery weight (as seen in the following videos), and yaw is controlled by trimming the difference in speed between the two prop motors.
In the first video, you can see how the weight shift mechanism works. However, I found that my battery pack was not producing sufficient output, so the flyer never got very far. In the second video, the battery had been replaced, but clearly some work is needed on steering. The crash at the end shortened one of the props by 0.5", but everything else was fine.
I think the basic structure is there, so the next step is to add accelerometers to aid in stabilizing attitude. I have both a 2-axis Analog Devices ADXL202E and a 3-axis LIS3LV, so I'll add one of the other. A gyro is clearly needed as well for yaw control, and I'm not yet certain which to use - I have a few with SPI interfaces that require 5V, or I might go with an analog output and use a voltage-to-frequency converter to capture the signal, since I don't have any A/D channels.
Me and my team have come a long way since I first posted on RC-Groups with interest of building a UAV.
I started pretty much from square zero, other than having some experience with Lego Mindstorms. I didn't know why my Stamp was being shorted when I did not use a resistor with an LED. I managed to short circuit my Parallax Servo Controller 2-3 times, ultimately resulting inthe battery springing a leak. I didn't know what a green dot meant on aschematic, and I almost fried my FPU chip. But in time, I learned frommy mistakes.
I have much to thank to this website, Parallaxforums, and RC-groups. I personally have learned ten times more from this project thanthree year's worth of science and technology classes, and to have themoney and freedom to design/research whatever you're interested in is agreat feeling for an aspiring engineer. It is really a great experience.
After months of research, we drafted a project proposal and emailed it to BAE Systems, a defense contractor company with ties to the Honolulu school system, and our principal, with requests for sponsorship.
BAE Systems responded to us in about 2 weeks, expressing interest in our proposal and offering us $363 to build our prototype (They offered $455, but I declined the additional money as I decided to withhold buying the airframe until I was confident this project could be done). Then shortly afterwards, our principal responded, requesting us to do a PowerPoint presentation to her, a few teachers, and two engineers.So we created a PowerPoint and crammed as much detail into it as possible (complete with GoogleEarth footage zooming in on a simulation flight path =P), which impressed the principal, who decided on the spot to fund us the remaining $200 we needed to buy the Easy Star and a radio transceiver system. As it turned out, one of the engineers (who will be our mentor) actually has a hobby doing the exact same thing we were doing (he uses the Easy Star as well)!
While all this was happening, we were also building a ground-based prototype to test our autopilot system. We used relatively low-tech materials (as you can see in the photograph) but it works fairly well and has a good turning response. My only concern is that it is too slow to get any sort of accurate bearing from the GPS's differential positioning (In that case though, we'll just use a digital compass to simulate a GPS bearing reading).
Anyway, after printing out Chris's Basic Stamp autopilot source code, GPS demo source code, pages and pages of floating point coprocessor instruction and data sheets, and PSC documentation, and then analyzing it, highlighting it, and annotating it, I've finally grown confident enough to code my own navigation program from scratch, although I pretty much used Chris's source code as an autopilot bible while I coded.
The current program works in a similiar way to Chris's navigation program, except it uses the floating point coprocessor, which allows a much more liberal use of variable storage, not to mention a relatively high precision without having to resort to clever tricks with integer-only math. The only difference is that since the turning system is a differential drive with continuous rotation servos, the turning angle is inserted into a function for the duration of turn, rather than the position of the rudder.
There are some logic and mathematical errors, especially with unit conversions, and when I work with bits, bytes, words, etc, since I don't really have any formal computer science training, so those concepts are foreign to me, but I think for the most part it looks okay. (It compiles!)
I am thinking of upgrading to the BS2P though, since currently I'm not sure how to implement waypoint lookups, other than just using constant arrays (do those even exist?!). The increased speed and scratchpad RAM will be nice.
So here is the program. For some reason, you can't directly view it on our website since it gives you a 404 error (it works offline), but you can still download it by going to the homepage and right-clicking --> save as, but you would need the Basic Stamp Editor to view it. (http://www.project-uav.net/index.html) I don't suggest you read our website other than the front page though, since it is mostly redundant information and mainly for academic purposes.
Otherwise, I've also uploaded the code to pastebin, so you can view it there too. Unfortunately without syntax highlighting it is a huge eyesore, but hopefully you can follow it.
http://www.pastebin.org/18059
P.S. I type as soon as a thought gets in my head, so in retrospect it kinda sounds like I'm rambling, so please excuse that.
So this was as good a time as any for me to upgrade the Basic Stamp autopilot for the EM406, so we can both use a better module and use GPS simulators (as described in this tutorial). If you want to use a GPS simulator with your Basic Stamp autopilot, you MUST make this change.
Here's the beta code of my port to the EM406. It was kind of a hassle, due to the different ways the two modules give GPS data, but the new version has a built-in GPS parser and is otherwise a lot more robust and can handle any GPS module you want to pair it with. It's also cleaned up a bit, so it's simpler and easier to follow. Tomorrow I'll test it with hardware in the loop and see how it does...
[UPDATE: I caught a lot of bugs in this code, including my stupidity in forgetting that if you place a value in two bytes of scratchpad memory with a PUT [location] Word [value] command, you've got to do the same when you GET: ie, "GET [location] Word [variable]". In the previous code I was PUTing with a Word modifier, but not including that modifier when I'd GET. Anyway, it's all fixed in the code linked in the paragraph above. Still need to do some tweaking to do the conversions properly to get around the limited variable space, but we're pretty close.]
http://code.google.com/p/binarymillenium/wiki/FlightGear
There's not much to it currently, it just demonstrates that I can receive vehicle state information through the native-fdm udp interface.
If you've been following the exploits of IceBear and a few others, you know that recently they've been beta testing a hot new autopilot that promises to be better and cheaper than anything else in the under $1,000 category. It's called the AttoPilot and I'm delighted that our third interview is Dean Goedde, its creator, who is here to tell us more.
Before we start, a little overview: To date, if you wanted to build an under-$1,000 UAV you only had two choices for the autopilot--make it yourself or pay $500-$800 for a UNAV PicoPilot (and the version of that with the features you want--the NAT--will push the total cost of the UAV to about $1,500).
I'm flying with PicoPilots and generally like them, but the relatively high cost and low feature set of that hardware (plus its total lack of customizability) is why Dean decided to make something cheaper and better. The picture above is him after one of his first successful test flights, which he says shows what he looks like "after 30+hours being awake hammering out new code, followed by generation of 6MB of log data from 20 minute flight!"
AttoPilot could revolutionize our hobby. Dean hasn't announced exact pricing yet, but he's targeting roughly half the price of the PicoPilot and the feature set matches those of autopilots costing thousands of dollars more. The early reports from the beta testers have been very positive.
This is still pre-release, so Dean doesn't have the website up yet (it will eventually be at attopilot.com) and there is still much be done on manufacturing, documentation and fulfillment. But I'm thrilled by what we've seen so far, and I'm hoping that AttoPilot will be powerful, customizeable and affordable--which is really what DIY Drones is all about. And, as you'll see at the end of this post, two years ago he started just like us, learning basic embedded programming with Parallax kits.
The interview will be in three parts:
- Part 1: All about Dean
- Part 2: All about AttoPilot
- Part 3: All about IR sensors versus gyros, and the challenges of autopilot design
Q: Can you tell us a little about yourself, day job, background, family, education, hobbies, etc?
I'm 36 years old, born in 1971 in the middle of the Apollo moon rocket days. At age 4 and 5, I would take construction paper, color it red with a crayon, chop it up (to increase surface area) and pack it in a tube with fins and a nosecone. I was suprised when it didn't "go", but can't remember if I tried to apply fire or not (I hope not!).
My mom's older brother is my godfather, and he is like a 2nd dad. He grew up in the 1940's building free flight planes, then did some of the earliest RC in the 50's and 60's (1 channel, "escapement" if you have ever heard of this it uses a rubber motor for torque that applies a bang-bang left/right/neutral choice) and a single pushbutton on the RC Tx. He was a maintenance guy in the US airforce in the early 1960's (heady times indeed) and is an electronics guru, that worked on missile silo maintenance.
In the 1970's he got into multi-channel Heathkit RC gear, and flies on that same equipment to this day. I have memory back to age 1 or so - so I clearly remember a warm summer afternoon in 1975 or so where I was playing in the front yard (rural area) and a 2m sailplane lands on the front yard but I was totally alone, then about 30 seconds later here comes my Uncle sitting on the open window jam of a car driven by his sister in law, coming down the dusty rock road at 50mph, he is hanging out of the car with Tx in hand. He had just flown the plane from his house about 2 miles away.
He was also the type of uncle that is very generous, bringing a plane to family get togethers, letting all of us kids flying it, being helpful, and showing us how to do stunts even. He is just such a super guy and a BIG reason I love this stuff, that I HAD to dedicate a paragraph to him. He is currently waiting for serial # 00001 of the production version of AttoPilot. I talk to him about 3 times a week.
I started building free-flight balsa planes of my own design at age 8. Age 9 I was fascinated with the Wright Brothers, reading a book about them in the 4th grade classroom literally 100 times in that year. This book was not dumbed down for kids, it described all of the background, trial and error, wind tunnel testing, extensive testing in the Carolinas over the sand dunes, about their homemade gasoline engine, etc.... I was enthralled. For 11th birthday my uncle and aunt bought me a 2m sailplane balsa kit from hobby-lobby called the Wanderer. It costs $14 as a kit back in 1982. My parents told me that if I finished it, they would buy the RC equipment.
I built it 100% myself, the covering job looked crappy, but it flew well. I added an 0.049 engine pod, then next year an astro 05 electric motor direct drive on a 7x4 prop. Electric fascinated me from the beginning. From age 12-15 I built many more RC planes, all of them self-designs. The first 5 or 6 just did not fly, but it just made me try harder. I then built a Goldberg Eaglet-50 (0.25 engine, full house control), and was even more hooked.
I studied music performance (trumpet) the first 3 years of undergraduate, but then switched to chemistry. After my bachelor chem degree, I got a PhD in chemistry at the University of Illinois at Urbana-Champaign. In 2001 I moved to Phoenix Arizona to work for Intel Corp (the chipmaker) at a high-volume fab as an engineer, and have worked for them until present.
At my day job, I do a lot of data mining, and looking for correlations between effects and their possible causes. I have 7 years experience sifting through literally terabytes of real-world data from $3 Billion chip making fabs. Looking at data is in my blood, as well as iterative methods of every sort. I am an Excel and SAS JMP guru, though up until recently had no programming experience.
Hobbies include flying RC, AutoCAD design of airplanes and laminate rifle stocks, gunsmithing and target shooting, aircraft construction, and now (the last 2 years) electronics and programming. I like to expose/develop/etch my own PCBs at home for rapid prototypes, and am able to do solder pasting of the smallest SMD components (0402, QFN, etc...).
I have almost no background in electronics or programming except self-taught starting in January 2006. I must recommend the Parallax company for EXCELLENT tutorials/kits/discussion forums to help utter beginners. That is where I was 24 months ago.
Q: You decided to go with an IR sensor (aka "thermopile", shown) rather than a gyro and accelerometer in an IMU for the first version. Can you explain how you came to that decision?
I have found that even without fancy code, the thermopile is a surprisingly robust solution; a LOT of bang for the buck. This keeps my AttoPilot in the spirit of "simplest low cost 3 axis autopilot.
My first flights were with very stable aircraft (the Miss2 old-timer). Even with this plane, over-steering was a problem at times. I realized some method of attitude sensing was a strict requirement for any serious autopilot.
I started out flying the FMA CoPilot [which is based on the IR sensor show above] only as the typical RC usage on a small unstable homemade plane with no dihedral and just aileron/elevator flight control. After experimentation, I realized that AttoPilot could skew the inputs to the CoPilot control box, and all of a sudden I had AttoPilot flying that same small unstable plane (at 70+km/h) even better than the raw AttoPilot used to fly the polyhedral winged Miss2.
Later, I reverse-engineered the CoPilot sensor head, and figured out how to interface to it directly to AttoPilot via 2 channel ADC (BTW, there is mis-information on the Paparazzi website regarding the FMA sensor head; it say CoPilot head is designed for 5V, but in fact it is actually a 3.3V device, so you don't need to replace resistors to make the gains correct), so now AttoPilot has direct use of the thermopile data, and therefore has direct idea of pitch and roll angle for a robust flight control solution that will never over or under-control.
I am integrating GPS and barometer data with the thermopile, so the solution is very robust, and self tuning. Additionally, although I have a working Kalman IMU, accelerometers have the limitation of being affected by motor vibration, whereas the thermopiles are immune to vibration.
So, in the end, to keep in spirit of a low-cost full function autopilot, I am starting out offering the thermopile version. As I wrote above, my use of thermopiles is more sophisticated than FMA's, so people should not be fearful about how well it will control their plane. I do have a working Kalman IMU, but just not ready to a level that fits my vision of a plug-and-play autopilot. Building all of the fancy control routines for my usage of CoPilot thermopiles is a nice stepping stone to a Kalman IMU later.
Q: What was the biggest challenge in designing AttoPilot?
Besides learning embedded programming over the last 12 months, besides coming up with the trigonometry routines that work anywhere on the globe, the biggest challenge in came from learnings with the Beta testers: making the Rx-interface code object TRULY universal to all R/C Rx out there. I had to crack down on myslef and learn assembly code, which I had avoided up until 2 months ago. Now that I know assembly, I am not only HOOKED on it, but re-writing other code objects.
Q: What advice do you have for others that are interested in building autopilots or related gear?
