2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Any datasheet / link to the transmitter and receiver you're using? Some of the types that don't include any packet handling can be a bit trickier than it sounds to use reliably. \$\endgroup\$ – PeterJ Mar 11 '13 at 4:00
2
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

If your commands are few in number you can use a simple binary packing as your propose. However, once your commands exceed one byte in size, if there's any chance of unreliability in the channel you face the problem of framing, ie, determining which byte falls where in a multi-byte command. There are stock solutions for that, all of them a bit inelegant (illegal codes, bit stuffing, etc), though most are in common use.

Given that, another possibility worth considering (if you have the bandwidth) is human readable ASCII text commands, with a terminator such as a newline. This is of course wasteful of bits, but it has two advantages going for it - first, that you can open up a terminal and type commands to the robot while testing or experimenting (you can also have it give readable status replies). Second, the terminating newline character easily and cleanly delimits the messages.

As for your question about how to have it respond, you could have it continue to do the last thing asked, but another possibility worth considering would be to have it automatically stop after a few seconds of either no communication through the channel, or after some loss-of-signal indication from the radio modem itself.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.