To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.handyboardOpen lugnet.robotics.handyboard in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / Handy Board / 2616
2615  |  2617
Subject: 
Re: positioning of robot
Newsgroups: 
lugnet.robotics.handyboard
Date: 
Fri, 15 Aug 1997 12:08:17 GMT
Original-From: 
root <root@snotnose.wizard.SPAMLESSorg>
Viewed: 
1536 times
  
Hello,

Howdy-


First my apolgies for my bad english (my dutch is mutch better but =
afcouse thats becoust dutch is my first language).=20

No problem- as long as you get the relevant points across- that's what
counts :)


anyway. im working on a robot and use lego to test the best way for =
moving a robot. i see 3 options.. 2 weels, 4 weels (like a nomal car) =
and caterpilar. i wonder what your experiences are whit those technics. =

Ok- that's a very good basic question. Here are the pluses and minuses for
each type of drive system:

2 WHEELS:
The two wheel drive system on very small robots is often a very
simple and easy way to go. While there are a couple of "true" 2
wheel drive mechanisms available, most are really 2 drive wheels
with one or more 'castor wheel(s)' for additional stability. This
arrangement is great for a table-top robot, or a robot who's entire
existence will be spent on smooth, level surfaces. Its navigational
considerations are very similar to the 'treaded' mechanism and I'll
talk more about that in a moment.

4 WHEELS:
The four wheel (like a car) drive mechanism (regardless of whether
2 of the wheels are powered or all 4 of the wheels are powered) is
also relatively easy to construct and control. Its main advantage
is speed, particularly on smooth, level surfaces (like a car). It
can also accomodate more weight (usually) than a 2 Wheel design of
similar size and "durablity". If the wheel-base (the width between
the wheels) is wide and the center of gravity (where the 'center' of
the weight suspended by the wheels is) , then its basic handling
characteristics will be very good as well. If the wheel-base is also
tall (so that the chassis sits higher off the ground- as a side-note
this also shifts the vehicle's center of gravity higher which you
can compensate for by widening the wheel-base) then it will probably
have good ground 'clearance' meaning that it can move over rougher
terrain as well.

However, the 4 Wheel mechanism also has some disadvantages as well.
The biggest problem you will have using a 4 Wheel vehicle is in
navigation. A 4 Wheel vehicle has a minimum turning radius. It cannot
turn on its center like the 2 Wheel or Treaded vehicles can. So this
complicates your robot's job of maneuvering from one location to
another, particularly if the journey requires tight turns or narrow
spaces. Consider, if your robot's minimum turning radius is 'y'
(whatever 'y' is)- the NARROWEST SPACE your vehicle will be able to
TURN AROUND IN is 'y * 2' (the diameter of the circle with a radius
of 'y'). The value of 'y' is determined by the maximum angle of the
steering wheels. (The actual math is only slightly more complicated
as it also takes into account the length of the vehicle which actually
slightly lessens the space usually- but for our conceptual purposes
we'll ignore that for now).

This particular property of the 4 Wheel design means that you will
need a much more sophisticated algorithm (programming) to analyze,
compute, detect and correct your course. For example, at a minimum
your robot will need to know (presumably) how to do several things:
Go Foward, Go Forward Left, Go Forward Right, Go Reverse, Go Reverse
Left, Go Reverse Right, and Stop. You of course can improve this
as you like- but you will probably agree that a 4 Wheeled vehicle
would probably need to be able to do these things :)

In order to complete a turn in a space that is slightly narrower than
its minimum turning radius (remember I said the math for that allows
the space to be slightly narrower)- the robot will have to move [the
direction is irrelevant so we shall just pick one] forward and to the
right a little bit until it runs into [senses, or whatever] the wall.
Then it changes its direction of motion to reverse to the left until
it runs into the opposite wall. Then it repeats these two actions as
needed until the vehicle is turned around. The algorithm itself
notwithstanding, consider too the problem of keeping track of your
location while performing these maneuvers. Even the most sophisticated
mechanical sensing mechanisms have some degree of error. This error
will be compounded by the accumulated maneuvers. So when you're done
the likelihood of _actually_ being where you _think_ you are is
reduced! You can of course attempt to compensate for this by improving
your software, sensors, etc- but you will probably agree that this
just complicates the situation.

If the space is actually too narrow. The vehicle will not be able to
turn around at all. More programming will be needed to figure out when
all navigation options have expired and the vehicle should be declared
'stuck'. Of course this may not mean the vehicle is hopelessly stuck
however as if the vehicle is sufficiently constructed it may be
possible to simply "back-track" the way it came and get out of the
situation. But in any case, by now I am certain you can see some of
the problems that 4 Wheels can create. On the other hand, if your
application does not involve narrow spaces, or perhaps turning around
or provides some other means to accomplish these tasks then 4 Wheels
can often be your best approach. [One very creative design I saw
someplace or other was a 4 Wheeled vehicle that moved in the usual
manner until it came to a place it needed to turn around. Then it
lowered a "revolving plate" until it reached the ground and slightly
lifted the vehicle up off the ground and rotated it the required
amount and then retracted. It was very clever arrangement I thought].

Another problem that 4 Wheel vehicles have (which you probably will
not encounter unless your goal is to send vehicles across trenches-
like in World War I :) is that they can get easily 'stuck' crossing
a trench because if the trench is sufficiently wide, and particularly
if the sides slope at an angle greater than about 25-35 degrees
(which is common propery of many trenches I think) there reaches a
point where the vehicle will be 'stuck' in the trench as a cork is
stuck in a bottle, or a lid is stuck on a pan. In late WW-I and more
recently, the way around this was to design vehicles with more than
2 axles (4 wheels) and to mount them on suspended carriages ['bogies']
So that the vehicle had a much harder time getting 'corked' as it
were :)

