 | | | | | | |
| |
|
A while ago I was intrigued by the soda can retrieval challenge. Particularly
because at that time I had built two different designs of grip-and-lift claws:
The first is based on the bar-code truck claw. It uses the flex system and
lifts things overhead. Moreover I also add a shock absorber and an additional
touch sensor to its base, so it also acts as a bumper. The second claw is
based on that famous Recycler, but mine is driven directly by the motor and
involves no pneumatics.
Since then, however, the project has essentially stalled, for two reasons: 1)
On March 23 our son, Linus, was born; 2) I bought Mindstorms for robotics, but
then Mindstorms brought me out of my dark age, and now ironically I find
myself spending most of my precious spare time play Lego, not Mindstorms.
Still, I'd like to show you what little progress I have made, namely how the
robot finds its way home, after it locates and grabs the soda can.
In my plan, the IR tower sits in the center of the home base, surrounded by
floor marks of one to two feet in radius. The IR signal guides the robot to
the floor marks, then the robot can follow the floor marks to the exact point
to drop the can.
The IR tower is set to the far mode, while the RCX is set to the near mode.
There is a 8-stud-long hood on the IR unit of the RCX, to increase its
directionality.
Whenever the RCX receives a message from the IR tower (either
MSG_GOT_NOTHING=7 or MSG_GOT_PING=8), it replies with a message MSG_PING=5.
The IR tower sends out a MSG_GOT_PING message when it receives MSG_PING from
the RCX, otherwise the tower sends out MSG_GOT_NOTHING five times a second.
From the RCX's point of view, it either 0) receives nothing from the tower; 1)
receives MSG_GOT_NOTHING, indicating that the tower does not receive messages
from the RCX; or 2) receives MSG_GOT_PING, indicating that it has established
the two-way communication.
In this way, we get three levels of signal strength. The robot navigates by
heading toward the mid-point of the band of the strongest signal.
The robot is a standard two-track design. It has two motors, each drives a
track with a 1:3 gear reduction. It uses two rotation sensors as tachometers
to maintain its heading. The rotation sensors are not connected to the motors,
but to two unpowered wheels. This way the rotation sensors still detect the
actual movement of the robot even when the tracks are slipping. The wheels are
suspended in a way that maintains their contacts to the ground even on an
uneven terrain.
The IR tower is controlled by a small program running on PC. Since spirit.ocx
does not provide the API for sending/receiving RCX messages through the IR
tower, I have to resort to the low level serial protocol (as described in
<http://graphics.stanford.edu/~kekoa/rcx/#Protocol>) to send/receive the Set
Message opcode. The program is written in Objective Caml
(<http://caml.inria.fr/>).
In my room, the robot can always get itself within two feet of the IR tower,
often within one foot, _if_ it is not obstructed by some obstacles or mislead
into walls by reflected IR signals. I think the failures can be overcome by a
better avoidance algorithm.
I use the IR unit alone, with no additional sensors. It will be interesting to
compare it with the hybrid approaches, for example the one described in
<http://www.lugnet.com/robotics/?n=529>.
On benefit of using the IR unit instead of the light sensor is that the IR
unit detects only pulses of certain frequencies. This filters out most
background noises. However, the current firmware ignores messages with wrong
check sums. For navigation this is undesirable. (A wrong signal is better than
no signals at all.) We may get better results by switching to other firmware
such as LegOS so we can have direct control to the IR unit.
We can replace the IR tower with another RCX. The drawback is of course the
cost. The benefits include:
1) It can be programmed in the same language as the robot.
2) When the robot is locating the cans using the light sensor or Dennis
Clark's IRPD, a shining IR tower can bring unwanted interference. A RCX at the
home base can start pinging only after the can is located. (The robot sets
itself to the far mode, send messages to start pinging, then sets back to the
near mode.)
From here to a fully functional can-retriever, there are still issues to be
resolved. Here are a few of them:
1) Can detection. I have an interesting idea of detecting soda cans using
Dennis Clark's IRPD: The robot wanders around. When it detects something in
the IRPD, it does a bit of wall-following. (See my earlier post
<http://www.lugnet.com/robotics/?n=4527>.) From the readings of its two
tachometers, the robot can deduce the shape of the "wall". If the "wall" is a
cylinder with a diameter in a certain range, then it may be a can.
2) Number of sensors: Now we have two rotation sensors as tachometers, one
light sensor to detect the floor marks, and one IRPD to detect the soda
cans... Oops. None of these sensors can share the input port with each others.
I plan to connect the floor mark detector and the can detector to a 2-way
power splitter (See <http://www.lugnet.com/cad/dat/?n=141>.) Depending on the
claw position, only one of them is active. So IRPD is on when the robot is
seeking for cans with its claw down, and the light sensor is on when the robot
is bringing back the can with its claw up. (We may need additional touch
sensors for the operation of the claw, but these touch sensors can share ports
with the active sensors, in particular the robot does not move when it uses
its claw.)
3) Alternatives to RCX. Maybe we should switch to something with more input
ports. Maybe mini-board. If I use Cyber Master, I can free up the two ports
taken up by the tachometers, but then I cannot use the IR unit, the light
sensor, and IRPD. If I mount RCX on top of Cyber Master, how do I make them
communicate with each others? (See, I am trying to find excuses to justify
buying a set of Cyber Master.)
4) Bumper. Currently the robot has no bumpers. It uses the tachometers to
detect obstacles. (If the motors are running, but the tachometers do not
change, then the robots must have bumped into something.) This way an obstacle
is detected only after the robot has crashed into it, which makes me quite
uncomfortable. I may add bumper(s) into the design. It is a bit tricky to have
the bumper coexist with the claw.
2) The claw should not obstruct the IR unit. I may put the claw on the other
end of the robot.
The NQC source code for the RCX is included at the end of this message. The
binary executable for the PC is available upon request.
Cheers,
Hao-yang Wang
// Homer.nqc -- a robot that homes in the IR tower
// (c) 1999 Hao-yang Wang, hywang@pobox.com
// two rotation sensors connected to two wheels, acting as tachometers
#define IN_TACHO_LEFT IN_1
#define IN_TACHO_RIGHT IN_3
// The difference between the two tachometers indicate the heading of
// the robot.
#define CalcTachoDiff(var) \
{ var = IN_TACHO_RIGHT; \
var -= IN_TACHO_LEFT; \
}
// the tachometer difference that makes up a whole circle, and a bit more
#define WHOLE_CIRCLE_TACHO_DIFF \
( 16 * 24 /*distance between the two wheels*/ \
/ 3 /*wheel radius*/ \
+ 8 /*a little bit more*/)
// The task Ping puts the current signal level in sig_level .
// 0 means no messages from the IR tower; 1 means getting a MSG_GOT_NOTHING
// message from the tower, indicating that the tower does not get our
// ping-back; 2 means getting a MSG_GOT_PING message from the tower,
// indicating that the tower also gets our ping-back.
int sig_level;
// The task Ping also puts into the following two variables the robot heading
// when the last messages from the IR tower are received.
int level1_tacho_diff, level2_tacho_diff;
#define MSG_PING 5
#define MSG_GOT_NOTHING 7
#define MSG_GOT_PING 8
#define NOISE_THRESHOLD 2
#define MESSAGE_TIMER 0
#define PING_BACK_TIME 1
#define NACK_TIME 6
#define SIG_L0_NOTE 330
#define SIG_L1_NOTE 440
#define SIG_L2_NOTE 660
#define SIG_NOTE_DURATION 10
#define SetSigLevel(level) \
{ sig_level = level; \
\
if (level == 0) \
PlayNote(SIG_L0_NOTE, SIG_NOTE_DURATION); \
else if (level == 1) \
PlayNote(SIG_L1_NOTE, SIG_NOTE_DURATION); \
else \
PlayNote(SIG_L2_NOTE, SIG_NOTE_DURATION); \
}
task Ping
{ int nothing_count;
int cur_tacho_diff;
sig_level = 0;
IRMode(IR_LO);
while (true)
{ if (Message() == 0)
{ SetSigLevel(0);
wait (Message() != 0);
}
CalcTachoDiff(cur_tacho_diff);
if (Message() == MSG_GOT_PING)
{ level2_tacho_diff = cur_tacho_diff;
if (sig_level != 2)
SetSigLevel(2);
nothing_count = 0;
}
else if (Message() == MSG_GOT_NOTHING)
{ level1_tacho_diff = cur_tacho_diff;
if (sig_level < 1)
SetSigLevel(1);
nothing_count += 1;
}
ClearMessage();
ClearTimer(MESSAGE_TIMER);
SendMessage(MSG_PING);
if (sig_level > 1 && nothing_count >= NOISE_THRESHOLD - 1)
{ wait (Message() != 0 || Timer(MESSAGE_TIMER) >= PING_BACK_TIME);
if (Message() != MSG_GOT_PING)
SetSigLevel(1);
}
wait (Message() != 0 || Timer(MESSAGE_TIMER) >= NACK_TIME);
}
}
// two motors, each powers a track
#define OUT_LEFT OUT_A
#define OUT_RIGHT OUT_C
#define SPEED OUT_FULL
#define BACKUP_SOUND 1
#define DEAD_SOUND 2
// These two variables keep track of the power of the motors.
int speed_left, speed_right;
#define LeftFwd(speed) { Rev(OUT_LEFT, speed); speed_left = (speed) + 1; }
#define LeftRev(speed) { Fwd(OUT_LEFT, speed); speed_left = -(speed) - 1; }
#define RightFwd(speed) { Rev(OUT_RIGHT, speed); speed_right = (speed) + 1; }
#define RightRev(speed) { Fwd(OUT_RIGHT, speed); speed_right = -(speed) - 1; }
inline LeftOff { speed_left = 0; Off (OUT_LEFT); }
inline LeftFloat { speed_left = 0; Float(OUT_LEFT); }
inline RightOff { speed_right = 0; Off (OUT_RIGHT); }
inline RightFloat { speed_right = 0; Float(OUT_RIGHT); }
inline GiveUp
{ Off(OUT_A+OUT_B+OUT_C);
PlaySound(DEAD_SOUND);
IRMode(IR_HI);
StopAllTasks();
}
int tacho_diff, new_tacho_diff;
// When the robot has turned around a circle (starting from tacho_diff)
// without detecting any changes in sig_level, it gives up. In a real
// application it should instead wander to a different location and
// try again.
sub TurnAroundCheck
{
CalcTachoDiff(new_tacho_diff);
new_tacho_diff -= tacho_diff;
if ( new_tacho_diff >= WHOLE_CIRCLE_TACHO_DIFF
|| new_tacho_diff <= -WHOLE_CIRCLE_TACHO_DIFF)
GiveUp();
}
// This task walks the robot: It wanders around, searches for the soda can,
// then bring the can back home. Currently it does only the homing part.
task HaveFun
{
int prev_level, cur_level;
// We have to copy sig_level into cur_level, because sig_level may be
// changed by task Ping any time.
while (true)
{ LeftRev(SPEED);
RightFwd(SPEED);
cur_level = sig_level;
CalcTachoDiff(tacho_diff);
do
{ TurnAroundCheck();
prev_level = cur_level;
cur_level = sig_level;
}
while (prev_level >= cur_level);
do
{ if (prev_level < cur_level)
{ if (cur_level == 1)
tacho_diff = level1_tacho_diff;
else
tacho_diff = level2_tacho_diff;
prev_level = cur_level;
}
TurnAroundCheck();
cur_level = sig_level;
}
while (prev_level <= cur_level);
if (prev_level == 1)
new_tacho_diff = level1_tacho_diff;
else
new_tacho_diff = level2_tacho_diff;
LeftFwd(SPEED);
RightRev(SPEED);
tacho_diff += new_tacho_diff; // Head toward the mid-point.
tacho_diff /= 2; //
// See? We don't care whether the robot is left- or right-handed.
CalcTachoDiff(new_tacho_diff);
if (new_tacho_diff > tacho_diff)
do
{ CalcTachoDiff(new_tacho_diff);
}
while (new_tacho_diff > tacho_diff);
else
while (new_tacho_diff < tacho_diff);
{ CalcTachoDiff(new_tacho_diff);
}
RightFwd(SPEED);
cur_level = sig_level;
if (cur_level > 0)
do
{ prev_level = cur_level;
cur_level = sig_level;
}
while (cur_level >= prev_level);
}
}
#define STUCK_TIMER 1
#define STUCK_WAIT_TIME 4
#define BACKUP_TIME 20
task main
{ int tacho_left, tacho_right;
Sensor(IN_TACHO_LEFT, IN_ANGLE);
Sensor(IN_TACHO_RIGHT, IN_ANGLE);
start Ping;
start HaveFun;
while (true)
{ ClearTimer(STUCK_TIMER);
tacho_left = IN_TACHO_LEFT;
tacho_right = IN_TACHO_RIGHT;
while ( tacho_left == IN_TACHO_LEFT
&& tacho_right == IN_TACHO_RIGHT
&& (speed_left != 0 || speed_right != 0))
if (Timer(STUCK_TIMER) >= STUCK_WAIT_TIME)
{ // The tachometers do not change, while the motors are
// running. The robot must have bumped into something:
// Back up.
stop HaveFun;
// This piece of code needs some improvements: First, it is
// time-based: We should get rid of BACKUP_TIME, and use
// the tachometers to determine whether the robot has backed
// up far enough. Second, it simply reverse the directions of
// the motors: The robot may bumps into the same spot again.
// Often a wall reflects the IR signal and misleads the robot
// to bump into it. We'd better move the robot way from
// the wall before we start HaveFun again.
ClearTimer(STUCK_TIMER);
Toggle(OUT_LEFT+OUT_RIGHT);
speed_left *= -1;
speed_right *= -1;
PlaySound(BACKUP_SOUND);
while ( tacho_left == IN_TACHO_LEFT
&& tacho_right == IN_TACHO_RIGHT)
if (Timer(STUCK_TIMER) >= STUCK_WAIT_TIME)
{ // Still not moving: Give up.
GiveUp();
}
wait (Timer(STUCK_TIMER) >= BACKUP_TIME);
start HaveFun;
break;
}
}
}
| | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Hao-yang Wang writes:
> A while ago I was intrigued by the soda can retrieval challenge.
I'm glad to hear that I'm not the only person who's still trying to solve
Joel's challenge. It sounds like you've made some great progress!
> Since then, however, the project has essentially stalled, for two reasons: 1)
> On March 23 our son, Linus, was born;
Congratulations! Another Lego Fan is born!
> 2) I bought Mindstorms for robotics, but
> then Mindstorms brought me out of my dark age, and now ironically I find
> myself spending most of my precious spare time play Lego, not Mindstorms.
Same here!
<snip!>
> The robot is a standard two-track design. It has two motors, each drives a
> track with a 1:3 gear reduction. It uses two rotation sensors as tachometers
> to maintain its heading. The rotation sensors are not connected to the motors,
> but to two unpowered wheels. This way the rotation sensors still detect the
> actual movement of the robot even when the tracks are slipping. The wheels are
> suspended in a way that maintains their contacts to the ground even on an
> uneven terrain.
I had considered switching to a tracked design also, and thought of using this
approach of having non-driven encoder wheels in contact with the ground. I
had trouble getting the wheels to maintain solid contact so I put it on hold.
I was trying to spring-load my wheels to hold them on the ground, but it
sounds like you're having better luck just using old-fashioned gravity?
Do you find that you are able to get fairly accurate odometry using this
approach? I think the entire Mindstorms community could benefit from somebody
figuring out how to track linear motion and turns reliably.
My latest design uses a six-wheel drive setup with three wheels on each side
which are direct-geared to spin as one. I have found this to be much easier
to work with than the tractor treads so far, and it grips so well, I half
expect it to climb up a wall while I'm not looking! For now, my encoders are
driven directly off the wheels, but I plan to eventually incorporate some kind
of free-floating odometry wheels if I can get them to track properly.
> 1) Can detection. I have an interesting idea of detecting soda cans using
> Dennis Clark's IRPD: The robot wanders around. When it detects something in
> the IRPD, it does a bit of wall-following. (See my earlier post
> <http://www.lugnet.com/robotics/?n=4527>.) From the readings of its two
> tachometers, the robot can deduce the shape of the "wall". If the "wall" is a
> cylinder with a diameter in a certain range, then it may be a can.
This is similar to my latest approach. I'm using an IR-radar "ping" to locate
the can. When I'm close to (and directly facing) an object, I turn a few
degrees left and right, comparing the ping values to either side of the peak
reading. I'm still trying to tune the heuristic, but the idea is that if the
ping is much lower on _both_ sides, it's probably a can. If _either_ reading
is comparable in magnitude to the center peak, it's probably a wall. (Since
my odometry isn't anywhere near perfect yet, I'm trying to minimize any
movement during this process.)
> 2) Number of sensors: Now we have two rotation sensors as tachometers, one
> light sensor to detect the floor marks, and one IRPD to detect the soda
> cans... Oops. None of these sensors can share the input port with each others.
> I plan to connect the floor mark detector and the can detector to a 2-way
> power splitter (See <http://www.lugnet.com/cad/dat/?n=141>.) Depending on the
> claw position, only one of them is active. So IRPD is on when the robot is
> seeking for cans with its claw down, and the light sensor is on when the robot
> is bringing back the can with its claw up. (We may need additional touch
> sensors for the operation of the claw, but these touch sensors can share ports
> with the active sensors, in particular the robot does not move when it uses
> its claw.)
>
> 3) Alternatives to RCX. Maybe we should switch to something with more input
> ports. Maybe mini-board. If I use Cyber Master, I can free up the two ports
> taken up by the tachometers, but then I cannot use the IR unit, the light
> sensor, and IRPD. If I mount RCX on top of Cyber Master, how do I make them
> communicate with each others? (See, I am trying to find excuses to justify
> buying a set of Cyber Master.)
One theory I've heard on this forum (I never heard how well it worked...
anyone?) is to connect a motor output (from the RCX) up to a sensor input (on
the CyberMaster) and then reading the ON/OFF state of the motor as if it were
a simple touch sensor. It sounds like you don't have any spare motor outputs
on the RCX, but maybe you will if you can delegate some motor control to the
CyberMaster? It would still be pretty tough to use this for any real robust
communication between the two devices, but you might be able to get this
working. Just be careful not to burn up your RCX and/or CyberMaster!
> 4) Bumper. Currently the robot has no bumpers. It uses the tachometers to
> detect obstacles. (If the motors are running, but the tachometers do not
> change, then the robots must have bumped into something.) This way an obstacle
> is detected only after the robot has crashed into it, which makes me quite
> uncomfortable. I may add bumper(s) into the design. It is a bit tricky to have
> the bumper coexist with the claw.
I didn't rely on bumpers in my design because I am working with empty soda
cans. The can would get plowed over long before the sensor got tripped. So I
use IR-radar for all obstacle detection / avoidance. This assumes that the IR
transmitter and the light sensor are on the front of the robot as it moves
forward.
> 2) The claw should not obstruct the IR unit. I may put the claw on the other
> end of the robot.
I had this problem as well. In my design, the arm must be raised out of the
way before the IR has an unobstructed forward view. For me, this is not a
problem because I only lower the arm when I've found a can, and only for long
enough to pick the can up and out of the way again. Because of the arm
geometry, this requires a small amount of blind navigation, but it works OK as
long as the distances are fairly short.
Good luck with your project!
- Chris.
| | | | | | | | | | | | | | | | | | |
| |
|
> I had considered switching to a tracked design also, and thought of using this
> approach of having non-driven encoder wheels in contact with the ground. I
> had trouble getting the wheels to maintain solid contact so I put it on hold.
> I was trying to spring-load my wheels to hold them on the ground, but it
> sounds like you're having better luck just using old-fashioned gravity?
>
> Do you find that you are able to get fairly accurate odometry using this
> approach? I think the entire Mindstorms community could benefit from somebody
> figuring out how to track linear motion and turns reliably.
So far I have been using the tachometers mainly to find the mid-point of the
signal band, so they don't have to be too accurate. The need of accuracy will
arise when I use them for soda can detection. Let's see.
I have posted my current design on lugnet
<http://www.lugnet.com/cad/dat/ideas/?n=21>. Tell me what you think about it.
> My latest design uses a six-wheel drive setup with three wheels on each side
> which are direct-geared to spin as one. I have found this to be much easier
> to work with than the tractor treads so far, and it grips so well, I half
> expect it to climb up a wall while I'm not looking!
Funny I tried this approach before. My problem is that when the robot turns,
the tyres are kind of reluctant to go sideways. I think it depends on the kind
of tyres you use. Which kind of tyres are you using?
Cheers,
Hao-yang Wang
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Hao-yang Wang writes:
> > My latest design uses a six-wheel drive setup with three wheels on each side
> > which are direct-geared to spin as one. I have found this to be much easier
> > to work with than the tractor treads so far, and it grips so well, I half
> > expect it to climb up a wall while I'm not looking!
>
> Funny I tried this approach before. My problem is that when the robot turns,
> the tyres are kind of reluctant to go sideways. I think it depends on the kind
> of tyres you use. Which kind of tyres are you using?
I am using the small "balloon tires" that are marked "43.2 x 28 S", and which,
I believe are the ones used in all of the Mars Rover designs. These tires have
nice, rounded edges that seem to make them slide sideways a bit easier than the
larger tires that have square corners. I don't have a digital camera or a
scanner so I can't post any pictures yet, but here's the basic idea: I'm using
three wheels and five 24-tooth gears on each side of the platform. The
24-tooth gears are mounted in a row, and the wheels are connected to the 1st,
3rd, and 5th gear axles. I have one motor on each side with a 16-tooth gear
directly meshing with any one of the five 24-tooth gears to drive all three
wheels together. The front and back axles pass through the farthest-separated
holes in a 14-stud Technics beam.
The base platform is built up out of Technics beams that are "bolted" together
using 2 or 3-stud friction pins, resulting in a flat platform that is 16 studs
wide. The drive gears rise slightly above (and below) this platform, leaving a
10-stud wide flat area in between which is ideal for mounting the RCX and the
two drive motors.
The "corner" wheels definitely have a little bit of sideways drag when turning,
but I've found that this design turns in a very nice in-place circle even
though my motors are not perfectly matched in terms of RPM or power. The
corner wheels tend to work their way loose from the axles over time unless you
put collars on like hub-caps to increase their holding force. (Hint: Instead
of using a single 1-stud collar, use a pair of 1/2 stud pulleys; they have
better holding power than a single part.)
As I said in my previous post, I am currently running the encoders directly off
of the drive gears. I expect that this will introduce errors when turning,
since there is likely to be some wheel slippage in a turn. But I'm hoping that
perhaps the middle wheel on each side will not slip much, being
somewhat balanced by the opposing slippage of its two neighbors. My current
prototype has the encoders driven off of an 8-tooth gear in direct contact with
the top of one of the drive gears.
All told, this is by far the most stable robotic platform I've built in the few
months since I came out of my dark ages. It has much better traction and less
vibration than any of my other designs. The lack of traction and the wheel
slippage caused when a platform "hops" during a sudden maneuver have been the
worst navigational challenges that I've encountered so far, and this design is
my best attempt yet to minimize these effects.
| | | | | | | | | | | | | | | | | | | |
At 03:32 24-07-1999 Saturday , you wrote:
> Funny I tried this approach before. My problem is that when the robot turns,
> the tyres are kind of reluctant to go sideways. I think it depends on the kind
> of tyres you use. Which kind of tyres are you using?
All you need is to put a differential between the wheels.
If those wheels need to have traction, all you have to do is to apply the force to the differential itself and the differential will distribute the traction for the two wheels like a real car.
Laurentino Martins
[ mailto:lau@mail.telepac.pt ]
[ http://www.terravista.pt/Enseada/2808/ ]
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | | | | | |
> All you need is to put a differential between the wheels.
>
> If those wheels need to have traction, all you have to do is to apply the
> force to the differential itself and the differential will distribute the
> traction for the two wheels like a real car.
Maybe I did not phrase my problem clearly. It's better described in Jon
Shemitz's recent post <http://www.lugnet.com/robotics/?n=5804>.
In my experience, wheels are more efficient than treads. Under the same load,
my wheel-based design outrun my tread-based design. However, without a
steering mechanism, the "corner" wheels will produce significant sideway drag
while the robot is turning in place. How does a differential gear solve this
problem?
(This problem does not occur on the two- or three-wheel designs. However,
these designs are usually not very stable.)
Cheers,
Hao-yang Wang
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
At 20:45 26-07-1999 Monday , you wrote:
> > All you need is to put a differential between the wheels.
> >
> > If those wheels need to have traction, all you have to do is to apply the
> > force to the differential itself and the differential will distribute the
> > traction for the two wheels like a real car.
>
> Maybe I did not phrase my problem clearly. It's better described in Jon
> Shemitz's recent post <http://www.lugnet.com/robotics/?n=5804>.
>
> In my experience, wheels are more efficient than treads. Under the same load,
> my wheel-based design outrun my tread-based design. However, without a
> steering mechanism, the "corner" wheels will produce significant sideway drag
> while the robot is turning in place. How does a differential gear solve this
> problem?
>
> (This problem does not occur on the two- or three-wheel designs. However,
> these designs are usually not very stable.)
Have you seen the mars rover turn?
If you have the parts for it, you could add a steering mechanism in the front wheels and another for the wheels in the back.
Humm... that should make an interesting mechanical project :-)
Laurentino Martins
[ mailto:lau@mail.telepac.pt ]
[ http://www.terravista.pt/Enseada/2808/ ]
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | | | | | | |
> Have you seen the mars rover turn?
> If you have the parts for it, you could add a steering mechanism in the front wheels and another for the wheels in the back.
> Humm... that should make an interesting mechanical project :-)
The little lift truck in the 8062 Universal set has the same steering
mechanism. Just use a standard steeing rack with the steering knuckles on
opposite sides of the wheel. Sorry for the inept description, my
lids are calling for dinner time..
Fred Glockner, can you do a better job describing this?
Cheers,
Ralph Hempel - P.Eng
--------------------------------------------------------
Check out pbFORTH for LEGO Mindstorms at:
<http://www.hempeldesigngroup.com/lego/pbFORTH>
--------------------------------------------------------
Reply to: rhempel at bmts dot com
--------------------------------------------------------
| | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Chris Phillips writes:
> In lugnet.robotics, Hao-yang Wang writes:
> > A while ago I was intrigued by the soda can retrieval challenge.
>
> I'm glad to hear that I'm not the only person who's still trying to solve
> Joel's challenge. It sounds like you've made some great progress!
I'm intrigued too by Joel's challenge. This was the reason for I started my
experiments with odometry months ago. The problem is always the same: much
more projects in mind than time to carry them out :-)
<snip!>
> > The robot is a standard two-track design. It has two motors, each drives a
> > track with a 1:3 gear reduction. It uses two rotation sensors as tachometers
> > to maintain its heading. The rotation sensors are not connected to the • motors,
> > but to two unpowered wheels. This way the rotation sensors still detect the
> > actual movement of the robot even when the tracks are slipping. The wheels • are
> > suspended in a way that maintains their contacts to the ground even on an
> > uneven terrain.
>
> I had considered switching to a tracked design also, and thought of using this
> approach of having non-driven encoder wheels in contact with the ground. I
> had trouble getting the wheels to maintain solid contact so I put it on hold.
> I was trying to spring-load my wheels to hold them on the ground, but it
> sounds like you're having better luck just using old-fashioned gravity?
>
> Do you find that you are able to get fairly accurate odometry using this
> approach? I think the entire Mindstorms community could benefit from somebody
> figuring out how to track linear motion and turns reliably.
>
> My latest design uses a six-wheel drive setup with three wheels on each side
> which are direct-geared to spin as one. I have found this to be much easier
> to work with than the tractor treads so far, and it grips so well, I half
> expect it to climb up a wall while I'm not looking! For now, my encoders are
> driven directly off the wheels, but I plan to eventually incorporate some kind
> of free-floating odometry wheels if I can get them to track properly.
I believe that tracks (or wheels coupled to behave like tracks) are a poor
choice to get good results from odometry. I mean, as this mechanical
arrangement relies on slippage to turn, it's unprecise for its own nature.
IMO a differential drive is much more suitable to get the best from odometry.
> > 1) Can detection. I have an interesting idea of detecting soda cans using
> > Dennis Clark's IRPD: The robot wanders around. When it detects something in
> > the IRPD, it does a bit of wall-following. (See my earlier post
> > <http://www.lugnet.com/robotics/?n=4527>.) From the readings of its two
> > tachometers, the robot can deduce the shape of the "wall". If the "wall" is a
> > cylinder with a diameter in a certain range, then it may be a can.
>
> This is similar to my latest approach. I'm using an IR-radar "ping" to locate
> the can. When I'm close to (and directly facing) an object, I turn a few
> degrees left and right, comparing the ping values to either side of the peak
> reading. I'm still trying to tune the heuristic, but the idea is that if the
> ping is much lower on _both_ sides, it's probably a can. If _either_ reading
> is comparable in magnitude to the center peak, it's probably a wall. (Since
> my odometry isn't anywhere near perfect yet, I'm trying to minimize any
> movement during this process.)
I have another idea about using the Dennis Clark's IRPD to detect cans: we can
turn it 90 degrees so the left and right detectors are on the same vertical
line and become "bottom" and "top" detectors. Placing the sensor at the proper
height on the bot, we should be able to tell if an obstacle is a wall (bottom
detection only) or a can (bottom and top detection at the same time).
Obviously I assume that the walls are higher than the cans :-)
Hope this may help your project. I'll start mine sooner or later :-)
Mario
http://www.geocities.com/~marioferrari
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
> I believe that tracks (or wheels coupled to behave like tracks) are a poor
> choice to get good results from odometry. I mean, as this mechanical
> arrangement relies on slippage to turn, it's unprecise for its own nature.
> IMO a differential drive is much more suitable to get the best from odometry.
My first thought: If you don't connect the tachometers directly to the tracks,
but to the separate, unpowered wheels, you don't have to care if the tracks
slip or not.
My second thought: When the robot turns, there is exactly one "fixed point"
(i.e., the point without slippage) on each of its tracks. Unless the
tachometer wheels are exactly on the same line as these two fixed points,
minor slippage on the tachometer wheels may still occur.
So yes, the differential drive with two driven wheels is more accurate than
tracks.
The problem is: It tilts easily when the claw lifts the can.
The robot goes out looking for cans, grabs one, then heads home. Hopefully, we
don't have to care whether it does its tasks in straight lines or not.
> I have another idea about using the Dennis Clark's IRPD to detect cans: we can
> turn it 90 degrees so the left and right detectors are on the same vertical
> line and become "bottom" and "top" detectors. Placing the sensor at the proper
> height on the bot, we should be able to tell if an obstacle is a wall (bottom
> detection only) or a can (bottom and top detection at the same time).
> Obviously I assume that the walls are higher than the cans :-)
One nice thing about IRPD is that you get two detectors in one input port.
> Hope this may help your project. I'll start mine sooner or later :-)
Thanks. Since the initial release of Mindstorms, the Recycler has been
pictured on the lid of the box. Isn't it a bit surprising that so much is
involved to make it actually working?
Cheers,
Hao-yang Wang
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Hao-yang Wang writes:
> [snip...]
>
> So yes, the differential drive with two driven wheels is more accurate than
> tracks.
>
> The problem is: It tilts easily when the claw lifts the can.
You can add more free wheels to make it very stable.
> The robot goes out looking for cans, grabs one, then heads home. Hopefully, we
> don't have to care whether it does its tasks in straight lines or not.
When I approached the Joel's challenge I was worried also about the time to
collect the cans. My idea was to develop a reliable navigation system to
minimize the time to find the cans. So I planned to use odometry to estimate
the position, going back home from time to time (or after having found a can)
to zero the accumulated errors.
Obviously the fact that the robot moves in stright lines is not relevant :-)
> > Hope this may help your project. I'll start mine sooner or later :-)
>
> Thanks. Since the initial release of Mindstorms, the Recycler has been
> pictured on the lid of the box. Isn't it a bit surprising that so much is
> involved to make it actually working?
What really makes this thing great is the incredible number of persons that,
directly or indirectly, contributed to this project. I'm glad and proud to
belong to this virtual community where ideas are shared just for the pleasure
of doing it.
Mario
http://www.geocities.com/~marioferrari
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Mario,
i am still intrigued by your creative response to posts. Good luck. & may
the force be w/u.
Michael Aaron
Mario Ferrari wrote:
> In lugnet.robotics, Chris Phillips writes:
> > In lugnet.robotics, Hao-yang Wang writes:
> > > A while ago I was intrigued by the soda can retrieval challenge.
> >
> > I'm glad to hear that I'm not the only person who's still trying to solve
> > Joel's challenge. It sounds like you've made some great progress!
>
> I'm intrigued too by Joel's challenge. This was the reason for I started my
> experiments with odometry months ago. The problem is always the same: much
> more projects in mind than time to carry them out :-)
>
> <snip!>
>
> > > The robot is a standard two-track design. It has two motors, each drives a
> > > track with a 1:3 gear reduction. It uses two rotation sensors as tachometers
> > > to maintain its heading. The rotation sensors are not connected to the • motors,
> > > but to two unpowered wheels. This way the rotation sensors still detect the
> > > actual movement of the robot even when the tracks are slipping. The wheels • are
> > > suspended in a way that maintains their contacts to the ground even on an
> > > uneven terrain.
> >
> > I had considered switching to a tracked design also, and thought of using this
> > approach of having non-driven encoder wheels in contact with the ground. I
> > had trouble getting the wheels to maintain solid contact so I put it on hold.
> > I was trying to spring-load my wheels to hold them on the ground, but it
> > sounds like you're having better luck just using old-fashioned gravity?
> >
> > Do you find that you are able to get fairly accurate odometry using this
> > approach? I think the entire Mindstorms community could benefit from somebody
> > figuring out how to track linear motion and turns reliably.
> >
> > My latest design uses a six-wheel drive setup with three wheels on each side
> > which are direct-geared to spin as one. I have found this to be much easier
> > to work with than the tractor treads so far, and it grips so well, I half
> > expect it to climb up a wall while I'm not looking! For now, my encoders are
> > driven directly off the wheels, but I plan to eventually incorporate some kind
> > of free-floating odometry wheels if I can get them to track properly.
>
> I believe that tracks (or wheels coupled to behave like tracks) are a poor
> choice to get good results from odometry. I mean, as this mechanical
> arrangement relies on slippage to turn, it's unprecise for its own nature.
> IMO a differential drive is much more suitable to get the best from odometry.
>
> > > 1) Can detection. I have an interesting idea of detecting soda cans using
> > > Dennis Clark's IRPD: The robot wanders around. When it detects something in
> > > the IRPD, it does a bit of wall-following. (See my earlier post
> > > <http://www.lugnet.com/robotics/?n=4527>.) From the readings of its two
> > > tachometers, the robot can deduce the shape of the "wall". If the "wall" is a
> > > cylinder with a diameter in a certain range, then it may be a can.
> >
> > This is similar to my latest approach. I'm using an IR-radar "ping" to locate
> > the can. When I'm close to (and directly facing) an object, I turn a few
> > degrees left and right, comparing the ping values to either side of the peak
> > reading. I'm still trying to tune the heuristic, but the idea is that if the
> > ping is much lower on _both_ sides, it's probably a can. If _either_ reading
> > is comparable in magnitude to the center peak, it's probably a wall. (Since
> > my odometry isn't anywhere near perfect yet, I'm trying to minimize any
> > movement during this process.)
>
> I have another idea about using the Dennis Clark's IRPD to detect cans: we can
> turn it 90 degrees so the left and right detectors are on the same vertical
> line and become "bottom" and "top" detectors. Placing the sensor at the proper
> height on the bot, we should be able to tell if an obstacle is a wall (bottom
> detection only) or a can (bottom and top detection at the same time).
> Obviously I assume that the walls are higher than the cans :-)
>
> Hope this may help your project. I'll start mine sooner or later :-)
>
> Mario
>
> http://www.geocities.com/~marioferrari
> --
> Did you check the web site first?: http://www.crynwr.com/lego-robotics
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | | | |
| |
|
At 14:51 27-07-1999 Tuesday , Mario Ferrari wrote:
> In lugnet.robotics, Chris Phillips writes:
> > In lugnet.robotics, Hao-yang Wang writes:
> > > A while ago I was intrigued by the soda can retrieval challenge.
> >
> > I'm glad to hear that I'm not the only person who's still trying to solve
> > Joel's challenge. It sounds like you've made some great progress!
>
> I'm intrigued too by Joel's challenge. This was the reason for I started my
> experiments with odometry months ago. The problem is always the same: much
> more projects in mind than time to carry them out :-)
>
> <snip!>
>
> > > The robot is a standard two-track design. It has two motors, each drives a
> > > track with a 1:3 gear reduction. It uses two rotation sensors as tachometers
> > > to maintain its heading. The rotation sensors are not connected to the • motors,
> > > but to two unpowered wheels. This way the rotation sensors still detect the
> > > actual movement of the robot even when the tracks are slipping. The wheels • are
> > > suspended in a way that maintains their contacts to the ground even on an
> > > uneven terrain.
> >
> > I had considered switching to a tracked design also, and thought of using this
> > approach of having non-driven encoder wheels in contact with the ground. I
> > had trouble getting the wheels to maintain solid contact so I put it on hold.
> > I was trying to spring-load my wheels to hold them on the ground, but it
> > sounds like you're having better luck just using old-fashioned gravity?
> >
> > Do you find that you are able to get fairly accurate odometry using this
> > approach? I think the entire Mindstorms community could benefit from somebody
> > figuring out how to track linear motion and turns reliably.
> >
> > My latest design uses a six-wheel drive setup with three wheels on each side
> > which are direct-geared to spin as one. I have found this to be much easier
> > to work with than the tractor treads so far, and it grips so well, I half
> > expect it to climb up a wall while I'm not looking! For now, my encoders are
> > driven directly off the wheels, but I plan to eventually incorporate some kind
> > of free-floating odometry wheels if I can get them to track properly.
>
> I believe that tracks (or wheels coupled to behave like tracks) are a poor
> choice to get good results from odometry. I mean, as this mechanical
> arrangement relies on slippage to turn, it's unprecise for its own nature.
> IMO a differential drive is much more suitable to get the best from odometry.
I've built a PC program for the CyberMaster that pools the integrated tachometers continuously and shows the trajectory of the bot in the PC screen.
It uses _tracks_, and I've found out that besides one of the tracks runs a bit better than the other (by hand), it has no real importance since the instructions to the bot are like: "Turn the left track 95 ticks". And since 95 ticks are always 95 ticks, the track always runs the same, no mater how difficult is for the motors to do it.
My conclusion is that identical tracks (left/right) have identical slippage _if_ the floor is identical below both the tracks and the bot has symmetrical shape and weight. I think the same happens with differential drive (?).
The biggest error with tracks happen when you change heading by turning one track while the other is stopped. Don't do this, always change heading by turning a track backwards and the other forward at the same time. That way the bot turns on it's axis and it's much more accurate.
The resolution of the tachometer _is_ important, but also the speed at which the bot turns and stops (!). The CyberMaster tachometers have a resolution of about 50 ticks/360 degrees and I think it's enough (maybe too much?).
Of course there are errors, and the worst part is that they accumulate over time. It's very difficult to see why they happen (believe me, I've tried), but that's one of the things I don't expect to correct because they seem inevitable due to the nature of the odometry.
If you are thinking in constructing a robot that uses only odometry to navigate, don't expect it to go far or for a long time without heading and distance errors.
Laurentino Martins
[ mailto:lau@mail.telepac.pt ]
[ http://www.terravista.pt/Enseada/2808/ ]
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, lego-robotics@crynwr.com (Laurentino Martins) writes:
> At 14:51 27-07-1999 Tuesday , Mario Ferrari wrote:
> > I believe that tracks (or wheels coupled to behave like tracks) are a poor
> > choice to get good results from odometry. I mean, as this mechanical
> > arrangement relies on slippage to turn, it's unprecise for its own nature.
> > IMO a differential drive is much more suitable to get the best from odometry.
>
> I've built a PC program for the CyberMaster that pools the integrated
> tachometers continuously and shows the trajectory of the bot in the PC
> screen.
> It uses _tracks_, and I've found out that besides one of the tracks runs a
> bit better than the other (by hand), it has no real importance since the
> instructions to the bot are like: "Turn the left track 95 ticks". And since
> 95 ticks are always 95 ticks, the track always runs the same, no mater how
> difficult is for the motors to do it.
Yes, 95 ticks are always 95 ticks, but the point is if your robot really *is*
in the position where it's expected to be on the floor. The main problem with
odometry, as you know well, is that errors accumulate very fast. The
unavoidable slippage of the tracks makes the things worse. From what I read so
far about detecting a robot position, tracks are the worst choice. See, for
example, the great "Where am I? Sensors and methods for Mobile Robot
Positioning" by J.Borenstein (freely available on the net but can't remember
where).
> My conclusion is that identical tracks (left/right) have identical slippage
> _if_ the floor is identical below both the tracks and the bot has symmetrical
> shape and weight.
True. But when dealing with odometry I still prefer to avoid slippage by
design instead of relying on *identical* slippage of the tracks.
> I think the same happens with differential drive (?).
In a good differential drive there is no significative slippage of the main
wheels.
> The biggest error with tracks happen when you change heading by turning one
> track while the other is stopped. Don't do this, always change heading by
> turning a track backwards and the other forward at the same time. That way
> the bot turns on it's axis and it's much more accurate.
I agree this helps a lot.
> Of course there are errors, and the worst part is that they accumulate over
> time. It's very difficult to see why they happen (believe me, I've tried),
> but that's one of the things I don't expect to correct because they seem
> inevitable due to the nature of the odometry.
> If you are thinking in constructing a robot that uses only odometry to
> navigate, don't expect it to go far or for a long time without heading and
> distance errors.
I did, I know the problems. Some months ago I posted a message about a robot
that used odometry to determine its heading and position. All the computations
were made inside the RCX, and for that reason I had to use legOS (I needed
32bit integers and arrays to interpolate the trig functions). I was glad with
the results: after a few meters of random, non orthogonal moves, the error in
the estimated position and heading was still below 2%. For longer range
navigation you need artificial landmarks to zero your errors from time to time
(loke tape on the floor or other signs).
BTW, I do love tracks and vehicle with tracks. Simply don't use them for
odometry :-)
Mario
http://www.geocities.com/~marioferrari
| | | | | | | | | | | | | | | | | | |
| |
|
At 09:20 28-07-1999 Wednesday , Mario Ferrari wrote:
[snip]
> Yes, 95 ticks are always 95 ticks, but the point is if your robot really *is*
> in the position where it's expected to be on the floor. The main problem with
> odometry, as you know well, is that errors accumulate very fast. The
> unavoidable slippage of the tracks makes the things worse. From what I read so
> far about detecting a robot position, tracks are the worst choice. See, for
> example, the great "Where am I? Sensors and methods for Mobile Robot
> Positioning" by J.Borenstein (freely available on the net but can't remember
> where).
I've downloaded, printed and read it all some time ago :-)
> > My conclusion is that identical tracks (left/right) have identical slippage
> > _if_ the floor is identical below both the tracks and the bot has symmetrical
> > shape and weight.
>
> True. But when dealing with odometry I still prefer to avoid slippage by
> design instead of relying on *identical* slippage of the tracks.
>
> > I think the same happens with differential drive (?).
>
> In a good differential drive there is no significative slippage of the main
> wheels.
I've used 2 wheels instead of tracks once, and the results where terrible compared with tracks.
The problem was that the wheels that come with the CyberMaster set are very deep like the F1 car wheels (they are the only ones I have). When doing tight turns they show a god mount of slippage.
But the worst problem was that the third wheel was a free wheel.
I would never guessed that, but it turned out that the "free wheel" is bad because it makes the whole vehicle very inaccurate.
The simple motion stopping the vehicle and reversing the engines, make the "free" wheel turn 180 degrees and because it's axis is off-center, it forced the vehicle slight changes of direction.
It was not good at anything, not even for straight paths because slight oscillations in the free wheel direction had a great impact on the direction of the vehicle.
Here's my free wheel:
vehicle
_________
#
OOOO #
OO OO #
O #####
OO OO
OOOO
I need to find a better design...
Laurentino Martins
[ mailto:lau@mail.telepac.pt ]
[ http://www.terravista.pt/Enseada/2808/ ]
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, lego-robotics@crynwr.com (Laurentino Martins) writes:
> I've used 2 wheels instead of tracks once, and the results where terrible
> compared with tracks.
> The problem was that the wheels that come with the CyberMaster set are very
> deep like the F1 car wheels (they are the only ones I have). When doing tight
> turns they show a god mount of slippage.
> But the worst problem was that the third wheel was a free wheel.
> I would never guessed that, but it turned out that the "free wheel" is bad
> because it makes the whole vehicle very inaccurate.
> The simple motion stopping the vehicle and reversing the engines, make the
> "free" wheel turn 180 degrees and because it's axis is off-center, it forced
> the vehicle slight changes of direction.
> It was not good at anything, not even for straight paths because slight
> oscillations in the free wheel direction had a great impact on the direction
> of the vehicle.
I see your point. Yes, F1 kind wheels are far from ideal to avoid slippage and
get accurate results. The larger but thinner spoked wheels that come with the
Minstorm RIS are quite better.
The free wheel(s) also must be light and thin and rotate very freely. In my
S10 differential drive platform I kept all the weight well balanced over the
two main wheels, with two back and front free wheels loaded with minimum
weight. Those free wheels were actually small pulleys (the kind with 6 holes
around) with the proper thin rubber tire on.
Mario
http://www.geocities.com/~marioferrari
| | | | | | | | | | | | | | | | | | | |
| |
|
On Wed, 28 Jul 1999, Laurentino Martins wrote:
> At 09:20 28-07-1999 Wednesday , Mario Ferrari wrote:
> [snip]
> > Yes, 95 ticks are always 95 ticks, but the point is if your robot really *is*
> > in the position where it's expected to be on the floor. The main problem with
> > odometry, as you know well, is that errors accumulate very fast. The
> > unavoidable slippage of the tracks makes the things worse. From what I read so
> > far about detecting a robot position, tracks are the worst choice. See, for
> > example, the great "Where am I? Sensors and methods for Mobile Robot
> > Positioning" by J.Borenstein (freely available on the net but can't remember
> > where).
>
>
> I've downloaded, printed and read it all some time ago :-)
Great source. Just found a source where Johann Borenstein discusses the
original 1966 paper and gives links for the full electronic version or a
CDROM or a book version. Here is the source:
http://www-personal.engin.umich.edu/~johannb/position.htm
Thanks for the pointer! Ralph M. Deal deal@kzoo.edu
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | | |
| |
|
I haven't done any 'bot yet but I have been thinking about this
problem. and here's the result:
it looks like the good free wheel should do its 'wheeling' equally
well in each direction. therefore it should be a ball. the design should
look like this:
@@
@ __ @
@ / \ @
@| |@
\__/
(you have to have non-proprotional font for this ascii art to make any
sense).
now rotate the picture about the vertical symetry axis and you have a
ball (\/|_ chars) and the 'holder' (@).
there should be something between the holder and the ball so that the
ball can rotate freely (few wheels would do the trick).
if did was not clear enough - it is something like a computer mouse
ball, only it is supported, not hanging (so it is where the mouse ball
is but it is of the same construction as trackball ball).
I do not have much experience with lego (only have mindstorm set and
haven't done much with it, mostly thought experiments so far).
what do you guys think? I haven't seen such a design yet - is there
anything similar out there? (I am talking lego realm, of course)
erik
Laurentino Martins wrote:
...
> It was not good at anything, not even for straight paths because slight oscillations in the free wheel direction had a great impact on the direction of the vehicle.
>
> Here's my free wheel:
>
> vehicle
> _________
> #
> OOOO #
> OO OO #
> O #####
> OO OO
> OOOO
>
>
> I need to find a better design...
| | | | | | | | | | | | | | | | | |
At 20:34 03-08-1999 Tuesday , Robert Munafo wrote:
> You'll have a very hard time making a ball-and-socket design bear a load and
> turn without lots of friction. Putting wheels between the ball and the socket
> just brings us back to the problem that we were trying to avoid by not having
> wheels.
>
> A much better solution that will definitely accomplish what you want is 1/3 of
> a Killough platform. This is a pair of balloon tires that are free to rotate on
> two axes (via a rotating mount) and geared to each other so that the primary
> axles of the two wheels are always at a right angle, but coplanar.
<snip>
Whoa! =:-o
That's what a call a DESIGN!
I'm almost burning a fuse trying to image one of those running, err... turning... whatever it does!
OK, what are good sources of baloon tires? (sets) :-)
Laurentino Martins
[ mailto:lau@mail.telepac.pt ]
[ http://www.terravista.pt/Enseada/2808/ ]
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | | | | |
Good balloon tires are available in two service packs:
Service pack 5283 (43.2 mm diameter)
Service pack 5282 (68.8 mm diameter) - these suckers are huge, but have
just the right shape.
Tilman
> OK, what are good sources of baloon tires? (sets) :-)
>
>
> Laurentino Martins
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | | | |
| |
|
You'll have a very hard time making a ball-and-socket design bear a load and
turn without lots of friction. Putting wheels between the ball and the socket
just brings us back to the problem that we were trying to avoid by not having
wheels.
A much better solution that will definitely accomplish what you want is 1/3 of
a Killough platform. This is a pair of balloon tires that are free to rotate on
two axes (via a rotating mount) and geared to each other so that the primary
axles of the two wheels are always at a right angle, but coplanar. Here are two
good pictures of the design:
http://www.net-info.com/~dcarlson/images/kmrp3.jpg
http://carol.wins.uva.nl/~leo/lego/killough.html
There are two balloon tires, and only one touches the ground. You'll have to
omit the motor in your model so the wheels turn freely on both axes.
I also want to point out that the full Killough platform with three pairs of
wheels is also rather nice for many other reasons, the main one being that you
can move in any direction without turning, or in fact you can turn while moving
without changing your direction of movement. This makes for much better
maneuverability and flexibility and is also pretty darn fun to watch. However,
it wouldn't be that great for odometry because it's difficult to travel in a
perfectly straight line.
- Robert Munafo
In lugnet.robotics, Erik Steffl writes:
> [...]
> it looks like the good free wheel should do its 'wheeling' equally
> well in each direction. therefore it should be a ball. the design should
> look like this:
> [...]
> there should be something between the holder and the ball so that the
> ball can rotate freely (few wheels would do the trick).
>
> if did was not clear enough - it is something like a computer mouse
> ball, only it is supported, not hanging (so it is where the mouse ball
> is but it is of the same construction as trackball ball).
> [...]
| | | | | | | | | | | | | | | | | |
| |
|
Here's a couple of short motion clips of the killough platform in motion. (about
1.4 MB each in mpg format)
I had been waiting to get a few really nice movies of this but a relative of mine
dropped by last weekend and shot these to show a
friend of his. If you have never seen one of these in motion you might find them
interesting.
Hope you enjoy them!
http://www.net-info.com/~dcarlson/klw1.mpg high resolution/shorter length
movie
http://www.net-info.com/~dcarlson/klw2.mpg low resolution/longer length movie
with several different motions
-- doug (who's wishing he had more time to work on this stuff)
Robert Munafo wrote:
> You'll have a very hard time making a ball-and-socket design bear a load and
> turn without lots of friction. Putting wheels between the ball and the socket
> just brings us back to the problem that we were trying to avoid by not having
> wheels.
>
> A much better solution that will definitely accomplish what you want is 1/3 of
> a Killough platform. This is a pair of balloon tires that are free to rotate on
> two axes (via a rotating mount) and geared to each other so that the primary
> axles of the two wheels are always at a right angle, but coplanar. Here are two
> good pictures of the design:
>
> http://www.net-info.com/~dcarlson/images/kmrp3.jpg
>
> http://carol.wins.uva.nl/~leo/lego/killough.html
>
> There are two balloon tires, and only one touches the ground. You'll have to
> omit the motor in your model so the wheels turn freely on both axes.
>
> I also want to point out that the full Killough platform with three pairs of
> wheels is also rather nice for many other reasons, the main one being that you
> can move in any direction without turning, or in fact you can turn while moving
> without changing your direction of movement. This makes for much better
> maneuverability and flexibility and is also pretty darn fun to watch. However,
> it wouldn't be that great for odometry because it's difficult to travel in a
> perfectly straight line.
>
> - Robert Munafo
>
> In lugnet.robotics, Erik Steffl writes:
> > [...]
> > it looks like the good free wheel should do its 'wheeling' equally
> > well in each direction. therefore it should be a ball. the design should
> > look like this:
> > [...]
> > there should be something between the holder and the ball so that the
> > ball can rotate freely (few wheels would do the trick).
> >
> > if did was not clear enough - it is something like a computer mouse
> > ball, only it is supported, not hanging (so it is where the mouse ball
> > is but it is of the same construction as trackball ball).
> > [...]
> --
> Did you check the web site first?: http://www.crynwr.com/lego-robotics
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
| | | | | | | | | | | | | | | | | |
| |
|
I was asked via E-mail where to get the balloon tyres. They are listed in the
Shop-at-Home catalog as item 5282:
http://www.lugnet.com/pause/search/?query=5282
I just ordered some from here in the United States and they were $6.00 per
package. Each package includes two tyres and two wheels (hubs) that the tyres
fit on.
If you just want to support weight with a free wheel (the original purpose I
was replying to) then one pair of these tyres is all you need.
Also, on the general topic of linear wheels, it isn't necessary to use balloon
tyres if you're willing to use more than two real wheels per linear wheel
structure. The idea is to make sure one wheel is touching the ground at all
times. If you use more wheels, each wheel can be thinner. Instead of two wheels
offset by 90 degrees, you can use three wheels offset by 60 degrees, four
wheels offset by 45 degrees, or five wheels offset by 36 degrees. All are easy
to accomplish with LEGO gears. There will always be a bit of up-and-down
variation as you go from one wheel to another but for most robotics
applications that should be acceptable.
More wheels is also the only way to make a linear wheel assembly with higher
clearance, for negotiating rough terrain. However, using more wheels also
causes more variation in wheelbase. Depending on which wheel is touching the
ground at any given moment, the point of contact moves which means the whole
structure has to be far away from your center of gravity or else the robot will
tip over. If you want to handle rough terrain you should probably be using tank
treads, an insect walker design (like
http://userpages.itis.com/jvwillou/legorob1.htm) or a fancy suspension like the
Mars rover (http://mars.jpl.nasa.gov/MPF/rovercom/images/sojrov2.jpg).
- Robert Munafo
LEGO: TC+++(8480) SW++ #+ S-- LS++ Hsp M+ A@ LM++ YB64m IC13
| | | | | | |
