Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 7 Jul 2006 20:34:00 GMT
|
Viewed:
|
6891 times
|
| |
|
|
In lugnet.robotics, David Hurley wrote:
> I have three designs on paper for leaky bucket modules. The
> basic version of what I had in mind was a simple large hopper
> to receive balls from either the faster modules, the train, or
> both. The output would be a simple lifter, which was run on
> a controller, much like you described.
This is what Steve and I call "clocker" modules, and they have always been
present. Here's a good example of Steves:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1788102
which can also redirect the output to a number of directions and heights. Very
useful, in fact critical for the trains, as they always dump large numbers of
balls at once. I have a module that can dump a train, or accept regular input,
and can handle about 60-80 balls at once, and (like Steve's, above) can clock
the output to anyhting from about 2 bps on down:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1788111
Both of these can handle trains... in fact, *any* module that unloads the trains
has this sort of issue to deal with. It still doesn't solve any issue with
low-throughput sectors, as what goes in, must come out. Modules like this do
allow you to "pause" sectors for a short time, while the surplus builds up in
modules like these that can temporarily impound significant numbers of balls
(I'm not sure where Steve's limits at, but min could absorb a standard 1 bps
flow for more than a minute without shutting down the whole GBC, which is enough
time to swap things out).
> Another one had a (powered) RCX 1.0 to control the train track
> voltage and a dumper motor for the train car.
This would seem to work if you use isolated track segments and an RCX for
each station. That seems a little RCX-expensive to me, as you can use a single
RCX to control two stations (loading, unloading, and train), with the lift or
clocking mechanism run by a battery box or equivilent.
> The output of this one had two lifts that split the balls
> from the hopper into two flows: one variable and one fixed
> at .5/1.0 bps.
Where did these two outputs exit the module? There's only one
standard-conforming output location, and since you don't know how deep the
neighboring downstream module is, where do you output the second stream? I can
think of several options, but the most likely would be at right angles to the
flow: either violating the backplane requirement (and likely crossing the train,
something we've talk about and are working towards), or extending out in "front"
of the module, with possibly limited room (i.e. - this stream, at least very
near the splitter you describe above, could only dump into fairly small
modules). Is this your idea?
> The third one was a variation of the above one, but with a
> train dump interface and RCX 1.0.
How is it different?
> As it stands, I only have so much time and components to use/borrow.
I understand that! Believe me, I can sympathize there... especially on the
"time" issue.
> If you can bring your stuff from last year, we will certainly
> put it to use!
I'm pretty sure a lot of us will be bringing stuff, from last year or
otherwise. As to pictures, browse Brickshelf. There are lots of them.
> The gbc website has a section on this topic that I developed:
> <www.greatballcontraption.com/leaky-bucket.html>
That seems to be on regulating network traffic where rules are being followed
(and sometimes broken). For the GBC, the rule is quite simple: 1 bps long-term
rate, with burst rates not to exceed 30 bps. Follow those rules, and it all
works together nicely without any special hardware (a bonus, as that means *any*
collection of modules can form a GBC, with no "special" modules required: that
was one of the primary goals, to allow *anyone* to do this, anywhere).
--
Brian Davis
|
|
Message is in Reply To:
 | | Re: thoughts on gbc module reliability
|
| (...) I have three designs on paper for leaky bucket modules. The basic version of what I had in mind was a simple large hopper to receive balls from either the faster modules, the train, or both. The output would be a simple lifter, which was run (...) (18 years ago, 7-Jul-06, to lugnet.robotics, FTX)
|
43 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
