Subject:
|
Re: Precise turns of any angle! -- Rotation Sensor Information
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 13 Jan 2002 11:14:10 GMT
|
Viewed:
|
6342 times
|
| |
|
|
Hi,
I did the rotation sensor fix for leJOS.
In the course of that I did a lot of tests and analysed
the ROM code, so I know a bit about this.
lego-robotics@crynwr.com (Steve Baker) writes:
>
> > 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.
You must have been very lucky.
> I believe the 1250 RPM figure...
Yes, that's right for the LEGO firmware.
For legOS/leJOS it's half that.
> 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.
That surprises me.
Most of the work is done in the ROM, but the ROM routine
has to be called within the 3ms until the next measurement.
It shouldn't be hard for the firmware to respect this deadline.
> > 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.
I don't think so.
The reason that count is lost is that the A/D conversion
happens just in the moment when the sensor switches between
two values, and you get neither of the two but the intermediate value
on the other side of the cycle:
3
/ \
2 (2)
| |
(1) 1
\ /
0
Say you go from 1 to 3 and measure the ghost 2 in between.
The ROM routine then doesn't change the count,
and it sets the state to 2. The end result is a miscount by two.
My experiments indicated a miscount for on the order of several
thousand counts.
> 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.
legOS and leJOS do a double measurement, which halves maximal speed
but practically eliminate the miscounts.
Jürgen
--
Jürgen Stuber <stuber@loria.fr>
http://www.loria.fr/~stuber/
|
|
Message has 3 Replies:
 | | Rotation Sensor Information
|
| I agree this is the heart of the problem... I made a small experiment and saw strange things on my scope. Has anyone already open a Lego rotation sensor ? I'd like to have a look to internal photographs and/or see a circuit diagram. I tried to open (...) (23 years ago, 13-Jan-02, to lugnet.robotics)
|
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
|
|
|
|
