(snip)
I think that the only place where BEAM robots will really shine are in
planned ecologies - not, by the way, something as random as today's
Jurassic Parks. The only one of these I've ever seen is made up of
two-wheel Unicore based robots ('cuz I've never seen the housecleaning
stuff -- the window cleaner has been broken for ever so long a time.)
Anyhow, on a tray less than a yard across with a dark end and a light
end, Tilden can put down these Unicore machines after twiddling their
parameters a bit along with dark and light foam disks and the robots
sort the disks according to color!! This synergistic effect comes about
only because there is a community of 'bots.
So, yeah, lots of people are going to jeer BEAM technology. Generally
speaking, they've only seen single examples of the most unsophisticated
types of BEAMbots. And it is true that these unsophisticated machines
really can't do much, that their true value is making robot design
accessible at a fairly low cost. Also, these people have never seen one
of the ecologies at work -- in fact, there AREN'T many of those
ecologies in existence. Until they see the educational value, until
they've seen some reasonably sophisticated ecologies they are going to
continue to scoff. If you wish to educate these people, write a calm
article in response to theirs -- it WILL make a difference.
So, be a dreamer. If you've made a photovore or walker, how little can
you add to it to make it do something moderately practical? How could
different castes of robots get a job done even when they don't
communicate with each other? How could one caste of robots do something
more efficiently just by being able to signal "I'm here!" where it
identifies itself uniquely - no complicated messages, just a simple
signal like an elephant trumpeting.
Dream big and build 'bots!
From:dbertram@andrew.cmu.edu Add to Address Book
Date:Sun, 02 Aug 1998 17:53:55 -0400
To:beam@palladium.corp.sgi.com
Subject:Photovore with crude memory system: B-memory.
Reply-To:dbertram@andrew.cmu.edu
I was brainstorming today while taking a nap. I wanted to try to come up
with a way to implement a basic memory system for a photovore. This is what
I came up with.
http://www.geocities.com/Paris/Lights/1267/Robots/se.gif
I've spared everyone from e-mailing the picture to the entire list. SO check
it out. I don't have any explination, but the picture itself should be
rather self explanitory. Anyway, I will give a brief explination: the Main
cap, C1a and C1b charge and run the Photovore as usual. When the photovore
hits an object one cap half discharges and half charges the other cap, while
the bot is sitting there 'waiting' for the other side to 'unstick' itself
both caps C1a and C2a are chargeing. Eventaually C2a is at a resonably high
charge level, so that when the bot encounters an object instead of just
sitting there, and having the Main cap discharged, it now sprints with a
burst of energy that has been gradually stored in C2a/b. This means several
things, after 'learning' about being stuck the bot takes action to 'unstick'
itself. In an offensive possition the bot learns how to 'charge' another bot
that touches it. Interesting no? I'm away from home so I can't test the
circuit untill I get back home so if anyone else has the time I implore you
to try it, since it's rather simple (although tweaking the cap values may
take some time, since I expect the value to C2A and C2b to need to be higher
than C1a/b) Tell me how it works out. Officially, I call it Bertram-Memory
or B-memory for short, (Hey! Zollean got a motor bridge named after him!)
And it just stands for this type of memory implementation. I expect that you
can tweak this circuit using other devices attached or just starting with
this basic principle to make it more effecient. So there. My two cents.
Dennison Bertram
From: dbertram@CMU.EDU Add to Address Book
Date: Sun, 02 Aug 1998 16:50:09 -0400
To : "Chiu Fang"
Subject: Memories for beam devices.
I was thinking about the idea for implementing some sort of memory in Beam
devices. I'm still away from home so I don't have any real chance to
experiment. I have been takeing a Electronic and computer engineering course
at Carnagie Mellon that has increased my understanding of circuits
immensely. I think it would be very advantagous to work out a method of
implementing memory into a Beam device. Beam devices are 'stagnating'
currently it seems. There hasn't been any real improvment in a little while,
although I must interject that the possibility's for imporvement are
enormous (ie, segmented robots, inchworm beam devices, diffrent types of
ball robots, and passive Beam bots (my recent idea)) the construction of
some sort of memory device would spice stuff up a bit.
Anyway, in class we were discusing memory devices and diffrent types of
digital memory. I'm not sure however that digital memory is right for beam
at this time, although I saw a really neat implementation of a two inverter
Static memory circuit that has potential. I was thinking that Nu's could be
used in a way to provided a memory. Cap's would be the easyest way to
implement a analog memory system. It would be easy to charge a cap, ie Store
a memory, but then figureing out how it influences the actual robot is the
hard part. Anyway, I just wanted to bring it up for discusion, see what you
think about it.
Dennison
Date:Wed, 01 Jul 1998 22:25:51 -0500
To:Gadagada@aol.com, richfile@prairie.lakes.com, beam@palladium.corp.sgi.com
From:Richard Weait
Subject:compliance in motors [was MECI motors]
Reply-To:Richard Weait
At 08:09 AM 7/1/98 EDT, Gadagada@aol.com wrote:
>In a message dated 98-07-01 01:43:29 EDT, you write:
>I'm going to build 3, 4 and a 5 motor walkers with some MECI motors.
>Correct me if I'm wrong, but I think those MECI motors are a bit too compliant
>to be useful in a walker.
[snip]
The good news is that the compliance is adjustable,
in some cases. You can see this when you are testing
motors in surples stores; (using the Miller method :-) )
[motor testing as described by Andrew Miller]
Holding the motor in one hand with the motor leads
open circuit, spin the shaft and observe. The 'clunk-
ier' the motor is; the worse it is. The longer it
spins; the better it is.
Now holding the motor, with the leads short circuited,
spin the shaft. The harder it is to spin; the better
the motor.
[end Miller method]
It's that second part we'll exploit. It demonstrates
the 'generator' aspect of the motor; if you spin the
shaft to generate current, and that current is fed in
to an infinite load (zero ohms between the motor leads)
the load stalls the motor. (well, I'm taking liberties,
but it should be close enough)
Use a lighter load (larger resistor) and the 'generator'
spins more freely, 'til at open circuit, it spins and
spins . . . Dave recently mentioned an implementation of
this braking method; I used a diode across motor leads in
a Mini-Ball when the motor tended to 'slide back down' if
against an obstacle. This diode can't be used if the motor
is to be bi-directional!
For your bi-directional motors (presuming an H-bridge)
active braking can be implemented by driving both motor
leads to the same power rail. This short-circuits the
motor like the 'Miller test' above. So while your robot
might 'fall' to a rest position when switched off, when
powered it can have reduced compliance, under electronic
control.
(see Mark Tilden's H-bridge primer at Brian's Tek page)
The 'brake' output marked on the fully functional
h-bridge (the one with the 74xx139) can be an adjustable
brake by using a resistor in series with the switching
element to set the maximum brake 'strength.'
Cheers,
Richard.
Subject:
Re: stop, walk, dig
Date:Sat, 27 Jun 1998 11:57:28 -0600 (MDT)
From:"Mark W. Tilden"
To:beam@palladium.corp.sgi.com
>I was just (re)reading Tilden's paper, _Living Machines_, and I noticed
>the following gaits described for Walkman: stop, walk, and dig.
>Now I'm pretty sure I know what stop and walk are, but what about dig?
>Any ideas out there? I'm fairly certain that Walkman isn't used in the
>garden...
At saturation, the legs all moved back and forth in unison, the net result
being zero forward motion, but an effective way for the robot to pull
itself down into a sandpile.
What else could we call it but "dig"?
markt.
Subject:Re: Stryder
Date:Tue, 23 Jun 1998 19:22:47 -0500
From:Richard Weait
To:
Hey Dennison;
While leg sequencing is the key to forward vs.
reverse in a ScoutWalker type walker, Stryder is
more complex. Endpoints matter. Phase counts.
Try this as your starting point:
Imagine that the range of motion for each leg, as
viewed from above, is an arc of ninety degrees and
none of the legs' ranges overlap. We'll have the
centre of the robot at the intersection of the two
lines. We'll also imagine that the "." marks are
selected 'stops' for the legs, and that they are
in a circle.
forward
^
d . | . d [hey! that
c . | . c circle doesn't
| stink too much!]
b . | . b
|
a . | . a
-------------------o-----------------
a . | . a
|
b . | . b
|
c . | . c
d . | . dFigure 1. Starting Stryder walking
Look at the vectors here. When we set the endpoints
at 'a' and 'b' the major orthogonal component is forward
and / or backward with little left and / or right. Look
at the placement of the centre of gravity 'o' now. How
does length or width affect C.G. placement, you ask?
Very much, thank-you, I respond helpfully.
If you want Stryder to walk with the traditional 1,2,3,4
gait you've got to have the C.G. under control. The legs
need to be checked for length, too. This design uses a
very small lift component to each step, so one leg, a little
too long will be an anchor!
So, with the above clues, get to your 'homework' and
report what you find. Go for straight(-ish) forward;
if it goes straight back, then you must have put the eyes
on the wrong end. :-) See what you can or must change
to go straigh back. We'll take care of turns later.
Oh, and relax; I'm not going to send you on a quest
for a two-thousand Nv-net.
Cheers,
Richard.
Stryder 1.0 details...
Brian O. Bush (bushbo@xtdl.com)
Sat, 19 Jul 1997 12:17:36 -0400
Greetings all,
I had asked some questions on Mark Tilden's bot, Stryder 1.0 to Dave
Hrynkiw (in reference to the pics on the solarbotics walking machine web
page). Stryder 1.0 is a very tall bot that places its load vertically on
the motors. The Stryder 1.0 pic is at:
http://www.solarbotics.com/beam_3a.html
Cheers, Brian
>* how big is this thing? (i am guessing around 8-9" tall?)
That sounds 'bout right.
>* how does it handle bumpy terrain? (good, bad, just avoids it)
LOUSY. Definitely a flat-surface walker with a maximum of about 1/8"
clearance. It depends on it's (impressive) mobility to avoid obstacles.
>* do you think a four motor walker such as this, could it be solarizable
>(yep, no batteries for me--spend more on motors :)?
Yes. It's quite power efficient as it doesn't move it's mass up and down
excessively.
>* are there any higher quality pics coming, so i can get some nitty gritty
>details?
I do have some, and it's on my "to do" list. Sorry about the delay!
>* any other details about its construction would be helpful.... since it
>seems to be a great test platform, i am thinking about building one
>similar. i could make several "heads" and interchance them for different
>behaviors, and etc.
The legs are splayed out from vertical at approximately 5 degrees at 90
degree spacing from each other, surrounding the "head" motor which points
up. The rear pair of legs are operating on a totally separate microcore
from the front legs, which (surprisingly) allow it impressive control based
on the phasing of the front legs. Hard to believe, but true! Saw it with
mine own eyes (ah, the eyes...). The head mechanism is operated in turn
with the leg activations, so it stops, looks around, then goes on it's
merry old way.
---
brian o bush,
gearhead
"the moment of terror is the beginning of life."
carve down to http://www2.xtdl.com/~bushbo
BEAM Robotics: http://www2.xtdl.com/~bushbo/beam/FAQ.html
Subject:Re: The final round of annoying turbot questions!!
Date:Tue, 16 Jun 1998 16:54:50 -0600
From:Dave Hrynkiw
To:Gadagada@aol.com, beam@palladium.corp.sgi.com
At 02:23 PM 6/16/1998 -0400, Gadagada@aol.com wrote:
>Richard Weait mentioned that the circuit was brilliantly
>modified by Dave H. so that both motors are active even when light levels
>between the two photodiodes is greatly varied.
The concept is to maintain the charge in the "sensor" capacitor even when
the PTurbot triggers. That way, when the optics are strongly active on the
other side which makes it trigger, and trigger, and trigger, the sensor cap
on _this_ side slowly gains charge until it ultimately will trigger before
the one on the "busy" side can zoom charge up and overtake it. So it may
take 10 triggers on one side before the other finally goes, but it
certainly keeps a turbot from getting stuck in one place because the other
limb isn't moving at all.
See the .22uF caps that cross the optical sensors? Replace them with much
larger values, like 10uF or 22uF (still experimenting). Then place a diode
just forward after the photodiode in forward-biased condition (striped end
towards cap/1381).
Now, this is where I've found a flaw in my logic (what the heck was I
thinking when I built this?): The diode should keep the charge from leaking
out of the 22uF cap back thru...what? The photodiode shouldn't leak; it's a
diode! Thru the 1381? Hmmm..on my Pturbot, I've got the diode installed
*before* where the 1381 is connected. With my Pturbot, it shouldn't work,
but it does. Then again, I'm not going from a schematic - I'm trying to
decypher the wiring on a hacked PhotoPopper circuit board (wise, huh?). I'd
draw a schematic, but I'm lousy with ASCIImatics. Didn't somebody once post
a URL to a program that helps draw such thing (please repost)?
I would think results would work better if you placed a diode in front of
each sensor cap *AFTER* where it connects to pin 2 of the 1381. Then it
blocks any possible leakage from the sensor cap thru the 1381.
Anyways, that's the general idea: Allow regular Photopopper action, but
soften the phototropic response so the other motor has a chance to fire at
least once-in-a-while.
>And what is the basic physical arrangement of the photodiodes
>in realtion to the arms so that the turbot is photovorous?
Not sure exactly - I haven't had the opportunity to examine the behaviour
of my slap-dash-put-together Pturbot yet. I would think normal
Photopopper-style orientation should generally work as long as you have the
optical sensor facing out directly in the same direction of the motor
output shaft. Otherwise, every 180 degrees, it's looking behind/ahead of
itself (confusing!).
>I've been thinking about this for a while (not long enough, eh?) and just
>can't seem to figure out how a turbot moves toward light that it senses with
>the photodiodes.
Me too, but I haven't had the time to finish my "though experiments".
Regards,
Dave
---------------------------------------------------------------
"Um, no - that's H,R,Y,N,K,I,W. No, not K,I,U,U, K,I,_W_. Yes,
that's right. Yes, I know it looks like "HOCKYRINK." Yup, only
2 vowels. Pronounciation? _SMITH_".
http://www.solarbotics.com
Subject:1381 replacement, Telcom TC54
Date:Wed, 10 Jun 1998 07:45:56 -0600 (MDT)
From:Roger E Critchlow Jr
To:beam@palladium.corp.sgi.com
I just stumbled onto a pin for pin replacement for the 1381 at
DigiKey. Do a parts search for TC54VC and you'll find CMOS voltage
detectors in TO92 and surface mount for 2.7, 2.9, 4.3, and 4.9 Volts.
They're a bit more expensive than the 1381: $1.01 vs. $0.85. Follow
the link to the vendor, http://www.telcom-semi.com, and you'll find
that they produce these in lots of other voltages, that their TO92
package has the same pinout as the 1381, and that they claim 1uA
typical 3uA maximum, quiescent current at 2.1V, rising to 2uA typical
4.2uA maximum at 5V.
-- rec --
Subject:Re - Convergence.
Date:Fri, 24 Apr 1998 18:16:12 -0700
From:"Mark W. Tilden"
To:beam@palladium.corp.sgi.com
Chris Ledderhof
> A walker that is strong enough to damage itself will.
Period. End of sentence.
Any form of feedback (Feed Forward, Feed Back, Feed Through) will only be useful after you've a balanced, in order, robot Mechanics and open loop Nv Convergence.
Mechanics: Lower your robot's center of balance. Spread your legs (the robots) so they're each perfecty 45 degrees each from your center of mass and level when the robot's in the neutral position. For forward walking robots, move the front legs in slightly to help with forward lift. If you don't like mechanical stops, use matched small springs on each side of your robot to a fixed point on the frame. This creates a natural centering effect better than gravity and reduces gearmotor slop. Above all else, think spider and use the thickest plastic coated AC solid-core wire from your local hardware store as the legs. Cover the ends in heat shrink to cut down on burrs and bring the legs in towards the CoB until the robot can move the legs *almost* to the collapse limits under load.
Convergence: Get some 5M pots or equivalent and play with the individual tau's on your microcore. You'll find many possible walking gaits but choose the one that gives you the biggest sweep of your legs on a level surface without unbalancing your device. Put in your sensors (tactile, visual) and play this game again, but now with variable resistors on your stimulus inputs as well. Don't let stimulus overwhelm your walker. Subtle effects are enough as tau variation effects are cumulative.
Feedback: Put in 50k pots across your 245 from the ins to outs, and play the convergence game again. Proprioceptive feedback benefits (implex) really only work on reasonably efficient motors, so if you're using servos or slot-car motors, you can skip this bit and go back to convergence fine tuning. Other forms of feedback will entail limit switches, potentiometers on your motors, and etc. The classical feedback methods popular in robotics and RC hobbys for years. If you're using worm-gear drives, for example, the *only* way you'll get a functional walker is with limit switches on your legs.
Gotta go, but believe me, follow these steps and your machine can go from barely walking to barely stopping. Some experimentation required. Your mileage may vary. No warrenties experessed or implied. Do not use in shower. Objects may shift during shipping. Not the Beatles.
markt.
Subject:Re: Hey...what does this do?
Date:Wed, 18 Mar 1998 11:37:25 -0800
From:"Mark W. Tilden"
To:beam@palladium.corp.sgi.com
>I just ordered a whole bunch of stuff from Digikey. I saw a
>photodetector(?) so I ordered a couple of'em. So i went to my meter to
>check it out and In light I get .4 volts haven't hooked all of them up yet,
>But I was wondering are these what is used in Tilden's BEAMant? I saw a
>picture of one that looked like it had them, It was a poor picture tho.
>Maybe Hook enough up to drie an SE
My passive "eye" of choice, the Seimens SFH 206. For IR detection, the
sharp IS1U60. Availalble at a variety of electronics parts sites,
including solarbotics, I think.
markt.
Re: Nervous net as the lowest layer in a subsumptive design
Mark W. Tilden (mwtilden@aerie.lanl.gov)
Tue, 1 Oct 1996 14:16:29 -0600
>Imagine a Tilden-esque nervous net as the lowest layer in
>a Brooks-style subsumption architecture.
Well, it works, but there's a problem.
When I first started reading Brooks, I immediately built a variety of my
own Subsumption based machines (micromouse, two-legged walker, three legged
hopper, remote submarine, etc), and immediately found the same problem I'd
had with conventional parallel-design robotics. To whit...
Tilden's Design Law: If, for a linear increase in ability, an exponential
increase in complexity is required, then start over from scratch.
Subsumption is better than parallel-control designs (which are VERY
brittle, especially as they are so software/connection dependant), but the
same complexity problem kept popping up in my subsumption designs as well.
The layered structure is a beautiful, threaded way to think about
behavioral control, but when one exception is made, you have to make other
exceptions to counter it, and after a while, you have a mess you've
forgotten how to debug five minutes after the download.
The Nv approach is not just a robust way to phase-drive motors, it's my
attempt at a design methodology that gives linear ability for linear
complexity. If you've built the bare-bones Nv walker you know it works.
The secrets are minimality and symmetry (I get pissed if I have to use two
whole hex inverters for a complete walking design, and doubly so if the
circuit has ugly bumps in the schematic).
But there's more. Nv tech is not just a bunch of oscillators, work we're
doing now shows that given the right type of Nv designs, capable autonomy
is not just possible, it is, given the right neural morphology, damn well
inevitable over a vast spectrum. That is, there now exist Nv designs that
give Exponential ability increase for linear complexity increase, and they
still work even if the damn thing gets chain-sawed!
I think the secret of life is anything that exhibits more competent
survival behaviors than components (biological plausable? Anyone?). The
problem is, if you stick a processor on top of it, you run the risk of
violating this rule, and even worse, imposing artificial values from the uP
on a Nv more capable of handling itself.
Getting a Nv to work is simple. Hooking it up so it can work with other
influences, aye therrre's the rub, and a major unexplored research field.
We've had one successful uP interface (Telluride, July 96), but not a few
other laughable failures (i.e.: the aply named Spazbot).
So it can be done, but my recommendation (or perhaps it's just my private
mania) is to see just how far we can push Nv tech into doing things we'd
nomally expect the uP to do. Is there a limit to Nv adaptability? Don't
know. More machines necessary.
Is all.
markt.
Influential E-mails Page 3
BEAM stuff
Beam Table of Contents