Jordi has opened my eyes to the Arduino platform, which is being described as a "Basic Stamp killer". Is it a good candidate for autopilots? Well, let's look closer.
Arduino is an open source embedded processor platform, based on the ATMega168 CPU, which has more memory than the Stamp and is a lot cheaper. There's proper development software available and SparkFun has a full line of dev boards and other accessories. Its programming language looks like C but should be easy enough to learn for people who know Basic.
It started as an Italian project (it's named after an Italian king) and still has a European flavor, so that may explain why we in the US don't know it well. But Jordi, in Mexico, had done some very interesting work in exploring its potential as an autopilot platform.
His main project is the "Arducopter" (shown at right), which has resulted in some very nice code, such as this navigation routine.
In his comments, Jordi (BTW, he's just 21) described some of the cool things he's doing with it, which I'll simply quote with links here:
"This is my first test with Boarduino (a breadboardable version of Arduino) controlling servos and using an accelerometer from a Nintendo Wii. Right now I'm using Gyros and Kalman filters. I even wrote code to read PMM signals, the GPS is finished and working pretty well, the IMU is in beta, and I'm developing an altimeter using I2C technology and high quality pressure sensors."
Here are some links he provided:
I'm intrigued. I don't see anything here we can't do with Basic Stamps with a little fiddling, but I have to admit that certain projects look like they would be easier with the Arduino, mostly thanks to its greater memory and full range of variable types, including floating point. Anybody else looking seriously at Arduino?
If I am following this right, this is an autopilot for a helicopter? I am looking for something that will give a stable hands-free hover so I can do some aerial photography. I plan on the flight being done by rc, I just want that ability to hover for a minute or two. Is this system one I want to keep an eye on?
NO, i made the tests using the buddy port from the futaba remote control: http://users.belgacom.net/TX2TX/tx2tx/english/tx2txgb3.htm
The PIN2 is the PPM output (Same that the receiver)...You can even obtain power from there =), don't forgot the ground...
After that i can hack the receiver and im going to obtain the same values, with a bid of noise...
So are you reading the PPM signal off the Rx now? This is what Paparazzi does. They also dedicate a chip with more power than an Arduino just to do PPM decode and PWM output.
I saw some code you posted that had a function to get the ticks from Timer0 so you could calculate the uSec width of the Servo PWM signal.
I'm not sure yet but i think that timer might be a source of error. Its ticking too slowly (I think its using the /64 prescaler). It depends on the timing but you could get 8 uSec fluctuations between frames.
Most current R/C gear supports 1024 steps. Thats about 2 uSec accuracy.
Some other things about that code don't add up to me. Specifically I don't think there are 256 ticks per millisecond on the Arduino. I think I found the post where you got the function from. I'll try and post something in the forum tonight.
About the "accuracy and latency" you need to read several PPN's frames an then average it, and make a code that is able to recognize bad frames and discard it. When i was making some test's i figured out that the receiver sends 1 frame about every 50 to 100 microseconds, and you need to refresh data in servos every 20 miliseconds, so you have a lot of ppm's frames to average before pulse any servo. =)
I ordered a Wiring board and an SD card holder to do some testing.
After thinking it over I would guess that the R/C receiver manufacturers care more about accuracy and latency than execution speed. After all, they only have to drive servos so it would be a waste not to use the whole CPU to do the job.
They probably send one servo pulse at a time so they can get the pulse length perfectly accurate.
I haven't seen any boards that can offload the reading of PWM so first I will focus on writing a PWM read driver for 6 to 8 channels. That should be enough for any Micro UAV.
If that is all the CPU we want to dedicate to control there is always the Pololu servo board to offload the servo driving. So its a problem that we don't have to solve.
First up will be a program to characterize the output of the Rx so we can learn more about them. I expect there will be differences by brand and maybe even model.
Code will be available for others to test with as well.
Cool! i have been looking at this all day and I figured out the Parallel Pulse thing just a little while ago.
Basically you set all servo pins to HIGH and then turn them off at he right time. It should only take 2ms to run as many servos as you like. Over a second thats 100ms or 10% of the execution time. If you use an interrupt and return between the setting HIGH and 1ms later when you need to start turning pins off it will only use 5% of the CPU time.
If your building an RC receiver you probably know this trick already. Maybe thats how they work??? We need to find out. If thats the case then we can optimize the reading of PWM data too.
We set an external interrupt to one of the Rx input pins. Once it goes HIGH we loop over all the pins with a digitalRead and record the times when they go to LOW.
If that really is the case then we could do 6 channels in & out for about 10-15% of the CPU time. Not bad. It probably isn't that simple but its worth writing some test code to find out.
I'm not keen to hack the Rx to get PPM signals. I fly Spektrum anyway so it wont work with my gear anyway. Did you know they use a real micro controller on their Rx? Reading PWM signals from the Rx gives the best chance of it working with all R/C gear.
Comments
http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A23188
Mixed with super accuracy GPS and altimeter...
http://users.belgacom.net/TX2TX/tx2tx/english/tx2txgb3.htm
The PIN2 is the PPM output (Same that the receiver)...You can even obtain power from there =), don't forgot the ground...
After that i can hack the receiver and im going to obtain the same values, with a bid of noise...
I saw some code you posted that had a function to get the ticks from Timer0 so you could calculate the uSec width of the Servo PWM signal.
I'm not sure yet but i think that timer might be a source of error. Its ticking too slowly (I think its using the /64 prescaler). It depends on the timing but you could get 8 uSec fluctuations between frames.
Most current R/C gear supports 1024 steps. Thats about 2 uSec accuracy.
Some other things about that code don't add up to me. Specifically I don't think there are 256 ticks per millisecond on the Arduino. I think I found the post where you got the function from. I'll try and post something in the forum tonight.
Good Luck..
http://blog.makezine.com/archive/2008/01/intro_to_the_arrrrduino_b....
After thinking it over I would guess that the R/C receiver manufacturers care more about accuracy and latency than execution speed. After all, they only have to drive servos so it would be a waste not to use the whole CPU to do the job.
They probably send one servo pulse at a time so they can get the pulse length perfectly accurate.
I haven't seen any boards that can offload the reading of PWM so first I will focus on writing a PWM read driver for 6 to 8 channels. That should be enough for any Micro UAV.
If that is all the CPU we want to dedicate to control there is always the Pololu servo board to offload the servo driving. So its a problem that we don't have to solve.
First up will be a program to characterize the output of the Rx so we can learn more about them. I expect there will be differences by brand and maybe even model.
Code will be available for others to test with as well.
No problem, if you do something related with this, please share it here =).
Thank you!
Basically you set all servo pins to HIGH and then turn them off at he right time. It should only take 2ms to run as many servos as you like. Over a second thats 100ms or 10% of the execution time. If you use an interrupt and return between the setting HIGH and 1ms later when you need to start turning pins off it will only use 5% of the CPU time.
If your building an RC receiver you probably know this trick already. Maybe thats how they work??? We need to find out. If thats the case then we can optimize the reading of PWM data too.
We set an external interrupt to one of the Rx input pins. Once it goes HIGH we loop over all the pins with a digitalRead and record the times when they go to LOW.
If that really is the case then we could do 6 channels in & out for about 10-15% of the CPU time. Not bad. It probably isn't that simple but its worth writing some test code to find out.
I'm not keen to hack the Rx to get PPM signals. I fly Spektrum anyway so it wont work with my gear anyway. Did you know they use a real micro controller on their Rx? Reading PWM signals from the Rx gives the best chance of it working with all R/C gear.
Thanks for the help. Good luck with your project!
-
1
-
2
-
3
of 3 Next