Using Microcontroller in R/C VTOL
Darquewing
Posts: 5
Hello all. New to the forums here and wanted to say "Hi", before I get into the nitty-gritty.
Well, I thought a crazy idea for funsies, maybe for worksies but that has yet to be seen. Either way, I hope to see it through. The idea was a quad engine VTOL aircraft that can transition from a "hover-mode" to actual flight using props or directional thrust via ducted fans. Either way, they will be using counter-rotation to help alleviate the unwanted yaw. On the current prototype, it is a fixed wing, twin-boom design wih engines mounted on the ends of the main airfoil and the tail wing.
Currently as proof of concept, I am using a BS2 board for the fly-by-wire systems. I know that this will not suffice in the end, but to just get the engines capable of level, hands-free hover is all I'm shooting for right now. This involves at least one 2-axis acceleromter, but probably a 3-axis or two 2-axis accelerometers. I'm hoping that I have enough open·pins on the chip to handle this, because I also need to have reciever engine input and output to 4 seperate speed controllers. If I can than also be able to handle I/O for all other controls and servos.
One thing I was wondering, to cut down on pins taken up. Do you think it would be possible to run only the signal wire from the reciever, to the BS2 board, then out to the servos/speed controllers; while leaving the BS2 board off the regular +/- wires? That way only a single pin is taken up for each input or output. Basically, the reciever in the craft normally powers the servos and sends signals.
Example: I only have a single throttle channel on the transmitter/receiver. However, I want to intercept that signal, take that value and modify it for each engine based on current roll/tilt/yaw sensor data and roll/tilt/yaw input. This means if I just throttle up and don't move the other transmitter controls, then the craft should increase altitude, but should stay level.
For later down the line, I'm hoping a Propeller chip may be able to handle this all better. Using one cog for user input, one for gyro input, and others for engine control ( 4 actually ), and one to handle fly-by-wire flight-mode transitioning ( or go from "hover" to flight no matter what the user is doing, just the cogs goal is to handle modifying output variables to make it as smooth as possible without tearing the frame apart in the process. )
I'm figuring the parallel processing from the Propellor will do wonders for the crafts performance, and would start with one now, but I want to get proof of concepts down before going too far. And I want to make sure I can secure any electronics and keep them safe in case of crashes. If I lose the BS2 I'mnot feeling so bad as if I lost a new Propellor.
Also, does anyone know if servo voltages are pretty much standard, or do they vary from manufacturer?
Well, I thought a crazy idea for funsies, maybe for worksies but that has yet to be seen. Either way, I hope to see it through. The idea was a quad engine VTOL aircraft that can transition from a "hover-mode" to actual flight using props or directional thrust via ducted fans. Either way, they will be using counter-rotation to help alleviate the unwanted yaw. On the current prototype, it is a fixed wing, twin-boom design wih engines mounted on the ends of the main airfoil and the tail wing.
Currently as proof of concept, I am using a BS2 board for the fly-by-wire systems. I know that this will not suffice in the end, but to just get the engines capable of level, hands-free hover is all I'm shooting for right now. This involves at least one 2-axis acceleromter, but probably a 3-axis or two 2-axis accelerometers. I'm hoping that I have enough open·pins on the chip to handle this, because I also need to have reciever engine input and output to 4 seperate speed controllers. If I can than also be able to handle I/O for all other controls and servos.
One thing I was wondering, to cut down on pins taken up. Do you think it would be possible to run only the signal wire from the reciever, to the BS2 board, then out to the servos/speed controllers; while leaving the BS2 board off the regular +/- wires? That way only a single pin is taken up for each input or output. Basically, the reciever in the craft normally powers the servos and sends signals.
Example: I only have a single throttle channel on the transmitter/receiver. However, I want to intercept that signal, take that value and modify it for each engine based on current roll/tilt/yaw sensor data and roll/tilt/yaw input. This means if I just throttle up and don't move the other transmitter controls, then the craft should increase altitude, but should stay level.
For later down the line, I'm hoping a Propeller chip may be able to handle this all better. Using one cog for user input, one for gyro input, and others for engine control ( 4 actually ), and one to handle fly-by-wire flight-mode transitioning ( or go from "hover" to flight no matter what the user is doing, just the cogs goal is to handle modifying output variables to make it as smooth as possible without tearing the frame apart in the process. )
I'm figuring the parallel processing from the Propellor will do wonders for the crafts performance, and would start with one now, but I want to get proof of concepts down before going too far. And I want to make sure I can secure any electronics and keep them safe in case of crashes. If I lose the BS2 I'mnot feeling so bad as if I lost a new Propellor.
Also, does anyone know if servo voltages are pretty much standard, or do they vary from manufacturer?
Comments
I expect that it certainly would! If you expect to end up using the Propeller I recommend starting there as well. It will be very tricky (not sure it is even possible) to do what you are describing with a Basic Stamp. The critical factor will be the loop execution time. Can you process everything and generate all the required signals with the right pulse width before it is time to read in the next signal from the receiver? I expect this will be very difficult or impossible to do with a BS2.
- Sparks
As for the BS2, I will only be handling a single accelerometer and the engines on it for now. Once I can get it off the ground in a stable flight, then I can move to a better chip. To handle this, I'll be running each engine through it's own "V" type rotation. So that way at least one engine is correcting as quickly as possible. Again, I'm hoping by using digital accelerometers I can save some cycles. I've gotten pretty good at code optimization, so, I pray, shouldn't have too hard a time getting the basics in on the BS2. If I can pull 25-50 loops a second, then I should be ok.
Maybe, if I at least one pin left, I can use it to gather rudder input. By lowering speed on diagonal engines, I can let the diference in counter rotation turn the craft in a given direction. That or wind up one of the rear engines so that it overpowers the rest. ( Though I think a bad roll could come of that. ) Thought that won't be error-corrected for now. I'd just have to deal with it.·Forward acceleration could be acheived by minor turning of the engines.
So thats more the simpler take of it to handle what I have. I do hope to get the propellor in a few months though. Then I can re-design it for full hover and flight schemes. Then I'll have all input running in so that I can adjust the how the transmitter controls operate on the fly. That's one of the nice things. With the large difference in how heli's, hover vehicles, and aircraft·are controlled It will be nice for "Up on stick 2" to pull-up or lift up no matter how it's done.
Post Edited (Darquewing) : 6/20/2007 9:09:04 PM GMT
you may want a Gyro onboard as it's the easiest instrument to read off to decide whether or not the craft is level.
Some accellerators and gyros uses a sequence of pulses to indicate speed/change of direction, and the BS2 isn't capable of doing anything else while reading those.
Others use a voltage to indicate change, and reading that isn't any better...
I'm working on getting an X-UFO to fly autonomously, and will be using a Propeller + a Accell/gyro package from Sparkfun. This uses voltages, but the Propeller is more than capable of handling many such inputs using just one COG.
(It should be able to read two simultaneously, and by multiplexing the inputs, it should be able to do at least 16 inputs, probably more, with updated readings every 10mS... )
Unfortunately, I haven't had time to mess about with it the last few months, and also, I seems to have misplaced the Accell/Gyro board...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
I've heard the two words being used seperately, interchangeably, and as if the two were night and day. Thus far I do know that there are differences, but how different they are, I cannot yet say.
Again, I do hope to change over to a Propeller board as quickly as possible, but still must make do with what I have right now. So, in this instance, what might be the best type of gyro to install?
A 2way(X/Y) gyro would be able to tell how much the VTOL is tilting forward/back and Side-to-side.
An accelerometer on the other hand tells you how how fast you're changing speed.
(It's a G-meter.)
And while it can be used to tell you how much your craft has banked, it requires a lot of calculation to get the data, and accuracy depends on who often you sample it and the accuracy of the reading.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Take a look at these
http://www.sparkfun.com/commerce/categories.php?cPath=23_85
I fly RC Helis and have a simular project in mind but have other projects I have been working own at the moment.
It only weighs 2grams, so it definitely won't overload your carrying capacity...
(and it's waaaay less than the horror of a mechanical gyro that was stuck on the X-UFO when I got it. )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I would love to change the world, but they won't give me the source code
People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.
I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"
And to add insult to injury, it is very bad at handling sudden movements, or tilts at over 20 degrees.
When this happens, the gyro is spun down and restarted, which takes several seconds. And no, it can't restart it unless the unit is level, which means the X-UFO will crash.
Lets just say that they make a brisk trade selling replacement props for it...
The battery is a Ni-mh package, which only gives 5minutes of flight-time, if you're lucky.
A lighter Li-poly pack gives you at least 10 minutes...
Replacement gyros, Li-poly packs, brushless motors, carbon-fibre fram parts...
There's a whole third-party industry out there to fix the X-UFO.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I would love to change the world, but they won't give me the source code
People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.
I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"
I've embarked on a similar project...· And spent some time getting it up on my website
http://www.tarbox.org/helicontrol.html
However, I did take an approach that might get you going quickly.· I was pretty surprised that it all seems to work albeit in separate components for the next couplea days.
First, I'm using the Blade CX2.· You can get the entire package, heli, transmitter, batteries, recharger.... everything ready to go for $200.
The heli is somewhat non conventional for an RC. First, it uses a completely different communications scheme than regular RC's.· It uses the 2.4Ghz spectrum and, apparently, internally, uses some form of wireless USB...· whatever... I'm leaving that part for later.
An unfortunate part is that one doesn't get access to many of the normal sigals available with a regular RC hookup... but, for now, it really doesn't matter
So, my quick approach was to put a sensor pack and transmitter on the heli, powered by sucking from the LiPo pack... the heli is more than capable of lifting all the electronics.
Then, instead of trying to understand the internals of the transmitter (which would be very difficult regardless as its 2 SMD boards),· I simply spliced into the 4 potentiometers which control the heli... turns out its all 3.3 volts so the prop chip I'm using is great.
So, I have a prop-usb, ultrasonic sesor, and transmitter sitting on the heli.· There is another prop chip glued to the transmitter with a receiver to get what the heli sensors transmit.· I have a compass, 3 axis accelerometer, and GPS receiver·in the wings to be installed later.
Today, I got the delta-sigma ADC to work so I can read the controller stick values.· DAC should be straightforward so the prop can input values directly into the rc controller... so I have all the parts kinda working (spent the day soldering the proto board for the heli... just using a breadoard on the controller)
So, now comes the hard part. The heli has a gyro built in for yaw. Works pretty well.· I noticed some discussion of gyros in this thread and I think there may be some confusion.· These small MEMS gyros are "rate" gyros, they don't provide absolute position.· Rate is sufficient for the time being but the compass and GPS will be needed for the "drift" implied by noise and the integration of rate to get angle...
But, being an adherent of the Agile approach, the first test will simply be altitude control. I'll read the height from the ultrasonic sensor and control the power applied.· The internal gyro will help with the torque problems... but I'll be directly controlling that later.
Of course, the really tricky part is the control laws.· A linear controller (PID)·will likely work for hovering but I expect to need to get fancier later.· I see discussions from time to time on various techniques like Kalma filtering etc... but I've done control work in the past and there is always the "plant" which really needs to be identified to get much help there...
So, I'm expecting to begin experiments using system identification techniques... basically, I'll be applying varying inputs to the controls at known displacements, frequencies, etc... and attempt to get a close linear model of the behavior.· Then, I'll begin the process of identifying the noise of the sensors, the coupling of the degrees-of-freedom (e.g. when one increases thrust, one must expect yaw... the gyro should only be used for error correction).· I'll be focusing on the accelerometers, ultrasonic sensor, and probably a new gyro (Analog Devices iMEMS of some sort)... I may need to hack the heli's control pack to disable / reroute the internal gyro for some of this... but I'm guessing having the gyro as part of the system being identified will work for a first cut)
I have a bunch of pictures... and will have more.· Perhaps I'll download them tonight and put them up for you folks to see...
I think the approach I'm taking is interesting in that its pretty easy and very cheap for the platform (the blade cx2)...· The propeller is a great chip for the project (a basic stamp wouldn't even come close to working).
And, of course, there's the software component which will live on the laptop providing ground station functionality, some graphics etc...· I'm pretty sure I'll have a first cut working closed loop in early August...
more later...
-glenn
Unfortunately, the GPS is only good for low-rate absolute position information (something like 1 sample / sec).· It's also very inaccurate for the kinds of control one needs to get proper behavior.
So, the strategy is to use the gyros, ultrasonic and·accelerometers for control of the heli and use GPS for correcting drift and once I get going farther away.· Could try DGPS to improve accuracy but theres more to it than simply comparing a local fixed GPS receiver to the one on the heli...· It seems like it would be straigtforward but upon looking into it, there is wierdness...
I'm also playing around with the compass.· We'll see how well that works given the electric motors etc...
-glenn