 | | | | | | |
| |
|
About a year ago I was inspired by discussions about how to get an
RCX robot to make perfect 90 degree turns and also by an interest in
traversing mazes and collision avoidance. I had an idea to navigate and
turn using an approach similar to a blind person using a cane.
My early proto-type had long been dismantled and I wanted to complete
the project, so I recently created a new version and improved the NQC
program I had begun so long ago.
The robot has a top mounted cane which rotates 360 degrees and about
2.75" off the floor. The cane is on large 56 tooth turntable and linked
to a rotation sensor in a 7:1 gear ratio to increase the sensitivity of
the rotation sensor to 112 clicks per full rotation of the cane. The
turntable is mounted over the robot's center of rotation. The assembly
is driven via a motor and pulley setup, allowing the motor to run
continuously without fear of burning out when the cane is in contact
with an obstacle.
The basic theory of operation is that the rotation sensor tracks the
orientation of the cane and when the cane is in contact with an object
it stops rotating and we have a directional reference against which to
make course corrections.
One application of this is to make precise turns of any angle. If
the rotation sensor value reads X, the robot can pivot until the
rotation sensor reads X+Y, thus rotating an angle of (Y*360)/112. The
112 is a function of the gear ratio between the rotation sensor and the
cane, 16*7=112, making each click of the rotation sensor represent
360/112, about 3.214, degrees. For a 90 degree turn clockwise Y=28, and
for 90 degrees counter-clockwise Y=-28.
Another application of this is to follow a wall, even turning
corners. With the cane in contact with a wall and the robot in motion
the rotation sensor will read a constant value if the robot's course is
parallel to the wall. If the course is not parallel to the wall the
cane will rotate one direction or the other, giving feedback for
adjusting the course. The robot's task is to maintain the angle of the
cane at a particular value, and thus follow walls which turn sharply
away from its path or walls that turn at moderate angles into its path.
Some minor run-time calculations allow the robot to detect a nearby
wall, its distance and orientation relative to the wall, and choose the
particular rotation sensor value that will maintain the distance
required to sucessfully navigate sharp turns away from it's path.
The end of the cane includes a freely rotating wheel to prevent it
from catching on imperfections in the surface of the wall being followed
and to improve its ability to follow walls which turn moderately into
the path of the robot. The motor and pulley drive allow the cane to be
counter-rotated by the physical force of the wall on the tip of the
cane.
For walls which turn sharply into the robot's path the robot
incorporates a forward IR proximity sensor, in preference to a touch
sensor. When the IR proximity sensor detects a wall the robot turns and
reinitializes it's behavior.
The 3 main fatal error conditions that can occur are loss of contact
with the wall, the robot colliding with the corner of a wall which turns
sharply away from its path, or a wall turning too sharply into it's path
which the cane cannot follow and the IR proximity sensor does not
detect.
An idea I have not yet pursued is to have the robot use a portable
obstacle which can be set down as needed as a fixed point of reference
against which to make course corrections. Another variation on this
would be to have a center jack-stand to raise the robot up, then
pivot on the jack-stand the required angle before setting down again.
Pictures are at:
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=10218
Brian H. Nielsen
LUGNET Member #108
| | | | | | | | | | | | | | | |
| |
|
"Brian H. Nielsen" wrote:
> The robot has a top mounted cane which rotates 360 degrees and about
> 2.75" off the floor. The cane is on large 56 tooth turntable and linked
> to a rotation sensor in a 7:1 gear ratio to increase the sensitivity of
> the rotation sensor to 112 clicks per full rotation of the cane. The
> turntable is mounted over the robot's center of rotation. The assembly
> is driven via a motor and pulley setup, allowing the motor to run
> continuously without fear of burning out when the cane is in contact
> with an obstacle.
>
> The basic theory of operation is that the rotation sensor tracks the
> orientation of the cane and when the cane is in contact with an object
> it stops rotating and we have a directional reference against which to
> make course corrections.
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.
----------------------------- 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
| | | | | | | | | | | | | | | | | | |
| |
|
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.
>
| | | | | | | | | | | | | | | | | | | | | |
| |
|
Dick Swan wrote:
> 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.
I believe the 1250 RPM figure...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.
> 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.
It's not a theory. There is absolutely no doubt that it loses counts at low
speeds - just take an RCX, connect a rotation sensor to it with a 40t gear
wheel attached so you can spin the sensor with your fingers. Mark one point
on the gear so you know how much you've turned it. You can set the RCX to
display the sensor count on the LCD.
Now, start with the mark on the wheel at the top and just slowly turn the
wheel back and forth - you'll soon find that when you return the wheel to the
original position, the count is not zero as you would expect. The slower you
do it, the more errors you accumulate. This test will completely convince you,
theory or no theory.
I'm pretty sure that the cause in *this* case is that issue of what happens if
the sensor is between two positions for long enough to confuse the firmware.
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.
I generally resort to using a light sensor and an encoder wheel to deal with
low speed rotation sensing.
> 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.
If you read my findings, you'll see that I thought of that and explicitly
tested for it.
> > You can read about my experiments that prove that fact here:
> >
> > http://www.sjbaker.org/steve/lego/rotation_sensor.html
----------------------------- 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
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, sjbaker1@airmail.net writes:
> "Brian H. Nielsen" wrote:
>
> > The robot has a top mounted cane which rotates 360 degrees and about
> > 2.75" off the floor. The cane is on large 56 tooth turntable and linked
> > to a rotation sensor in a 7:1 gear ratio to increase the sensitivity of
> > the rotation sensor to 112 clicks per full rotation of the cane. The
> > turntable is mounted over the robot's center of rotation. The assembly
> > is driven via a motor and pulley setup, allowing the motor to run
> > continuously without fear of burning out when the cane is in contact
> > with an obstacle.
> >
> > The basic theory of operation is that the rotation sensor tracks the
> > orientation of the cane and when the cane is in contact with an object
> > it stops rotating and we have a directional reference against which to
> > make course corrections.
>
> 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've done your experiment and I won't dispute that the rotation sensor
drops counts. However, that only impacts the wall following application
only to the extent that it would require periodically going through the
initialization function which calculates the distance the robot currently is
from the wall.
The application of making precise turns is completely unaffected since it
doesn't matter what the current value "X" is to start a turn, only that we
pivot until the counter reads "X+Y". At pivot speeds the rotation counter
is turning neither too slow nor too fast.
Brian H. Nielsen
LUGNET Member #108
| | | | | | |
