Subject:
|
Re: positioning of robot
|
Newsgroups:
|
lugnet.robotics.handyboard
|
Date:
|
Fri, 15 Aug 1997 16:25:15 GMT
|
Original-From:
|
Jeffrey Strauss Morehead <MOREHEAD@spamcakeECE.UTEXAS.EDU>
|
Viewed:
|
1283 times
|
| |
| |
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
On Fri, 15 Aug 1997, root wrote:
>
> > 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 is in Reply To:
| | Re: positioning of robot
|
| (...) Howdy- (...) No problem- as long as you get the relevant points across- that's what counts :) (...) 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 (...) (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
|
|
|
|