Finally one more observation about 4 Wheel (or any wheel for that
matter) designs is that relatively speaking only a VERY TINY amount
of surface area of the wheel is actually touching the ground at any
particular moment. This has implications on traction, top-speed,
power-input/speed-output ratio, and handling (while steering for
instance). These implications in themselves are not necessarily good
or bad, they just characterize the nature of the design. Wheeled
vehicles have a very good power-in/speed-out ratio. There is very
little loss due to friction between the wheel and the ground. So
for certain types of applications this means that it will require
less power to move in general- or put another way, can move around
quite a bit longer than a similar design built using some other
mode of operation.


TREADED OR TRACKED DESIGNS:

This is the 'classic' all-terrain design to date. It is not an
accident that virtually every military in the world, rescue teams,
construction teams, etc use this design. It is rugged and it will
get you there! Its biggest virtues are simple navigation and control
mechanisms and incredible traction and terrain-covering ability. By
rotating one track forward while the other track rotates in reverse,
the vehicle can literally 'turn on a dime' (around its own axis).
This means that its minimum turning radius is approximately the length
of the vehicle itself (a line drawn across the vehicle in such a way
that no other line can be drawn longer- diagonally). This naturally
simplifies the programming (move left track forward/reverse, move
right track f/r- that's it :) Also positioning is greatly improved
as you will only be making a single measurement so any errors are
not compounded- they are only simple errors and much easier to
correct.

However, the treaded vehicle pays for this versatility by sacrificing
top-speed, power-in/speed-out ratio, complexity, and durability. The
biggest single disadvantage is that a large amount of the track's
surface-area is in contact with the ground at all times. This is of
course the source for its remarkable traction, but also the source
for its lack of speed- and most importantly robs power. A great deal
of power is lost due to friction between the track and the ground
(compared to a similar wheeled design).

The tread carriage assembly is usually a pretty complicated thing. I
referring mainly to the 'real world' examples (tanks, bulldozers, etc)
which have to work and exist in the real-world performing real-world
tasks facing real-world hazards. Their carriage assemblies must have
complex systems of shock-absorption, suspension, power-transfer, and
load-distribution. By contrast, a hobby robot (of the type generally
feasible given the average hobbyist's resources and talents) is a very
diluted design which skips these considerations entirely or at most
the bare minimum they can get away with. The difference between the
top mechanical designs and the hobby versions makes a big impact on
the factors I mentioned at the beginning of the previous paragraph.

I say this not to discourage you in pursuing a treaded design (in
fact, I advocate this type personally) but mainly to point out the
realities and limitations of this particular type of design. If the
mechanism is not well suspended, or the shock absorption system is
lacking (or not there!) or the load-point calculations are off (or
were never done), etc, etc, the resulting vehicle will have its
lifespan, range, power, speed, durability, handling, load-capacity,
etc affected significantly!

Then there is the problem of obtaining the actual tracks themselves.
This can be a huge problem, particularly on the hobby-scale. You
generally can't just go downtown to Uncle Bob's Used Tank Emporium
and buy them :) So some people use things like automotive belts (fan
belt, timing belt, etc). Some of the higher performance automotive
engines use timing belts with deep-cut grooves that can work well.
The grooves reduce the surface area of the track without adversely
impacting its load or handling characteristics so it ends up changing
the power-in/speed-out ratio in a nice way.

Suspension in a hobby vehicle can be as simple as a small springed
'bogie' assembly or even not there if you insist- but if its not,
your vehicle will wear out much sooner and its contents will get a
rougher ride. If you plan to do the usual things like motion sensing,
accelation or force monitoring, vision (TV camera or something),
etc- it could easily have a detrimental effect! The track assembly
will require at least one spring however to keep the track tight
(but not too tight) around the driving wheel(s). Without suspension
though, you're asking for trouble in my opinion.


and what way is best to make a robot that can move around in a way you =
can folow it whitin your computer program.

I would recommend using a microcontroller. Such as one based around the
Motorola 68HC11 for example. If your means are limited, you may consider the
PIC family of controllers. By attaching sensors of various types (light,
infrared proximity detection, wheel-shaft speed encoders, etc) to your
vehicle's frame, you can provide input to the controller about the state of
the vehicle at any given moment. By using this information, your program
can make decisions about what action (or sequence of actions) to perform
next. I personally am using a number of controllers (CPU's) in my robot.
Each one has a set of given tasks to control, or sensors to oversee- or
some general aspect of the robot's operation. Then I have a larger computer
(running Unix) which manages all the smaller computers and uses their
"condensed" reports to make decisions- kind of like a manager would in a
business endevour. This process is repeated continuously (of course) so that
your robot will be able to operate in its world in a continuous manner.



met vriendelijke groet.

Same to you! (whatever you said :)


Frank Gillebaard


Hope this helps!

John Whitten
brat@naxs.com



Message has 2 Replies:
  Re: positioning of robot
 
I think the Tyco ZIG ZAG makes a great platform. It is a treaded vehicle with a center motor/wheel set that moves it sideways. I haven't complete a robot with it yet but you may want to look into it. jm (...) (27 years ago, 15-Aug-97, to lugnet.robotics.handyboard)
  Re: positioning of robot
 
I missed the first posting, I liked the summary posted by John Whitten. Youcan take his posting one layer "up" to get at the abstractions if you want. These are: 1. Points of contact with the surface - More increases stability. 2. Drive Train (...) (27 years ago, 15-Aug-97, to lugnet.robotics.handyboard)

3 Messages in This Thread:


Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR