Subject:
|
Re: Precise turns of any angle! -- Rotation Sensor Information
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 13 Jan 2002 15:56:37 GMT
|
Original-From:
|
Steve Baker <SJBAKER1@AIRMAIL.NETspamless>
|
Reply-To:
|
sjbaker1@airmail.*IHateSpam*net
|
Viewed:
|
4405 times
|
| |
|
|
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
|
|
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
|
|
|
|
