Subject:
|
Re: odometry (was Re: Homing with the IR Tower)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 28 Jul 1999 08:20:11 GMT
|
Viewed:
|
1021 times
|
| |
|
|
In lugnet.robotics, lego-robotics@crynwr.com (Laurentino Martins) writes:
> At 14:51 27-07-1999 Tuesday , Mario Ferrari wrote:
> > I believe that tracks (or wheels coupled to behave like tracks) are a poor
> > choice to get good results from odometry. I mean, as this mechanical
> > arrangement relies on slippage to turn, it's unprecise for its own nature.
> > IMO a differential drive is much more suitable to get the best from odometry.
>
> I've built a PC program for the CyberMaster that pools the integrated
> tachometers continuously and shows the trajectory of the bot in the PC
> screen.
> It uses _tracks_, and I've found out that besides one of the tracks runs a
> bit better than the other (by hand), it has no real importance since the
> instructions to the bot are like: "Turn the left track 95 ticks". And since
> 95 ticks are always 95 ticks, the track always runs the same, no mater how
> difficult is for the motors to do it.
Yes, 95 ticks are always 95 ticks, but the point is if your robot really *is*
in the position where it's expected to be on the floor. The main problem with
odometry, as you know well, is that errors accumulate very fast. The
unavoidable slippage of the tracks makes the things worse. From what I read so
far about detecting a robot position, tracks are the worst choice. See, for
example, the great "Where am I? Sensors and methods for Mobile Robot
Positioning" by J.Borenstein (freely available on the net but can't remember
where).
> My conclusion is that identical tracks (left/right) have identical slippage
> _if_ the floor is identical below both the tracks and the bot has symmetrical
> shape and weight.
True. But when dealing with odometry I still prefer to avoid slippage by
design instead of relying on *identical* slippage of the tracks.
> I think the same happens with differential drive (?).
In a good differential drive there is no significative slippage of the main
wheels.
> The biggest error with tracks happen when you change heading by turning one
> track while the other is stopped. Don't do this, always change heading by
> turning a track backwards and the other forward at the same time. That way
> the bot turns on it's axis and it's much more accurate.
I agree this helps a lot.
> Of course there are errors, and the worst part is that they accumulate over
> time. It's very difficult to see why they happen (believe me, I've tried),
> but that's one of the things I don't expect to correct because they seem
> inevitable due to the nature of the odometry.
> If you are thinking in constructing a robot that uses only odometry to
> navigate, don't expect it to go far or for a long time without heading and
> distance errors.
I did, I know the problems. Some months ago I posted a message about a robot
that used odometry to determine its heading and position. All the computations
were made inside the RCX, and for that reason I had to use legOS (I needed
32bit integers and arrays to interpolate the trig functions). I was glad with
the results: after a few meters of random, non orthogonal moves, the error in
the estimated position and heading was still below 2%. For longer range
navigation you need artificial landmarks to zero your errors from time to time
(loke tape on the floor or other signs).
BTW, I do love tracks and vehicle with tracks. Simply don't use them for
odometry :-)
Mario
http://www.geocities.com/~marioferrari
|
|
Message is in Reply To:
 | | Re: Homing with the IR Tower
|
| (...) I've built a PC program for the CyberMaster that pools the integrated tachometers continuously and shows the trajectory of the bot in the PC screen. It uses _tracks_, and I've found out that besides one of the tracks runs a bit better than the (...) (25 years ago, 27-Jul-99, to lugnet.robotics)
|
23 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
