Subject:
|
Re: Precise turns of any angle! -- Rotation Sensor Information
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 13 Jan 2002 19:52:21 GMT
|
Viewed:
|
4887 times
|
| |
|
|
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/
|
|
Message is in Reply To:
11 Messages in This Thread:
   
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
