Alt-BEAM Archive

Message #08352



To: beam@sgiblab.sgi.com
From: Bruce Robinson Bruce_Robinson@telus.net
Date: Fri, 17 Dec 1999 23:17:09 -0800
Subject: [alt-beam] Re: BEAM Flocking (HPV)


> Richard Caudle wrote:
> ... There needs to be a number of systems to the Herd PhotoVore (HPV).
>
> 1. Battery Power with solar charging capabilities!
> 2. Auditory sensors (for positive audiotropism)
> 3. Vocalization
> 4. Locomotion ('natch)
> 5. Vision (for positive phototropism)
> 6. Collision avoidance (feelers)
>
> What I'm proposing that we do is to work on a joint project. It's
> working quite well on the Soccer Project and the PSH Project.

Lots of overlap here with three of my (too many) ongoing projects.
Here's a thought or two to consider.

Use your joint project to estabish some standards. For example,
frequency, volume, duration of your sound emissions (e.g. the chirp).
Also, frequency range of your receivers -- you will want to filter out
motor noise (audible and electromagnetic). Avoid any standards beyond
this minimum.

BEAMers could then mount the circuits to whatever mobile creature they
can think up. Walkers, crawlers, rollers, whatever. Then, whenever
BEAMers get together somewhere, they can bring along whatever HPV(s)
they happen to have, stick 'em all together in a park, and see what
emerges. Could be VERY interesting.

Some ideas to fuel discussion ... tear them apart as much as you like.
First, DON'T have a "master" robot that initiates or co-ordinates
activity. Design them so they all function autonomously.

Second, keep your chirps short enough that a typical robot can't lock
onto the source on the first chirp. Get the robot turning and moving in
the general direction, but no more.

Third, make your design independent of the number of robots. Any number
more than one should be able to interact.

Finally, one possible master control scheme.

- each robot, after it emits a chirp, counts "x" other chirps before
it emits one again. I suggest "x" be a number around 8 or so.
- the robot waits a short interval after the triggering count is
reached, before it emits it's chirp.
- if a chirp hasn't been heard for "y" seconds, advance the counter
one position (a virtual chirp).
- this is the easy part. Ought to be possible with Nu's and Nv's,
probably half a dozen caps & resistors, a few diodes, and a 74HC14.

Random variations between 'bots will likely tend to spread out the
chirps until the robots are emitting them in sequence. Presumably the
robots will turn and move toward the last chirp they heard. This could
be pretty chaotic at first, but may converge on a particular area.

Ought to be fun. Someone (Richard!) take charge. You don't need a boss
to make it happen on the net, but you need a driving force or two.

Bruce



8353 Fri, 17 Dec 1999 23:18:25 -0800 [alt-beam] Re: Bi ped beam@sgiblab.sgi.com Bruce Robinson Ian wrote:
>
> Hey, I was just browsing some web sites related to biped walkers and it
> seems most are 10 motors designs ...

> Ankles ----
>
> 1) Ankle pivot (forward/backward)
> 2) Side to side is controlled by servo
> 3) pivoting rod from the tip of the foot to
> the higher section of the leg
> 4) Thus when the knee bends the ankle will bend
> to keep the body centered above the feet.

Well, I didn't want to discourage you, but I couldn't see getting away
from two motors per ankle. Still don't, to be honest.

> How the robot will balance itself ----
>
> 1) 4 pressure sensors in each foot will let the robot know where the
> pressure is and then adjust so the center of gravity is right over the
> middle of the foot.

Do-able, but keep this in mind. When both feet are on the ground, you
won't be able to use pressure to get the center of gravity over the
foot, because the leg will only be carrying part of the weight. As soon
as you even begin to lift the other leg, the pressure will increase
dramatically on the inside of the supporting foot, so your system will
have to begin immediately to shift the center of gravity to balance the
weight of the leg. You might want to consider a bit of springing action
in the supporting legs, so the transfer of weight is gradual when a foot
is lifted.

>
> How to achieve balance ----
>
> 1) Hip motors move to swing the body back and
> forth changing the center of gravity.

This sounds like static balance to me. In other words, the body is never
allowed to fall. So one of the things I do (more successfully than
building robots at the moment) is teach people how to move, in ways they
aren't familiar with. All the movements start with the stance -- the
position of the feet, legs, and hips. Based on this experience:

1) It can be done. (A human CAN move across the room
using only static balance).
2) It looks really weird -- probably even stranger than
your experiments.
3) It ain't easy.

Each time you shift the raised leg forward, you're threatening to upset
the balance, so you have to shift the hips back slightly to compensate.
You will almost need a master-slave control circuit. Shift the raised
leg forward slowly on command. Use your 4 pressure sensors to shift the
hips back (both knee and hip motors, I expect).

