Hello,
I have wanted to make myself an R/C airplane for a loong time. Availability in this part of the world as well as the expense has been a problem. Once I found arduino, I have been thinking, why is it necessary to use those transmitter/receivers anyway? Why encode in PPM/PCM ?
Why not .. say send the position of the servos ( say 4 ch ) as 4 bytes as a serial stream through an xbee radio or a cheap rf module? Then maybe a lightweight arduino like the Sparkfun wee on the airplane, can separate these values, and apply them to the servos .
Then there is this servo controller board from polulu
I am not sure how it is used but I think it has some kind of a serial interface. Well, then can't this serial data be sent over the air?
Doesn't that make a much cheaper R/C solution rather than buying the transmitters+receivers? Of course, the joystick etc. could be a problem, but we can rig something from a few pots .. or maybe take apart an old transmitter/usb R/C trainer thingy.
Doesn't that make a much cheaper R/C solution rather than buying the transmitters+receivers
In a multichannel R/C, after the receiver, the decoder is (or used to be in The Good Old Days (tm)) a single TTL counter chip, with a simple RC to ensure it got reset it in the inter-frame gap.
Can't get much simpler/cheaper than that.
It operated at a typical update rate of say, 6 channels every 20mS (50Hz).
A radio serial link will have to transmit those 6 channels as at least one byte per channel, so 60 bits (even without error checking) every 20mS or 3000 bits per second, minimum. You'll need to synchronise too, adding possibly redundant codes.
Radios are noisy, better add some error checking, so you'll have to raise that bit rate even higher.
I'm not saying don't, just be aware of the problems.
Well , I guess I still dont understand the PPM system much. Why would it be necessary to send the channel every 20 ms ?
There is the Serial.available() function right? I can wait till 4 bytes/6 bytes are available and then read. Of course, the noise can be a big problem.
And at edge of range controls can become sluggish. But isn't that the case in all radio systems ?
I can just keep on sending the bytes out. Maybe with some kind of a one-byte header byte to denote start of a message and the end of the message. ( Servo position is only from 0-180. Rest of the byte till 255 is available for use like this )
No, you may not need the 50Hz update rate, but in existing radio systems, this automatically gives a degree of noise immunity - the servo hasn't got time to move to an erroneous position before the next (hopefully more noise-free) position pulse has arrived (except for very fast servos).
If you only transmit a change when you have to (ie, when the stick position changes), and you don't have adequate noise protection, there's no guarantee that the servo will go to the position you want it.
Because you probably don't want two-way comms, you've got no way of requesting a re-send.
Ok .. so are the existing radio systems capable of maintaining sufficient datarate to the edge of their ranges? I didnt say that the transmitter only transmits when the stick changes. Its just keeps on sending them all the time as fast as it can.
The receiver will look for a series of bytes that match the pattern of the frame( header .. data .. footer) Decode it and use it. Is that viable?
Is it possible to implement a PPM based system in Arduino? Can it work using xBee/RF modules?
Hello,
I know it will be expensive if I use Xbee. But not so much so if I use one of those cheap 433 MHz RF kits. Of course the range is less but for indoor applications they maybe suffice.
As for signal generated by Arduino for servos, will it be sufficient to rig the "Servo pin" from the arduino to the data pin of the RF Tx and similarly connecting the Rx pin of the RF receiver to the Servo?
Of course that would be a single channel system. Some kind of multiplexer/encoder or something would be needed for multichannel data.