Subject:
|
Re: Rotational Sensor & Gearing Down
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 25 Jan 2001 19:36:04 GMT
|
Viewed:
|
2185 times
|
| |
|
|
Steve Baker wrote:
> Rebel Transcanner wrote:
> >
> > "Bob Fay" <rfay@we.mediaone.net> wrote in message
> > news:G7MKLo.2tB@lugnet.com...
> >
> > > Rotation sensors will lose counts randomly in spite of the firmware.
> >
> > I'll back that! It's totally hit-and-miss. I've done several tests on
> > different gearings (some running the thing off a micromotor...) and no
> > matter what, they *always* loose count. I'm really dissapointed with them,
> > and I've hardly used them for this exact reason. :(
>
> OK - time for the rigerous scientific approach here (well - OK - the
> half-assed semi-scientific Steve Baker method :-)...
>
> I'm typing this email as I run the tests...so right now, I don't know
> the answers...
>
> Test 1:
>
> Connect two rotation sensors to a motor, run for 10 seconds:
>
> Sensor 1 Sensor 2
> 792 792
> 790 790
> 788 788
> 784 784
>
> Well, at standard 'new Mindstorms' motor speeds, EITHER no counts
> were lost at all over four ten second runs *or* the lossage is in
> the system software and happens identically for both motors.
>
> Test 2:
>
> I did one ten minute run - and the two sensors returned identical
> counts at the end.
>
> Test 3:
>
> We can test for the theory that when the system firmware 'glitches',
> it always drops counts on BOTH sensors. If that were true then
> if I run two sensors at different speeds one will drop a different
> number of counts from the other.
>
> OK - so I'll change the setup so that one rotation sensor is
> on the motor shaft - and the other on another shaft that's
> geared down 5 times.
>
> Sensor 1 Sensor 2 Sensor2 * 5
> 778 156 780
> 774 155 775
> 772 154 770
> 771 154 770
>
> Yep - this is fine - since we are using integer math, sensor2 * 5
> is always within 5 of sensor1 - that's as good as it gets.
>
> Conclusion: At ~50 to ~300 RPM, we don't lose counts.
>
> Test 4:
>
> It's known that when the shaft speed is *too* high, the
> software will eventually lose counts for sure. So, let's
> speed up one shaft and keep the other at the 'known good'
> speed of the Lego motor.
>
> I'm swapping the gears to we are geared UP 5 times...
>
> Sensor 1 Sensor 2 Sensor2 / 5
> 752 2517 503
> 749 2494 498
> 749 2499 499
> 748 2480 496
>
> Woah!! BIG TIME Lossage. It's pretty clear that the rotation
> sensor doesn't work at 1,400 RPM without losing data.The
> good news is that it's pretty consistent in that is loses about
> one count in three. This would still be useful in some
> applications...but I don't recommend it.
>
> Test 5:
>
> So, I wonder about the slow speed lossage (which is a pretty well
> known 'phenomenon'), let's gear down by 25:1 and run again:
>
> Sensor 1 Sensor 2 Sensor2 * 25
> 790 32 800
> 785 32 800
> 784 29 725 <===== Oops!
> 779 31 775
>
> ...so yes - at SLOW speeds (say 12 RPM) we lost at least
> one count over ~40 seconds of testing.
>
> Conclusions:
> ~~~~~~~~~~~~
>
> You can run your sensors directly on the motor shafts of
> the standard Mindstorms motor - and you can run it 5x
> slower than that and still not lose counts. However, don't
> run 25x slower or 5x faster than the motor or you *WILL*
> lose counts.
>
> Try to stick to rates around 50 to 300 RPM - the range may
> be a little higher - but we know that <12 RPM or >1400 RPM
> are definitely bad news.
>
> Future Work:
> ~~~~~~~~~~~~
>
> Someone (not me!) should probably figure out a bunch of gear
> trains and motor loadings to check the actual limits - and
> run the tests over MUCH longer periods than 10 seconds.
>
> I also wonder if it's possible to make the thing lose more
> counts by giving the firmware more work to do. It I run
> 6 threads all doing lots of sensor and motor work - and run
> the light sensor at the same time - and play lots of beeps
> on the speaker...would that load the firmware down enough
> to make it drop counts at all speeds?
>
> I'd *hope* not. If I were designing the RCX, I'd make the
> rotation sensor generate high priority interrupts so that
> sensors would be accurate no matter what...but who knows?
>
> OK - so do we have any more long-established 'myths' to bust?
But I don't think you did what we reported IS the problem...
Did you run the motor FORWARD, then REVERSE so we can see the missing positions?
That's where the errors come in.
Dean
--
Coin-Op's For Sale!: http://www.akasa.bc.ca/tfm/coin-op.html
Dean's Lego Workshop: http://www.akasa.bc.ca/tfm/lego_wr.html
Vancouver Lego Club: http://www.akasa.bc.ca/vlc
|
|
Message is in Reply To:
 | | Re: Rotational Sensor & Gearing Down
|
| (...) OK - time for the rigerous scientific approach here (well - OK - the half-assed semi-scientific Steve Baker method :-)... I'm typing this email as I run the tests...so right now, I don't know the answers... Test 1: Connect two rotation sensors (...) (26 years ago, 24-Jan-01, to lugnet.robotics)
|
19 Messages in This Thread:
 
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
