To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.events.brickworldOpen lugnet.events.brickworld in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Events / BrickWorld / 241
240  |  242
Subject: 
Re: Re Rafe Donahue's GBC binary counter
Newsgroups: 
lugnet.robotics, lugnet.events.brickworld
Date: 
Fri, 6 Jul 2007 15:48:34 GMT
Viewed: 
130 times
  
In lugnet.robotics, Brian Davis wrote:

I know that my posterior Bayes updater worked even better
than I had come to expect when testing here at home, so
that was a relief for me.

Do you have pictures up (Brickshelf, other)? Or at least an explaination?


There is some video that Joe posted.  There are some pictures too.

The explanation goes something like this:
Upon entry into the module, the ball is lifted with a standard link lifter and
is dropped onto a narrow chute that directs the ball onto the diffusion table.
(That's a word I just made up: diffusion table.)  It is really just a collection
of pins on a flat surface.  The pins make the ball bounce this way and that way
so that as they rolled down the table, they get distributed, shuffled,
randomized, whathaveyou.  A picture of the machine is here:

http://www.flickr.com/photos/brickjournal/622340259/in/pool-brickworld/

You can see the input chute on the left and the diffusion table from the end of
the chute to approximately the yellow support post.  Notice how the balls have,
at least in this photo, all collected on the downstream-right side of the
diffusion table.

So, we have balls coming down the chute and forming a _distribution_ once they
pass through the diffusion table.  Now, if the chute is in the middle of the
diffusion table (note that it can pivot left and right so that the balls may or
may not enter the diffusion table in the middle), then the resultant
distribution should have a mean in the center.  (In fact, if things were
perfect, the distribution would be binomial with the center of the distribution
centered directly downstream from the chute.)  But if you look carefully, you
will see that some of the pins in the diffusion table have little bionicle teeth
(or are they claws?  whatever.) on them so as to force the balls only one
direction.  In the current picture, the balls are all on river-right (canoeist
term for the right side when facing downstream) eventhough the directioning pins
are all pointed left, an artifact of the fact that this picture was taken during
non-run time and someone just put all the balls on river-right.  Go figure.

So, the balls have formed a distribution.  There is a slowly rotating parallel
turnstile at the bottom of the distribution that releases one row of balls at a
time.  You can see three balls being released in this picture looking upstream:

http://www.flickr.com/photos/brickjournal/611024719/in/pool-brickworld/

You might want to think of the balls as being in positions -1, 1, and 2 if we
make the middle position zero, looking upstream.  Looking downstream, of course,
they are in positions 1, -1, and -2.  The balls then stay in their little chutes
and drop into the slanted gearing mechanisms as they fall.  The gearing
mechanism is slanted so that the balls fall past a series of turnstiles that are
turned once for each ball passing.  The gear train, with a zillion
differentials, forms a mechanical adder to add up the rotations generated by all
the balls falling past the turnstiles.  Balls falling farther from the center
generate more total turnstile turns and thus get more votes in the summation.
As such, it takes 6 balls falling just outside the center (positions 1 and -1)
to equal one ball falling in the furthest chute (positions 6 and -6).

This (very subtle, because of the necessary down-gearing) rotation is passed to
a torque amplifier (design idea courtesy of Alexander Holroyd), essentially a
polarity switch and differential and motor combination.  When the cumulative
rotation is large enough (in the neighbor hood of a few degrees), the switch
gets closed and the motor turns on.  Turning on the motor does two things: (1)
it reopens the switch, shutting off the motor and (2) it sends a strong twist
pulse down a flexible axel, all the way to the input chute at the beginning of
the machine.

Now, there are really two mechanical adders and two torque amplifiers, one on
each side of the center of the distribution table.  The mechcanical adder on the
river-right side of the center is configured to push the input chute toward
river-left; the adder on the river-left side pushes the chute to river-right.
(This summation of pushes is carried out via one last differential.)  As such,
_the machine continually adjusts itself to keep the mean position of the balls
dropping through the turnstile gate in the center!_

So, to keep things interesting during the show, every now and then (15, 20, 30
minutes, or whenever I was moved) I would redirect the bionicle teeth so as to
give the machine something against which to adjust.  In the example in the first
picture, the balls all on river-right would gradually push the chute to the
left, but the bionicle teeth would force the incoming balls back to the left, so
there would not be much motion.  But if we were to turn all those teeth to point
to river-right, in about 10 minutes the chute would have migrated to point
river-left to compensate.  "It's foolproof."

So, why is it a posterior Bayesian estimator/updater or whatever I called it?
The idea of Bayesian statistics is to estimate a parameter of a distribution.
One starts with a prior distributional estimate, collects data, and they
integrates the prior with the distribution of the data given the prior in order
to generate a posterior distribution.  Then the estimate is usually taken to be
some summary of the posterior distribution.  In this GBC module, the position of
the chute is the prior, the balls falling through the gate are  the data, and
the new position of the chute after the balls drop is the posterior.  We are
estimating the effect of turn bionicle teeth on the mean position of the balls
at the bottom of the diffusion table; the position of the input chute is the
current estimate of the negation of that effect!

Another picture of balls in motion can be seen here:

http://www.flickr.com/photos/brickjournal/633268626/in/pool-brickworld/

with four balls racing to get counted.  The four balls are in positions 1, 2, 3,
and 4.  Four balls are in position for being the next data set.  They are in
positions -2, 1, 2, and 4.  There is a pair of balls in the zero chute just
ready to fall and NOT get counted; the minifig is chewing them out for not
taking a stand.  Note the distribtuion is pushed river-right, since the teeth
are pointing that way.  In a few minutes the chute (with a ball on it) will be
well past center pointed river-left and will have compensated for the fact that
the teeth are pointing right.  The torque amplifier are both visible.

So, the trick was to come up with a way to measure the position of the balls
once they got mixed up on the diffusion table.  The turnstile gate was easy
enough; I spent months trying to come up with a way to measure the mean of a
collection of balls.  Teeter-totter position once the balls fell through was an
idea that failed.  A water wheel with the balls carrying the wheel different
distances failed.  The mechanical adder would have failed without the torque
amplifier.

All-in-all, it was a great year of building, but too many headaches.  Many
thanks to all the help I received online!

Walt from California brought a small link-lifting
module that we inserted into the chain.  It worked
well but we learned a lesson on pushing too hard on
the part tolerances with his module!

Did things keep binding up because of tight clearance?

Yes, there was a tread-link lift with two of those axel/peg things on each link.
They were exactly two-studs wide, passing through a gap exactly two studs wide.
The axel things would work loose just slightly and bind when entering the chute
and then things would fly apart.

Steve H is going to be posting the text from my GBC
reliability talk on the web one of these days.

I look forward to it - it's a talk I'd have loved to sit in on. And yeah, a lot
of it could be summed up in two points:

1) Follow the Spec... the Spec is good... always follow (or exceed!) the Spec.

and

2) Test the module until your eyes bleed, and then do it again.


See? You could have given my talk.  Good thing you didn't waste your time and
went to Colorado instead!!!

I always try to keep in mind that they spec has at least three components: one
is the 10x10x10 input/output hopper, one is the flow rate, and one is the
clearance to the back of the table.  My latest creation was quite wide, thus
necessitating some offset between the input hopper and the chute that leads to
the diffusion table and offset between the final output and the location of the
output mechanism.

Rafe



Message is in Reply To:
  Re: Re Rafe Donahue's GBC binary counter
 
(...) That I can believe - he's amazingly good at that. I just hope my modules didn't give him any trouble. (...) It works very well that way for closing loops - both Steve and I can switch the trains from "circulating" to "ping-pong" mode at will, (...) (17 years ago, 5-Jul-07, to lugnet.robotics, lugnet.events.brickworld)

10 Messages in This Thread:





Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    
Active threads in Robotics

 
Verified and Trusted Team of Hackers
25 minutes ago
Custom Search

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