Odometry / wheel encoders / record - playback

I have tried various methods for navigating a robot lawnmower. Now I propose to try a simple method as follows and would like any comments and guidance:

  1. Add encoders (1600 counts per revolution) directly to the wheel shafts of both wheels (differential drive robot).
  2. Drive the mower around the lawn manually or using wireless remote control.
  3. RECORD PATTERN: Using Mega/Interrupts/bluetooth shield/pc/Visual Basic I will record the encoder counts (two longs) every 100mS to a serial file in the PC as I drive the mower around my lawn in the pattern I want it to copy.
  4. PLAYBACK PATTERN: Playback the PC file at the same rate via bluetooth to the robot and have the Mega compare the pre-recorded values with its actual real-time encoder counts each 100mS. If the recorded value is > real time encoder count then speed up that wheel and visa-versa for each wheel (even reverse if necessary). Probably use a PID loop for each independant wheel.

I think this eliminates most odometry errors leaving only errors due to wheel slippage (I intend to add studs to the wheels and running slowly).

Maybe, for example at the lawn corners, I could force the robot into a certain fixed 'start' position and orientation and re-zero the counters at these 'start' or 'reset' positions? One of these 'reset' locations would be the 'home' position where the automatic battery charger is located.

If the wheel slip is repeatable then I could compensate for it by adjusting the pre-recorded counts.

Anyone else done something similar?

With any kind of odometry you still need regular checks that give your absolute position.

Self navigating industrial robots use under floor inductive loops, RF beacons, laser range finders, vision systems and IMUs.
None of these are cheap.

There's a book called "Mobile Robotics: A Practical Introduction"

warren631:
4. PLAYBACK PATTERN: Playback the PC file at the same rate via bluetooth

I don’t know exactly what you have in mind here, but don’t expect the PC to be able to send a stream of timed pulses. It could send messages like “go forward 5000 pulses on the right wheel and 4763 pulses on the left wheel at 223 pulses per second”. (Obviously such a message would actually be <5000, 4763, 223>)

…R

I propose that the serial file (of long variables in text) pre-recorded (learned) in the PC would be like this:

458763, 45877
458790, 45889
458901, 45897
etc, etc...

Each 100mS the PC transmits via bluetooth one line of the file for right and left wheels. The robot compares the latest values with its actual encoder counts and adjusts its wheel speeds accordingly. I know how to do this with Visual Basic.

I need to use the PC because the Arduino does not have enough EEPROM memory. I could also invest in an on-board SD card reader to replace the PC/bluetooth but I like the idea of PC remote monitoring.

The positioning errors will accumulate due to wheel slip etc. and eventually the lawn mower will be hard up against the fence trying to mow the grass on the adjacent property.

Submarines face the same problem. Dead reckoning will only give an approximate location that degrades over time. Eventually you have to come to the surface to look for visual landmarks or RF beacons/satellites.

warren631:
Each 100mS the PC transmits via bluetooth one line of the file for right and left wheels.

If you have in mind that the PC would send those numbers back to the Arduino to cause it to retrace its steps then I think that should be feasible. But the precise 100ms timekeeping will have done by the Arduino. The PC will just send the next set of numbers whenever requested.

If you could do the count over (say) 200msecs you would greatly reduce the communication overhead and I doubt if the position accuracy would suffer.

I am not commenting at all on the practical problems that @mikb55 has mentioned.

...R

There is no problem sending the data from the PC every say 100mS. I just use a timer in the VB6 code to trigger the sending subroutine. The timing does not really matter. If the data is recorded at one pair of positions (wheel encoder counts) every 100mS but the playback is only every 200mS then the robot will move at half the speed as when it was recording - no big deal although wheel slippage might be a little different at different speeds.

This is not true odemetry where you try to calculate positions and directions and turn angles using mathematics (with all the inherent resolution errors which multiply with distance traveled).

Anyhow, I will let you know my experience with this.

warren631:
If the data is recorded at one pair of positions (wheel encoder counts) every 100mS but the playback is only every 200mS then the robot will move at half the speed as when it was recording

If the turning movements depend on repeating different encoder counts for each wheel I think you will need more precision. I strongly advise that you leave the timing to the Arduino.

...R