How to use a computer to communicate with robot's controller boards

[Avayan]

I like to use microcontrollers to take care of different aspects of a robot in real time (such as controlling motors and loads, reading sensors, etc.), while the robot intelligence is taken care of by a computer. This has a series of advantages, namely:

1. Each microcontroller can take care of the real time issues of reading sensors, shaft encoders, and other variables at a fast pace.
2. The computer requests the information on an interval basis and as needed.
3. The computer does not need to interrupt intelligent control to take care of mundane tasks such as those mentioned on item 1.

This is pretty much parallel processing, which is how our brain works. But how do we add controller boards to a computer? As you can see on the picture below, we wcan take advantage of the computer's serial port. It can be an RS-232 port (which are pretty much obsolete) or USB ports, which are very popular nowadays, plus the amount of them are practically infinite to the application at hand. There is of course a limit, but I can not imagine a robot that will ever close to such.



What I like to do is have each microcontroller coded to accept a series of bytes (I will from now on call a packet) which includes an instruction and data on how to perform said instruction. Per example, I could have a motor controller board coded to accept a command such that a particular motor speed is maintained and another command to stop the motor. I can have another controller board coded to accept commands such that a series of sensors are read. Why not put the motor controller and the sensor board together? It can be done, but if you have about a dozen of very simple MCU's with very simple tasks, you will get better performance than if you have a giant MCU with a ton of tasks to resolve.

The other advantage is that you can have multiple boards for a particular task. Say you need 15 sensors, but each board can only tackle 8 sensors. It is easier to add a second module than it is to redesign the entire application to take up more inputs. I think modularity is pretty advantageous and in this case, it usually proves as such.

In upcoming posts, I will explain how the serial communication works from a microcontroller stand point and what does the computer needs to do.

[EvilSpeeder]

Another advantage I see to this approach could be very helpful to beginners in robotics. 

In my experience learning robotics is all about layers and building upon what you learned previously.  As I'm learning to program, I'm creating functions that I can continue to use in any robot I build (that uses C++).  That way I don't have to repeat work when I start each new project.  On the hardware side I began with a single microcontroller.  I've learned to make it do tasks of ever increasing complexity.  Each one of these 'projects' could then be used to expand on previous experience.  As you continue you'll be able to keep combining these projects into a useful thing.  The first project will be getting two micros to do two things independently.  The second task will be making them talk to each other.  Then we will add more micros in this way until we have the framework for a useful robot.  Somewhere around that point some higher level of control will be needed and the PC can be brought into the picture.  Skills you've learned in making the micros talk to each other can then be use to make the computer talk to the micros. 

It's a very nice modular way to learn.

[Rud]

It is useful to have a standard set of communications routines that you can rework for different serial communication chips. Back in the 70-80s I did a lot of embedded system work. Each project, it seemed, used a different serial communication IC. I developed the C functions listed below. Most of them did not change from system to system. What changed were the underlying routines that setup the port and interrupt and the interrupt handlers. But once those hardware level routines were working the higher level routines were ready to go. On one project I could run the code on a IBM PC running DOS or the target hardware. The only difference was getting the low-level routines to work on both platforms. Even the simple multi-tasking environment ran on both systems.

void AbortComm();
void PortOpen(    int port, int baud, int bits, int parity, int even, int stop);
int RxBuffCount(  int port);  // count is how many bytes in a circular buffer
int TxBuffCount(  int port);
void WriteBuffer( int port, int cnt, byte buf[]);
void ReadBuffer(  int port, int * cnt, byte * buf);
byte ReadCh(      int port);
byte PeekCh(      int port);
void WriteCh(     int port, byte ch);
byte ReadStatus(  int port);