 | | | | | | |
| |
|
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/
| | | | | | | | | | | | | | | | |
| |
|
Juergen Stuber wrote:
> 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.
Excellent! Someone who *knows*!
> > 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 guess so. You kinda have to hope that Lego designed the sensor to
work when directly connected to a motor though - they surely imagine
that this will be the most common use for 'naive' users.
> > I believe the 1250 RPM figure...
>
> Yes, that's right for the LEGO firmware.
> For legOS/leJOS it's half that.
OK - that's good to know.
> > > 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.
I confess that seems reasonable to me. It's an interrupt driven thing, you'd
hope that they didn't slow the code down to the point where it misses interrupts
wouldn't you!
> > > 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.
Is there also an in-between reading for 0-->1 and 2-->3 ? If so,
you could perhaps use that to deduce when a miscount has occurred?
If you see (say) 0, 0.5, 1, 2, 3 then you know that the 2 was
the ghost because there would have been no 0.5 reading if the
sensor had been rotating in the opposite direction.
I guess this might entail the software switching into a different
mode for slow speed measurements.
> My experiments indicated a miscount for on the order of several
> thousand counts.
So that should be pretty much independent of speed (because the
probability of being in the 'bad' zone is the same irrespective
of motor speed) - but perhaps the integration time of the AtoD
hardware plays a part. At low speeds, I suppose the internal
contacts could be touching two pads at the same time - and
at higher speeds, the voltage could change partway through
the integration time - resulting in some kind of screwup.
However, this indicates that we should *expect* dropped counts
at all speeds.
My experiments clearly show that the number of dropped counts
varies dramatically with speed...and there are really must be
almost negligable (if not exactly zero) dropped counts in the
'sweet spot' between ~50 and 300 RPM.
I should update my web page to include your comments.
> > 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.
That's a very good thing. I don't see any need to count accurately
beyond the speed range of a standard Lego motor - so the 625 RPM
that LegOS is managing is plenty at the top end.
I wonder if we could get Lego to fix the standard firmware?
----------------------------- 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
| | | | | | | | | | | | | | | | | | | | | |
| |
|
lego-robotics@crynwr.com (Steve Baker) writes:
> Juergen Stuber wrote:
> >
> > 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.
>
> I confess that seems reasonable to me. It's an interrupt
> driven thing, you'd hope that they didn't slow the code
> down to the point where it misses interrupts wouldn't you!
Yes. Actually it's two step, the A/D interrupt sets a flag
and a routine in the firmware checks the flag periodically and
does the processing, most of it being calling the ROM routine.
> > > > 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.
>
> Is there also an in-between reading for 0-->1 and 2-->3 ?
No. You can read height in the diagram as voltage, and the
ROM decodes the raw value to these four states.
> If so,
> you could perhaps use that to deduce when a miscount has occurred?
>
> If you see (say) 0, 0.5, 1, 2, 3
No, there are just the four states, no 0.5.
You could look at the raw values, but I think that wouldn't help
much, just reduce the probability of a miscount somewhat.
> then you know that the 2 was
> the ghost because there would have been no 0.5 reading if the
> sensor had been rotating in the opposite direction.
Actually I thought about using longer sequences of states to
decide how to count, to keep the maximum speed. But that got
too complicated so I decide to do the double check on a value.
It would make an interesting computer science research problem
to find a method to do that and prove its correctness
(w.r.t. some limits on speed and acceleration).
> > My experiments indicated a miscount for on the order of several
> > thousand counts.
>
> So that should be pretty much independent of speed (because the
> probability of being in the 'bad' zone is the same irrespective
> of motor speed) - but perhaps the integration time of the AtoD
> hardware plays a part.
Yes. IIRC it's 100us of 3ms, so 1/300th.
Probably the window where you really get a wrong measurement
is about one order of magnitude smaller, otherwise wou would
get miscounts more frequently.
> At low speeds, I suppose the internal
> contacts could be touching two pads at the same time
No, I think the sensor itself is optical and will always
produce a proper value (no static intermediate value).
Only when the value changes at the wrong moment you get
a wrong measurement.
> - and at higher speeds, the voltage could change partway through
> the integration time - resulting in some kind of screwup.
That can also happen at slow speeds, though maybe less often.
> However, this indicates that we should *expect* dropped counts
> at all speeds.
>
> My experiments clearly show that the number of dropped counts
> varies dramatically with speed...and there are really must be
> almost negligable (if not exactly zero) dropped counts in the
> 'sweet spot' between ~50 and 300 RPM.
That's strange. For my experiments I put a rotation sensor
directly on a motor and almost always got miscounts.
Jürgen
--
Jürgen Stuber <stuber@loria.fr>
http://www.loria.fr/~stuber/
| | | | | | | | | | | | | | | | | | |
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 one, but everything seems glued and I fear to break it...
Philo
www.philohome.com
> 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.
| | | | | | | | | | | | | | | | | |
| |
|
> 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.
In 'The LEGO Lugger', previously posted at
http://www3.sympatico.ca/jdkalpin, the extended drive shafts for both sides
of a tracked vehicle, moving in opposite directions, are summed in a
differential with the difference (hopefully zero)fed to the rotation sensor.
Because the two motors are never the same there is always a very small
rotation, perhaps 0.2 rpm. At a count of '+2' the right motor is stopped
until the count drops to '1' and at '0' the left motor is stopped until the
count rises to '1'. The count is displayed on the RCX readout and the
vehicle is quite slow so you can watch it. A straight-line standard is the
joint in a tile floor.
My rotation sensor misses counts (and gains counts!) to the extent that I
cannot use it as a position sensor. This is probably not news to anyone.
The control system tracks beautifully but every three or four feet (of tile)
the count will drop to '0' or jump to '3'. Perhaps I can correct some of
this out by code that allows change of +/- 1 but filters out larger excursions.
My take on it is that the rotation counter is a good device when used within
its limitations and I should not expect it to be perfect. I believe I saw,
somewhere, a non-LEGO position sensor, a better bet for The LEGO Lugger.
Regards, Jerry
| | | | | | | | | | | | | | | | | |
| |
|
Jerry Kalpin wrote:
> In 'The LEGO Lugger', previously posted at
> http://www3.sympatico.ca/jdkalpin, the extended drive shafts for both sides
> of a tracked vehicle, moving in opposite directions, are summed in a
> differential with the difference (hopefully zero)fed to the rotation sensor.
> Because the two motors are never the same there is always a very small
> rotation, perhaps 0.2 rpm. At a count of '+2' the right motor is stopped
> until the count drops to '1' and at '0' the left motor is stopped until the
> count rises to '1'. The count is displayed on the RCX readout and the
> vehicle is quite slow so you can watch it. A straight-line standard is the
> joint in a tile floor.
I believe that in this case, you should use a light sensor looking at a wheel
that's white with a black line marked on it. The software for reading this
is identical to what you would use for line following (a very well researched
topic!) - all the problems of rotation sensors goes away.
> My take on it is that the rotation counter is a good device when used within
> its limitations and I should not expect it to be perfect.
Yes - although I think it's important to know precisely what those limitations
are.
----------------------------- 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
| | | | | | |
