Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 5 Jul 2006 22:42:31 GMT
|
Viewed:
|
5127 times
|
| |
|
|
In lugnet.robotics, David Hurley wrote:
>
> I was wondering the exact same thing. For BF06 planning purposes, I was
> tentatively planning on having "throughput zones" grouped according to balls per
> second. The faster modules would be grouped together just as the slower ones
> would be with others of similar speed. My big mama-jama module can barely do
> .4bps on a sunny day. The junction between the faster to slower modules can be
> regulated with what I call "leaky bucket" modules to regulate/throttle the ball
> flow from faster modules to slower ones.
So then there are shunts needed to allow some balls to go to slow-land and some
to return to fast-land, right? Is this where the train comes in? I'm thinking
this adds a certain level of complexity to the whole organization process. Of
course, we could just set up a place for modules that meet the spec and those
that don't; trying to connect them might make it even harder.
The whole rate-limiting step theory seems to me to indicate that unless every
module follows the standard, we are going to have a mess on our hands. The
leaky bucket will eventually fill up and overflow or it will need to be somehow
unloaded.
Last year I had a component (an archimedian screw) in my module that couldn't
handle 1 bps. As such, I had the part before it (another part of my module)
only send about 1 of every 6 or so balls into the screw; the rest were shunted
around the screw and on to the next module in the line. The select few that
went up the screw got to do some other fancy and fun things. That way I was
able to maintain the standard and keep my components that were not quite up to
speed.
It was, however, *reliable*, in the sense that it didn't jam or leak (to any
noticeable extent). I did have a piece that completely exploded (something
that, in retrospect, shouldn't have been included simply because it was just too
complicated; I learned my lesson: simple, simple, simple) either late Saturday
or early Sunday but I was able to build a by-pass chute quickly and go things
back to running. But my module, as a whole unit, followed the spec. For what
it is worth, that was the part that was built last as an afterthought. Proper
testing on my part would have shown me that it was outside tolerance: don't use
an RCX in a hot room to try to start and stop those RC motors. Oh, and bring
back up parts and such. And no string.
Just some thoughts,
Rafe
|
|
Message has 2 Replies:
 | | Re: thoughts on gbc module reliability
|
| (...) In *principle*, this is one reason to have the possibility of "splitter" modules - you could take a 1 bps stream, and subdivide it into two streams with lower rates (0.5 and 0.5 bps, or even things like 0.75 & 0.25 bps, are easy to do (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
Message is in Reply To:
| | Re: thoughts on gbc module reliability
|
| (...) I was wondering the exact same thing. For BF06 planning purposes, I was tentatively planning on having "throughput zones" grouped according to balls per second. The faster modules would be grouped together just as the slower ones would be with (...) (18 years ago, 5-Jul-06, to lugnet.robotics)
|
43 Messages in This Thread:
 
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
