Subject:
|
Re: Homing with the IR Tower
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 27 Jul 1999 16:26:53 GMT
|
Original-From:
|
Laurentino Martins <lmartins@marktest.^nospam^pt>
|
Viewed:
|
978 times
|
| |
|
|
At 14:51 27-07-1999 Tuesday , Mario Ferrari wrote:
> In lugnet.robotics, Chris Phillips writes:
> > In lugnet.robotics, Hao-yang Wang writes:
> > > A while ago I was intrigued by the soda can retrieval challenge.
> >
> > I'm glad to hear that I'm not the only person who's still trying to solve
> > Joel's challenge. It sounds like you've made some great progress!
>
> I'm intrigued too by Joel's challenge. This was the reason for I started my
> experiments with odometry months ago. The problem is always the same: much
> more projects in mind than time to carry them out :-)
>
> <snip!>
>
> > > The robot is a standard two-track design. It has two motors, each drives a
> > > track with a 1:3 gear reduction. It uses two rotation sensors as tachometers
> > > to maintain its heading. The rotation sensors are not connected to the • motors,
> > > but to two unpowered wheels. This way the rotation sensors still detect the
> > > actual movement of the robot even when the tracks are slipping. The wheels • are
> > > suspended in a way that maintains their contacts to the ground even on an
> > > uneven terrain.
> >
> > I had considered switching to a tracked design also, and thought of using this
> > approach of having non-driven encoder wheels in contact with the ground. I
> > had trouble getting the wheels to maintain solid contact so I put it on hold.
> > I was trying to spring-load my wheels to hold them on the ground, but it
> > sounds like you're having better luck just using old-fashioned gravity?
> >
> > Do you find that you are able to get fairly accurate odometry using this
> > approach? I think the entire Mindstorms community could benefit from somebody
> > figuring out how to track linear motion and turns reliably.
> >
> > My latest design uses a six-wheel drive setup with three wheels on each side
> > which are direct-geared to spin as one. I have found this to be much easier
> > to work with than the tractor treads so far, and it grips so well, I half
> > expect it to climb up a wall while I'm not looking! For now, my encoders are
> > driven directly off the wheels, but I plan to eventually incorporate some kind
> > of free-floating odometry wheels if I can get them to track properly.
>
> 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.
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. I think the same happens with differential drive (?).
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.
The resolution of the tachometer _is_ important, but also the speed at which the bot turns and stops (!). The CyberMaster tachometers have a resolution of about 50 ticks/360 degrees and I think it's enough (maybe too much?).
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.
Laurentino Martins
[ mailto:lau@mail.telepac.pt ]
[ http://www.terravista.pt/Enseada/2808/ ]
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message has 2 Replies:
 | | Re: odometry (was Re: Homing with the IR Tower)
|
| (...) 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 (...) (25 years ago, 28-Jul-99, to lugnet.robotics)
| | | Re: odometry (was Re: Homing with the IR Tower)
|
| At 09:20 28-07-1999 Wednesday , Mario Ferrari wrote: [snip] (...) I've downloaded, printed and read it all some time ago :-) (...) I've used 2 wheels instead of tracks once, and the results where terrible compared with tracks. The problem was that (...) (25 years ago, 28-Jul-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Homing with the IR Tower
|
| (...) I'm glad to hear that I'm not the only person who's still trying to solve Joel's challenge. It sounds like you've made some great progress! (...) Congratulations! Another Lego Fan is born! (...) Same here! <snip!> (...) I had considered (...) (25 years ago, 23-Jul-99, to lugnet.robotics)
|
23 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
