Subject:
|
RE: Precise turns of any angle! -- Rotation Sensor Information
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 12 Jan 2002 07:59:27 GMT
|
Original-From:
|
Dick Swan <d.swan@att.net&AvoidSpam&>
|
Viewed:
|
4346 times
|
| |
|
|
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.
The rotation counter software is a combination of interrupt level firmware
and a base level task run by a "co-operative" non pre-emptive scheduler. It
works as follows:
1. The firmware samples, at interrupt level, the current raw value of the
rotation sensor every 3 milliseconds. The interrupt level then "schedules"
an internal sensor handler task to run at "base" (i.e. non-interrupt) level.
2. The base level scheduler cycles through the various tasks -- sensor
management, motor management, button/display handler and opcode interpreter,
... -- executing those waiting to run in a non-preemptive fashion. Each task
runs to completion and returns to the scheduler.
3. The base level handler for the rotation counter does the following:
o Converts raw sensor value to 1 of 4 positions [0..3]. From an old Dave
Baum post "The rotation sensor uses a quadrature encoder with a 1:4 gearing
between the axle and the encoder, so there are 16 'ticks' per revolution of
the axle. ... so with 16 ticks per revolution and 3ms per tick you get 1250
revolutions per minute."
o Compares last saved quadrant to current quadrant to see if there is any
change. If there is a change, converts to a +1 or -1 on the rotation counter
depending on the direction of the change. When the change is two quadrants,
e.g. 1 to 3, it is ignored. If the change is 3 quadrants -- e.g. quadrant 0
to 3 -- it will be interpreted as a 1 quadrant change in the opposite
direction.
There are several possible sources of error:
1. Within a 3 msec period, the rotation sensor changes by more than one
quadrant.
2. The RCX just happens to sample the rotation sensor during the instant
that it is changing quadrants and gets a spurious value. I'm not sure how
real this is, since I think the A to D sampling only takes 8 micro-seconds.
There are some old posts on this regarding a LEGOS debouncing algorithm --
look for two consecutive samples with same value -- but I'm not sure if this
is the current LEGOS implementation as this would halve the highest speed
that could be recorded.
3. The scheduler delay before the base level handler is run. I think this is
the biggest cause of any inaccuracy. My measurements indicate that this is
variable with typical values in the 1 - 5 millisecond range, but that it can
be up to 15 milliseconds! When one of these infrequent 15 msec delays
occurs, the rotation sensor will drop counts at any speed above 250 RPM!
I think the most time consuming base level task is the opcode interpreter.
It cycles through each of the ten possible tasks, looking for a running
task. It then executes a single opcode and returns.
I have measured the speed of the RIS 2.0 opcode interpreter and found a
single opcode typically take 3.5 millisecond to execute. ]. I did these
measurement by taking the difference in the elapsed time to execute two
different FOR loops 5,00 times. One loop was empty. The other had 20 opcodes
in it. Divide the time difference by 10,000 to get the time to execute a
single opcode. {By the way, this is significantly longer than the RIS 1.0
firmware where it was in the 1.0 to 1.5 millisecond range
In a second experiment, I found that there was quite a variation in the
scheduler response time. I sent hundreds of "is RCX alive" message from my
PC and measured the response time from when the last byte was sent by the PC
to the time the first reply byte was received. After adjusting for delays in
the infrared serial link, the times ranged from under a millisecond to about
15 milliseconds. There were no running tasks / programs on the RCX. I
suspect this delay is due to the "heavy duty" computing done every 10
milliseconds in the opcode handler to determine if any high level "events"
have happened. I have no way to confirm that this is the "culprit", and I
now realize that I could have measured the RIS 1.0 firmware, which doesn't
have the "event" capability, to see if it exhibited the same behavior to
confirm.
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.
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.
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.
This post was prompted by an earlier post from "Steve Baker"
<lego-robotics@crynwr.com> wrote in message
news:3C3FB9FE.35C9FC7@airmail.net...
>
> ...SNIP...
>
> The trouble is that the rotation sensor drops counts when you run it at • low speeds - especially if it's reversing direction frequently.
>
> You can read about my experiments that prove that fact here:
>
> http://www.sjbaker.org/steve/lego/rotation_sensor.html
>
> I'm told that you get much better results using LegOS - but I have not yet • tested that.
>
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Re: Precise turns of any angle!
|
| (...) The trouble is that the rotation sensor drops counts when you run it at low speeds - especially if it's reversing direction frequently. You can read about my experiments that prove that fact here: (URL) told that you get much better results (...) (23 years ago, 12-Jan-02, to lugnet.robotics)
|
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
|
|
|
|
