I am making a simple robot, and am using a relatively cheap RF transmitter and receiver to send commands to my robot. Essentially, the transmitter end would send data from an AVR MCU via its UART to the RF transmitter, and a similar setup on the robot would pick up the data.
So what I am confused about is how this whole process works. I mean, suppose I have four motors on my robot which all need to be controlled individually and at the same time. How would I accomplish this? Would I encode my info in a byte (say, 1111000) where the first four bits represent the on or off position of the four motors, and the receiver would decode this and carry out the necessary task? Or is there another, better way of doing this?
This leads to my next question related to this. Suppose the method I just described is used, then how is the robot typically programmed to handle commands? Say, it receives the 11110000 packet, and turns on all four motors. Do I just let the robot keep the motors on until a new packet of info is received? Essentially, if I want continuous communication with my robot (one way is fine in this case), how would I do it if it takes a certain amount of time between each signal which is sent to be processed and carried out before the next one comes in? Maybe the time it takes for the signal to be sent, processed, and carried out is is small that the impact is unnoticeable?
EDIT: Here is a link to the RF Tx/Rx I bought.
Best Answer
One challenge using those types of RF modules is that the receivers can receive a lot of random noise between transmissions. They also like the signal transmitted to be DC balanced, long strings of zeroes and ones can cause distortion in the output from the data slicer in the receiver.
The usual way to deal with random noise between transmissions is to introduce a preamble to that the receiver knows a valid packet is on the way and to synchronize the UART ready. Maintaining the DC balance requires using an encoding scheme that keeps the number of 1 and 0 bits in each byte as close as possible to equal.
I've used the following application note from Radiotronix that includes a source code example in the past to implement a system that worked well using modules similar to the ones you're using. The only change I had to make was to introduce a delay before transmitting and increase the length of the preamble, although that was mainly required because I was powering down the transmitter between transmissions so you may not require the same.
Radiotronix Application Note AN-401
Once you have the basics sorted you'll need to consider what to do when a transmission is lost, I'd recommend sending the data several times and then have a timeout that will stop the robot after a pre-determined time. You may want to also consider using some relatively long (say 4 byte) commands that are essentially random (ie. don't use 1,2,3) so that you can determine the difference between a valid command and a data error.
I'd probably start with a baud rate of 2400bps for those modules. Using the above scheme that will give a transmission time of somewhere around 40mS so if you were to transmit each command twice a latency under 100mS should be realistic.