| |
In lugnet.robotics, Jordan Bradford wrote:
> I saw this and was reminded of Rafe's binary counter:
>
> http://www.youtube.com/watch?v=GcDshWmhF4A
> http://woodgears.ca/marbleadd/
>
> It's a marble-powered binary adder.
>
> Rafe's counter could do this with a tiny bit of modification. He'd just have to
> add a tray at the top and bottom to temporarily store the input and output for
> easy viewing.
Hi Jordan,
You are right; Rafe's counter actually does this already. The only mod would be
the storage trays you mentioned.
In fact, during down times at Brickworld, I often mention that the machine is
really an adding maching and all we are doing in the GBC set-up is adding unity
to the total. I sometimes show that we can add, say, 5 + 6 + 7 like the
wood-worker does by setting all the flip-flops to zero and then just dropping
all the balls into the appropriate holes at the top.
Anyway, thanks for the post for the opportunity to see the wood version.
We just got in from our return trip from Chicago; I now think some long naps are
in order!
Rafe
|
|
| |
In lugnet.robotics, Rafe Donahue wrote:
> In fact, during down times at Brickworld, I often mention that the machine is
> really an adding maching...
I'll use this as a location to ask (for those of us who *couldn't* make it...
this time...) how did the GBC in particular go? What were some of the new or
innovative modules, and does anybody have GBC-specific pictures up as yet?
--
Brian Davis
|
|
| |
In lugnet.robotics, Brian Davis wrote:
> I'll use this as a location to ask (for those of us who *couldn't* make it...
> this time...) how did the GBC in particular go? What were some of the new or
> innovative modules, and does anybody have GBC-specific pictures up as yet?
Brian,
Greg D spent a great deal of time manning the loop and did, as usual, a
wonderful job.
Steve H redid the train thing so that it went back-and-forth, instead of
round-and-round. Personally, I think this turned out to be a much better
system, since it removed the train for me inadvertently knocking it to the
floor.
Gus' NXT-driven fork-lift was a joy to watch.
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. Of course, on
the outside it just looked like the balls were falling through a randomizer; the
wise ones among us knew it was actually computing the mean using an analog
computer the whole time!
Phil made some modifications to his large module from last year. It took some
tinkering during the first day and some additional reprogramming but he was able
to keep it running during the two expo days.
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! But it was great that he added it to the
display.
Steve H is going to be posting the text from my GBC reliability talk on the web
one of these days. The key point, of course, is to always follow the spec! But
you knew that, right? :-)
A young man whose name escapes me brought a simple NXT powered lifting gate
thing later in the show. We were able to insert that into the chain on, I
think, the second day.
There were some standard modules that I had brought before, like my foosball
game and ball counter, and some by others that I had seen before, like Andrew
D's minimal 10x10x10 stepper, and some others that came from Indiana, although I
never have learned whose was whose!
Oh, and someone (again I forget, someone please help me here) brought the
drawbridge for the train so that we could enter and leave the display area in a
highly classy fashion. Crawling under the tables seems SO lame now...
All in all, it went well, but we missed Brian Davis.
Rafe
|
|
| |
The drawbridge is John Brost's.
|
|
| |
In lugnet.robotics, Rafe Donahue wrote:
> Greg D spent a great deal of time manning the
> loop and did, as usual, a wonderful job.
That I can believe - he's amazingly good at that. I just hope my modules didn't
give him any trouble.
> Steve H redid the train thing so that it went
> back-and-forth, instead of round-and-round.
> Personally, I think this turned out to be a much
> better system, since it removed the train for me
> inadvertently knocking it to the floor.
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, although usually in a
given show on one mode is used.
> Gus' NXT-driven fork-lift was a joy to watch.
*That* I'm really sorry I missed. Gus, Dave, and the rest of the SMART group
were my inspiration for my forklift GBC module... so much that after a lot of
correspondance with him, I ended up naming my (RCX-based) forklift "Gus". With
all the recent stuff, I've not had the time to pull it out and improve it much,
but the NXT forklift sounds wonderful. Any video out there on this yet?
> 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?
> 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?
> 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.
> Oh, and someone (again I forget, someone please
> help me here) brought the drawbridge for the
> train so that we could enter and leave the display
> area in a highly classy fashion.
As mentioned, that was John Brost. He worked hard on that module, after many of
us just said "yeah, I'm sure that would work". He's the guy that actually went
out and put it into practice. That's another thing I really hope to see in the
future.
> All in all, it went well, but we missed Brian Davis.
Well, I wish I could have been there, and missing the festivities a lot as
well... but on the other hand I did get to do a 9 mile hike up above the
treeline (in 4 hours... altitude can really make things interesting) in
Colorado, so my day was fairly full as well :-).
--
Brian Davis
|
|
| |
In lugnet.robotics, Brian Davis wrote:
.
| |
- I’m really sorry I missed. Gus, Dave, and the rest of the SMART group
|
Go here.
| |
| |
All in all, it went well, but we missed Brian Davis.
|
Well, I wish I could have been there, and missing the festivities a lot as
well... but on the other hand I did get to do a 9 mile hike up above the
treeline (in 4 hours... altitude can really make things interesting) in
Colorado, so my day was fairly full as well :-).
|
Yeah, but we still missed you:-)
Joe
|
|
| |
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
|
|
| |
In lugnet.robotics, Brian Davis wrote:
> In lugnet.robotics, Rafe Donahue wrote:
> > Gus' NXT-driven fork-lift was a joy to watch.
>
> *That* I'm really sorry I missed. Gus, Dave, and the rest of the SMART group
> were my inspiration for my forklift GBC module... so much that after a lot of
> correspondance with him, I ended up naming my (RCX-based) forklift "Gus". With
> all the recent stuff, I've not had the time to pull it out and improve it much,
> but the NXT forklift sounds wonderful. Any video out there on this yet?
I'm sorry I missed seeing you too in Chicago. What I brought is more of a truck
with a crate loading mechanism in the front, like a garbage truck with a
dumpster lifter in front. In the back a cargo bed with a side dumping
mechanism.
I have not found any great video of my truck or wave crate loader though I know
there were a lot of folks shooting video of it.
Only GBC video I have found is from Zac Donahue, uploaded by Joe Meno:
http://www.youtube.com/watch?v=6X9tZsIKDf8
You can see my truck towards the end of the video.
Zac, thank you for taking this video and getting it on the net. If anyone else
has more GBC video, please make it available. Thank you in advance.
If you want to see the CrateDump truck in action, checkout the video that David
Schilling shot in Portland. Again, the truck is mostly towards the end of the
video.
http://www.youtube.com/watch?v=bGmOAYqKSaU
Gus
|
|
| |
There are a couple of YouTube videos of the GBC and my truck in particular that
have not yet been mentioned.
Here is a very nice GBC video uploaded by Joe Meno:
http://www.youtube.com/watch?v=NLOuTJEpeD4
Here is one that shows my truck in action picking up and loading the balls from
the crate and then driving around to dump the balls into the train-car loader.
Thank you Brian from Brickworkz LLC for this one.
http://www.youtube.com/watch?v=0ol0biHrpE0
Gus
|
|
|
