I may be over-thinking this, but I also hate reinventing the wheel.
A number of people over the years have posted about robot designs where a microcontroller does low-level control and a PC does high level planning, mapping, etc. Most of the papers on sonar mapping mention using this technique. However, I've seen very little written about the actual commands used.
I've got most of my low-level micro code working, so this is the next step. I was hoping to get some ideas on what kind of commands are best to implement, ie: robot-type commands like Move n units, turn n degrees, or more low-level control through direct access to PID parameters. Another thought was if the micro should only give status updates (position, etc) when asked or send them periodically on it's own, and how often.
I don't expect to find a "This is how to do it" document, but I'm surprised I haven't found any write-ups on what someone else has done and how it worked for them.
It's actually quite smart to ask around and do research before you start hacking away. That's how real engineering is done, and it's more likely to get you to a successful result. In addition, you are likely to discover aspects of the problem that you had not considered. So bravo!
On to the problem. Yes, lots of folks have considered this problem, and come up with various solutions. You might do a search for stand-alone servo or stepper control boards or chips, often they have a serial connection with a command set.
Here's an example:
formatting link
Here's my own setup:
I use a number of small processors, each set up to do a limited set of control functions, so I can get each of them up and running, and move on to the next function. The micros are hooked in parallel to the stepper power,direction and step lines so any micro can "take control" of the steppers. The PC talks to them via an i2c connection, and also uses the i2c to read sensors. Unless you need an extremely "tight" connection between a sensor and a motor control micro, I'd let the PC read the sensors and make decisions.
The basic set of motor control functions:
Power on/power off to the motors (important to power down battery driven motors)
Set direction of motors CW/ACW
Toggle Motor Step lines up/down (useful for testing from the PC, and for slow "fine" movement, hardly ever use it so no need for a dedicated micro)
Rotate wheels x times at a fixed speed (generally used for approaches or back away from a bump, so different speeds were not needed, a rotation is 200 steps of the stepper, maximum rotations are 255 for simple math in the micro)
Set steppers to stepping at a set frequency (the most often used function, left and right can be independently set so you can get turning while moving forward, up to 255 Hz for each wheel for simplicity)
Turn to a compass heading (micro uses an electronic compass to set direction and speed of the motors, but not a very good function and probably won't be used on the final system, darn flakey compasses!)
Each of the above functions have an associated "check if busy" function, so the PC can tell if the function has finished or not.
In general, I try to keep the micro stuff as simple and "contained" as possible, and put all the high level stuff on the PC.
: On to the problem. Yes, lots of folks have considered this problem, : and come up with various solutions. You might do a search for : stand-alone servo or stepper control boards or chips, often they have : a serial connection with a command set.
That's what I've seen as available on the hardware side, which makes sense if you are selling a generic controller. From the perspective of people who actually made a robot, the only real reference I found was in "The Map-Building and Exploration Strategies of a Simple Sonar Equipped Mobile Robot" By David Lee -- his master's thesis. He actually gives the language he came up with, which came down to some simple commands -- Move n units forward, Rotate N degrees, Take a sonar reading, and Take a full sonar sweep.
This seemed simple enough for a first stab at least, and was the direction I was leaning. I have drive PID, sonar, sonar rotation, and bumpers all on a single ATmega16, talking to the PC via rs232.
However, he didn't mention at all if this method was adequate, or what limitations it posed. My feeling is it's probably easier to implement complete functions like move and rotate on a single micro, but it will make later changes more difficult.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.