Wireless communication with robot

    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?

    The classic answer is that there's no "wrong" way to do this, but rather your design criteria depend on your application.


    The "constant communication" scenario is generally called "polled I/O" in industry -- basically, registers of bits are constantly updated in a hard-realtime fashion over the communications bus, and all the devices on the bus can assume that the data in those registers is always "fresh." Any communication interruption lasting more than a certain number of update cycles triggers a comm-failure watchdog event and halts all operations for safety.


    So, assuming all 4 of your motors are driven using H-Bridge drivers, each driver will need 2 bits -- one for CW, one for CCW (never turn on both inputs to an H-bridge). So you need 8 bits. The microcontroller (let's assume an Arduino) on board the robot is constantly polling the input registers from the wireless link (maybe an ESP8266), and every X milliseconds updates the outputs to the H-Bridges to match the 8 bits coming in from the ESP.


    But, what about a failure? Well, one typical way to handle this is to allocate another bit, or several, on the communications link. This bit(s) has a value that should change every comm cycle (a byte might simply count from 1 to 255 then rollover back to 1). The ESP or the Arduino would have to monitor this "heartbeat", and if the value failed to update, trigger a safety stop of all the H-Bridges (both inputs on each H-Bridge to 0V, which usually causes regenerative braking).


    This can, of course, become much more elaborate, but that's the kinds of barebones setup you can start with.

Advertising from our partners