When it comes to static balance, the point to remember is the centre of
gravity must always be above a point that lies within the boundaries of
the foot. Key principle -- use big feet.

Dynamic balance is a whole other ballgame. Your robot is constantly
falling, but always in control. I've heard that the biggest problem is
stopping (shift from dynamic to static balance).

Sounds like fun ... if you have a high frustration tolerance.

Bruce



>
> Laterz
> \^^^^^^^^/
> (.)(.)
> -------------------------.oooO-- (__) --Oooo.--------------------------
>
> There is only one true "SyNeT"
> BEAM Online - http://www.beam-online.com



8354 Fri, 17 Dec 1999 23:18:22 -0800 [alt-beam] Re: PCB iron on transfers beam@sgiblab.sgi.com Bruce Robinson jester96@iname.com wrote:
>
> ... The only way I can make PCBs now is with a pen, and that it's a pain in the arse, so I am looking for something better. How much do cheap UV boxes cost?

Chris, you might want to consider photo-etching. A number of firms now
make PCB's pre-coated with a photo-resist.

Design your layout, print it onto transparency overlays, place it on a
piece of pre-coated PCB material, weight it with a transparent plate,
and expose it to UV according to instructions. Then develop the plate
and etch.

Two sites to check out, both with lots of information to you know what
you're getting into:

In the US: http://www.turnpike.net/~Kepro/index.htm

In Canada: http://www.mgchemicals.com/

Kepro uses a negative process, so you have to invert the colours in your
layout (e.g. traces are transparent, material to be etched is black.)

MG Chemicals uses a positive process.

Both outfits are wholesalers, but their websites have lists of
distributers. I chose MG chemicals, (thanks to Greg Powell for the
recommendation) simply because they're Canadian-based; shipping
chemicals across the border is sometimes a hassle. The Kepro
distributers I checked out weren't able to ship the developer to Canada.

So after all this hype ... I haven't tried it yet. Got all the
materials, got the stuff for a UV box, got the circuit designed, now I
just need some time.

It's worth checking out the sites, in any case.

Bruce



8355 Sat, 18 Dec 1999 00:21:55 -0700 [alt-beam] Re: Bi ped Ian Hi

> yeah, you are going to need *at least* 10 motors to
> make a biped walker that can actually walk.
I'm watching a movie of a 4 motor biped walker walking fine right now so it
isn't "required" but if you want more maneuverability to turn and stuff your
going to need more.

> Say you want the bot to lift one leg while standing.
> You are going to have to shift the center of gravity
> 'COG' over the foot that is still planted on the
> ground. This is where your original pic that you
> posted fails. you have no DOF to accomplish this
> shift.
Um, no. Not from what I see. I have a side-to-side motor in each ankle. Just
turn that and raise the opposite leg and it will rest one leg. Then you are
able to lift the leg and move it around. Keeping the balance using the ankle
motor and hip motors of course.

> You are also going to need an impact cusioning motion at
> the knees for the leg as it plants, or your bots steps
> are going to be so sudden and jarring that it's going
> to bounce itself right onto it's back.
Maybe a couple springs in the heal?

> Now in order to stop it has to be able to shift the
> COG slightly back in order to slow down and counteract
> the forward momentum.. all while still shifting side
> to side and taking steps.
Yikes, well I've got some work cut out on the programming sensor electronics
side =)

> Now all this has to be done while dynamically keeping
> track of the balance of the bot, or it's going to fall
> over all the time. And you plan on doing this with a
> *Basic Stamp*???
That was my first thought. I'm going to give it a try.

> I dunno.. I don't want to rant about this too much..
> Honda has done an amazing thing with thier humanoid
> bot, in that it walks fairly closely to how a human
> walks..
Anyone got a million dollars for me to spend? I'm working more in the $100
range.

> The MIT little dinosaur bot can't even walk yet as far
> as I know.. all it can do is stand itself up from a
> crouch and then go back to a crouch. And they seemed
> pretty ecstatic about it....
That things pretty complex. Their other biped bots and do flips and stuff on
the other hand. Pretty cool!

> IMHO, you'd be better off spending your energy
> elsewhere.. There are plenty of exciting things to do
> in hobbyist robotics research.. Let the big
> orginazitions throw money at making bipedal walkers..
Your probably right but I'd like to at least give it a try. If I can at
least get it to stand up and balance I'll be happy.

Thanks for the info. You gave me lots of ideas.

Laterz

--------
There is only one true "SyNeT"
BEAM Online - http://www.beam-online.com

Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and
weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and
weigh only 1.5 tons. - Popular Mechanics, 1949

Home