Odometry for wheeled robot

[jodicalhon]

I have a small two-wheeled robot using differential drive. I've fitted wheel encoders and I'm pretty sure (famous last words!) that I can implement some sort of speed control by counting clicks/time on one motor, then clicks/time on the other, and vary a PWM source to independently control each motor's speed.

If I also want to calculate the total distance travelled by the bot, and its postion in cartesian space, I would have to count total clicks on wheel A and total clicks on wheel B, wouldn't I? (And do some calculating!)

I can only think that I would have to swap between wheels as I count, and would likely end up with inaccurate counts.

Am I right? Am I missing something? Is the answer right in front of me? What is the best way to go about this sort of thing?

Any help appreciated.

Jo

 

[Rickharris]

Actually a major problem will be wheel slip. This happens very often for all sorts of reasons unless you move very slowly. It causea as miscount of course.

A more accurate method is to use some sort of beacon system so that the robot receives a signal that it can then translate into position in space.

Alternatively a fixed PC could receive a signal from the robot and calculate position then send it back to the robot.

Picaxes have problems implementing arrays which is really what you need to map your position.

 

[Jeremy Leach]

Hi Jo, there's been a lot of discussion about coordinates before - solutions including ultrasonic, GPS, laser, bar-coded squares and one I dreamt up a while ago involving coloured squares (which I still haven't tested) ! Plus I'm sure many more.

There's no simple solution. It also depends on the accuracy you're looking for.

I'm not a robot expert at all, but the trouble with measuring and calculating from the wheels themselves is that errors will accumulate, probably fairly quickly.

Varying the speed of each motor is another matter, and I'm sure you'll get a lot of help on that one.

 

[BeanieBots]

The most common approach using dead reckoning is to use 'idle' wheels with encoders fitted. This gets round the problem of slippage and errors due to tyre wear on the drive wheels.
If you stick with PICAXE as the controller, you will have a few problems with the limited maths (integer only and no trig) trying do the required sums. You could use use the floating point processor but speed might become your enemy if you want high resolution. Consider using several PICAXEs to read the encoders and then have them communicate with each other. Using interrupts will ensure that encoder events are not missed while other things are being calculated.
Robotic navigation can be made as complex as your imagination will allow, but there is no "really simple" solution that I am aware of.

 

[jodicalhon]

Many thanks for your input. I would like to stick with Picaxe ('cos that's what I know!) but, hmmm, I hadn't thought about the lack of trig yet. Would have become clear sooner or later, I suppose!

The other solutions involving beacons, etc, I find quite appealing. I'll do a better search of the forums and a bit more investigating.

Thanks again, all. This is a very helpful place to visit!

Cheers

Jo

 

[Fowkc]

Tech Supplies sell a maths co-processor (order code FPU001) that does trig (and other stuff) and uses an i2c interface.

http://www.micromegacorp.com/picaxe.html

Helpfully, the manufacturer has lots of info about PICAXE interfacing.

 

[jodicalhon]

Oh, thanks mate. I'll have a look.