inside. However, the echo system will be an attempt to compensate both for
slippage, as well as for driving over such things as transition strips.
What I meant by motor speed input is that the speed input will be a range of
about 25 in my case, which is a manageable number. Therefore, I can time
true speed at different settings to come up with a speed curve. If this is
done with some care, and with multiple repetitions, the error in this should
be acceptable. Heck, it HAS to be acceptable. The echo locator, which is a
pair or SRF08 sonar sensors, will be taking a reading every 2s, and
comparing sequential readings off of the closest five items. The error on
the SRF08 between sequential reads seems tolerable enough that this kind of
triangulation will allow me to detect signficant slippage, and the dead
reckoning module is designed to be able to adjust its calculations on the
fly.
If that doesn't work, a magnetic leaf switch could be used to measure
rotations on the wheel, but I'll see whether or not I need to, first.
Brian Lloyd-6 wrote:
>
>
> On Mar 8, 2008, at 12:28 PM, Shaggy wrote:
>
>> I also heard that in other peoples experience, wheel slippage will
>> cause
>> sufficient errors that simply counting wheel revolutions is a dubious
>> measure to begin with. My alternatives seem to be these:
>>
>> 1) Possibly use oCounterH to count a single wheel speed (only 1 IO
>> line for
>> this object).
>> 2) Just measure true ground speed the old fashioned way and make up
>> a speed
>> curve based on the set motor speed.
>>
>> Frankly, unless there is something I have missed, I'm inclined to
>> just use
>> option 2, since I have already implemented code that will be
>> checking the
>> dead reckoning position against sonar echoes. Is there anything else
>> I might
>> consider?
>
> Using the encoder on a driven wheel will be inaccurate due to wheel
> slippage as you have suggested. This is more of a problem on loose
> ground. You can get better accuracy by putting an encoder on a non-
> driven wheel (odometer).
>
> Unless you always run on flat ground and unless your motors have
> massive extra torque, just looking at motor speed input isn't going to
> be very accurate either. How much accuracy do you need and what are
> you willing to pay for it? If you want to go nuts you can add an
> inertial reference but that is probably overkill for most applications.
>
> --
>
> Brian Lloyd Granite Bay Montessori
> brian AT gbmontessori DOT com 9330 Sierra College Blvd.
> +1.916.367.2131 (voice) Roseville, CA 95661, USA
>
http://www.gbmontessori.com
>
> I fly because it releases my mind from the tyranny of petty things . . .
> — Antoine de Saint-Exupéry
>
> PGP key ID: 12095C52A32A1B6C
> PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
--
View this message in context: http://www.nabble.com/Quadrature-Encoder-tp13322047p15921198.html
Sent from the OOPic mailing list archive at Nabble.com.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/oopic/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/oopic/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:oopic-digest@yahoogroups.com
mailto:oopic-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
oopic-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
No comments:
Post a Comment