I am planning to make a RC blimp for a college freshman project and need some beginner's direction as to how to connect the components to the board and what code to look at so I get an idea of where to start (I'm familiar with Java so this isn't so bad). I am going to salvage a Tx/Rx from a Megatech Merlin (72 Mhz) airplane to control the blimp. There will be 2 motors on each side and a servo to do thrust vectoring (it will rotate a rod which the 2 motors are mounted on). So far my research shows that controlling 3 channels requires interrupts so resources aren't taken up. I am provided the Arduino Duemilanove for the project which I know has 2 interrupts so is it possible to receive 3 channels and then control the servo and motors plugged into the Arduino? Also, do the servos/motors need seperate power sources? Your help is much appreciated!
Oh, it's that time of the year again, where big projects are hatched. Well, lets apply a little common sense see what we'll get.
As you already mentioned, reading more than 2 PWM-channels from the RC-reciever becomes a pain because you just have 2 easy to attach interrupts (Pin 2 and 3). However, controlling up to 12 servos is no real problem.
If you have a channel that isn't too sensitive to changes (eg motor setting), you can read that one by polling.
You can also use the general change interrupt for a pin group and then parse out on your own which one was changed to handle up to 8 incoming signals. You 'll have to take care to write your interrupt properly and it helps it the various PWM signals don't come in all at the same time like in some modern RC-receivers.
As an alternative, you could spend another dollar or two on a counter chip per input channel and measure the PWM-signal with those. The you'll have no trouble at all to parse as many inputs as you want.
With a blimp you need to plan carefully because your weight requirement is probably very, very exacting.
I'm not quite clear how you mean to combine the salvaged RC transmitter/receiver with the Arduino. It seems a bit strange to decode the RC's servo-frequency PWM and turn it back into... servo-frequency PWM! What is the Arduino doing in this process? If you have to carry an Arduino (I presume the point of the exercise is to develop control code?) is it better to use a simpler radio module?
(edit: I hasten to add, I'm sorry if I sound a bit negative here, I don't mean to! I love blimps... )
About the weight, I can well imagine that an Arduino pro mini is still within the weight budget.
What kind of radio-module do you have in mind. I could use something like this for another project, if it can receive signals sent by the usual RC-transmitter.
I don't know radio very well at all, but it seems like it might be easier to send serial digital data than to use an r/c transmitter. The bandwidth would not need to be large.
The original poster, who has had an Arduino duemilanove provided by his college and is presumably expected to use it, will know better than I can what radio kit is available in his lab!
If I were buying something from scratch I would probably try those cheap "RF link" modules from Sparkfun. At about $10 for a transmitter/receiver pair, it's not too much lost if they don't do the job, but it sounds like they would do the trick for an indoor blimp.
(I'm assuming this is indoor. Otherwise the blimp engineering is going to be much trickier than the arduino part)
I think one of the main advantages of using a standard RC-transmitter/receiver pair is that the communication between the controller and the blimp is solved. The range is known, the user interface is known, the latency is known, it uses legal frequencies and you can use for the other aspect that don't need the special function commercial off the shelf products that are are tested. There won't be any surprises there. In the end, hooking up to 2 or 3 servo-control lines and measuring the PWM-pulse length is far less work than doing the radio part with some wacky gizmo. I was hoping, you had a good and affordable solution for a standard RC-receiver with digital output to avoid the PWM signals.
If you have a channel that isn't too sensitive to changes (eg motor setting), you can read that one by polling.
Does this mean hooking up two channels to the interrupts and using something like pulsein for the third channel?
I'm not quite clear how you mean to combine the salvaged RC transmitter/receiver with the Arduino. It seems a bit strange to decode the RC's servo-frequency PWM and turn it back into... servo-frequency PWM! What is the Arduino doing in this process? If you have to carry an Arduino (I presume the point of the exercise is to develop control code?) is it better to use a simpler radio module?
We are provided one of these kits (Adafruit MetroX Classic Kit - Experimentation Kit for Metro 328 : ID 170 : $84.95 : Adafruit Industries, Unique & fun DIY electronics and kits) and given a $50 budget so I'm salvaging some RC stuff I already have since even the cheapest radio systems are at least $30-$40. Since it comes from a plane, 2 of the channels were meant to drive servos and one for the motor. So yes it's more of a programming exercise to get the left stick to control throttle, right stick up/down movement to control vector thrusting, and right stick left/right movement to control turning (turning on or off the two motors). Don't know if there is a simpler way of doing this (the project has to involve an Arduino).
With a blimp you need to plan carefully because your weight requirement is probably very, very exacting.
We'll since we're stuck with the Duemilanove, I was thinking of constructing the whole unit and then figuring from there on what size balloon to get in order to lift that amount of weight.
Does this mean hooking up two channels to the interrupts and using something like pulsein for the third channel?
Yes. If you don't need extremely quick response and can afford to miss one or two 20ms refresh cycles of the servo INPUT, you can do all of it with pulseIn and don't need interrupts at all. And if you happen to poll the in the order the RC-receiver sends them out, you might not lose any time. You should be able to look into that by measuring how long pulseIn takes usually to get a value.
The refreshing of the servo OUTPUT is done interrupt driven by the Servo library anyway, so the main inconvenience of this scheme is a little slower response to your commands, which might not be that much of a factor by a blimp. This isn't a stunt-plane after all.
Question: to read a mass of servo PWMs with a single timer interrupt, would it work to use one timer interrupt to repetitively copy a whole port (say PORTB) to successive locations of an array in memory (an array long enough to represent a decently long sample of PWM time, but not so long as to introduce excess latency)?
Then the main loop can concentrate on averaging the results for each bit of the array in turn (sum of a certain bit position = value for that channel) and making decisions based on the results.
Feasible?
(I just thought of this and can't test it right now, feel free to shoot it down)
Caiol - that definitely sounds like the right way around to do it, measuring the electronics and making a blimp to match, but it's still going to have to be a very trim system. What do you reckon the smallest battery you can carry would be?
in theory yes. The interesting part is how precise do you want that measure to be and if the PWM signals on all line are staggered or come at the same time.
For the precision, if you want to discriminate between 1024 positions, you need the measurement to be precise to the µs. That's 16 clock cycles on a 16 MHz cpu.
If your PWM signals are generated by an old style receiver in a serial manner, you plan probably will work. But it seems newer receivers start the PWM for all servo at the same time. With those, you might get two signals ending roughly at the same time and the processing of the second will be delayed while the first still runs thus affecting the measured time for the second.
As I wrote earlier, if you have a system that reacts slowly to controls like a steam boat or - I imagine - a blimp, you also might get away not reading every single PWM signal but cycle through the pins and concentrating on just one at the time. This might not work for very twitchy application where small delays produce big consequences.
I wasn't imagining that this would be perfectly precise or low-latency. Just that it might be an interesting, low-resource way to read up to 6 PWM channels at a time. It might be possible to increase accuracy at the expense of latency by stretching the sample over several PWM cycles - leaving more time for the Arduino to process.
(I'm also assuming that some kind of "switch on with the sticks centred" arrangement might be needed to let the Arduino measure neutral positions before we get started)
If the PWMs are parallel rather than serial, the values will make it into memory in parallel, then the Arduino's limited resources will churn through them in serial, resulting in latency. However, it might well be an acceptable amount. I don't have access to an RC set right now (mine's in long term storage no flying for me) so can't test, but it would seem that the key measure is "what fraction of the servo latency does this introduce" (or perhaps "what multiple of the servo latency..."). If it's a large multiple, this had better stick to slower moving applications.
If the PWMs are parallel rather than serial, the values will make it into memory in parallel, then the Arduino's limited resources will churn through them in serial, resulting in latency.
No, you got that wrong. Wrong consequence and wrong reason. Limited resources have nothing to do with it.
Erm, I'm not sure I explained what I had in mind well then.
We copy a whole port's worth of data into memory at a time, using the interrupt.
In the slices in between those interrupts, we have to work out what that data is doing.
The way of doing so that I envisaged would be to work on the bits representing the first channel, then set the corresponding controls. Then work on the bits representing the second...
If we could get through processing all the channels between each timer interrupt, we would never introduce an excessive delay. But, obviously, we can't. If it takes too long to get through channels 1...n, a change commanded to channel n+1 just after it has been checked might take a while to be processed. This would be a problem for a super-fast, twitchy model but probably not for a gently cruising blimp.
If my logic is incorrect here, please help me understand how.
Of course, a better plan than mine for working on the stored data might be able to circumvent this issue. However, if we are storing samples of the pulses and then measuring them, even a perfect way of processing the data is going to have to allow time for measurement somewhere. The question is only "is it acceptable for this purpose", surely?
You're trying to solve a problem that isn't one - processing time once a value is read - while ignoring a problem that is one - getting an accurate time measure of the PWM pulse length. That's all.
Korman - I'm confident I can read the values well enough, but I fell asleep last night before I could finish coding a test Too much real work right now.
Also, as my RC gear is in a box somewhere, I am trying to mimic it using another Arduino running the servo library. I know this is not the same, but it should be similar enough to prove the concept.
I'm confident I can read the values well enough, but I fell asleep last night before I could finish coding a test
That's good. I ran into problems that I got wrong readings occasionally. How many varied with the servo position, but it created enough jitter to make it a concern when using the value to drive another servo.
Ok, I just received the RC equipment yesterday. Here's some photos.
Some things I noted:
-The battery plugs into the white port on the ESC, the motor(not shown) plugs into the red/black pin connectors on the ESC
-The ESC plugs into Ch3
-There are holes marked for Ch1-4 at the center of the board, but only Ch3 has pins soldered in place (the rest are filled with solder)
-The servos aren't the standard RC plane ones I've seen, they have 5 wires and plug into the white ports
I will be using a 3-pin type 9 gram servo so I need to find a way to hook it up to one of the other channels. I will be going to a electronics lab at my school to do some testing with an oscilloscope.
no flying for me) so can't test, but it would seem that the key measure is "what fraction of the servo latency does this introduce" (or perhaps "what multiple of the servo latency..."). If it's a large multiple, this had better stick to slower moving applications.
Too much real work right now.