Subject:
|
Re: Precise turns of any angle! -- Rotation Sensor Information
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 12 Jan 2002 17:25:23 GMT
|
Original-From:
|
Steve Baker <sjbaker1@+saynotospam+airmail.net>
|
Reply-To:
|
sjbaker1@airmail%AntiSpam%.net
|
Viewed:
|
4191 times
|
| |
|
|
Dick Swan wrote:
> Steve Baker has done some wonderful experiments on the accuracy of the
> rotation sensor which can be read at the URL at the end of this message. I
> have a alternative explanation for the inaccuracy in the rotation sensor
> when used with the standard Lego firmware. My bold conclusion is that the
> maximum theoretical rate on the rotation sensor is not the previously
> reported 1250 RPM but more likely 250 RPM or less. Read on for more details.
I ran my rotation sensor in an experiment at nominal motor speeds of 300 rpm
and didn't lose a single count in over 10 minutes of testing.
I believe the 1250 RPM figure...although you may be right about it being
worse with the RIS 2.0 firmware.
> My conclusions are as follows:
> 1. The RIS 2.0 firmware is more likely to drop rotation sensor counts
> because it runs significantly slower than the RIS 1.0 firmware.
That's interesting. I don't recall which firmware was loaded when I ran my
tests.
> 2. The theory that rotation counter drops counts at both very low speeds and
> high speeds is probably wrong. I suggest that it is more likely that low
> speeds are very accurate, medium speeds is usually accurate and high speeds
> always drop counts.
It's not a theory. There is absolutely no doubt that it loses counts at low
speeds - just take an RCX, connect a rotation sensor to it with a 40t gear
wheel attached so you can spin the sensor with your fingers. Mark one point
on the gear so you know how much you've turned it. You can set the RCX to
display the sensor count on the LCD.
Now, start with the mark on the wheel at the top and just slowly turn the
wheel back and forth - you'll soon find that when you return the wheel to the
original position, the count is not zero as you would expect. The slower you
do it, the more errors you accumulate. This test will completely convince you,
theory or no theory.
I'm pretty sure that the cause in *this* case is that issue of what happens if
the sensor is between two positions for long enough to confuse the firmware.
At high speeds, it's certainly true that the interrupt rate of the scheduler
limits performance. That's entirely believable and quite acceptable. You
can almost always live with the sensor running no faster than the ~300RPM
of the modern Lego motor. However, the lossage at low speeds is a major
pain - making the sensor all but unusable in many of the applications where
it ought to be the perfect solution.
I generally resort to using a light sensor and an encoder wheel to deal with
low speed rotation sensing.
> 3. Because the inaccuracy is due to scheduler delay, if you're comparing the
> results of two concurrently running rotation counters, it's quite likely
> that they are both simultaneously dropping counts at the same time.
If you read my findings, you'll see that I thought of that and explicitly
tested for it.
> > You can read about my experiments that prove that fact here:
> >
> > http://www.sjbaker.org/steve/lego/rotation_sensor.html
----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net> WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
http://prettypoly.sf.net http://freeglut.sf.net
http://toobular.sf.net http://lodestone.sf.net
|
|
Message has 1 Reply:
Message is in Reply To:
11 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
|
|
|
|
