Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 29 Jun 2006 19:39:11 GMT
|
Viewed:
|
3536 times
|
| |
|
|
On Thu, June 29, 2006 1:30 pm, Rafe Donahue wrote:
> All GBCers,
>
> This will likely be a long post, so be forwarned.
Rafe,
It sounds like all this info jammed up in your brain, before it finally leaked
out... :)
All these thoughts & calculations are good. As you pointed out, for one module,
it's ok if 90% of the balls pass through. However, with ten modules at 90% each,
only 1/3 of the balls will make it through, and that's not too acceptable.
The key we've found to making this work is that YOU (the builder of a module) are
responsable for getting ALL the balls through YOUR module. If you do that by
scooping them with your hand, and moving them to the next module (I've seen it
done), that's fine (but very unimpressive.) If you have a leaky module, and don't
want to babysit it, it will be removed from the GBC.
You may recall, last year, at BrickFest, we had the ability to "turn-off" sections
of the GBC (by bypassing the train unloading stations) to allow builders to repair
damage caused by jams. Then, we put the "less tested" modules all in one section,
and the "more reliable" modules in another. We also only ran the GBC for about 1/2
hour at a time. I think that worked very well.
And, under the heading of "one ball per second", the standard page says:
"Each module should be able to accept balls at an average rate of 1 ball per
second. Balls can be passed continueously, or in a batch. A batch should not
exceed 30 balls."
The intent is to say the module should handle thirty balls every thirty seconds.
Some modules have batch outputs (up to 30 balls). Other modules don't accept batch
inputs well. We simple don't place those modules next to each other.
Good thoughts.
Steve
> It contains some rambling
> thoughts on development and reliability of GBC modules. Now that I have started
> writing, I'm not sure exactly where this is headed, but I have this need to try
> to get these thoughts out of my head an onto paper or its electronic equivalent.
>
> Ok, so over the last couple of months I have been working on three GBC modules
> that I plan to bring to Brickfest in August. Development and testing can never
> start too early, I think, since the kinks are very difficult to iron out,
> certainly the ones that are quite rare.
>
> So, some thoughts for open discussion, or to cure insomnia:
>
> Building a (reliable, functioning) GBC module is harder than it looks. The
> really hard part is lifting. Actually, lifting is easy; reliably getting the
> balls *onto* the lift mechanism is hard. Getting them off the mechanism is
> easier but has challenges too.
>
> It seems to me there are essentially two competing issues with this reliability
> (most of it takes place in the transition from simple rolling or stationarity to
> the lift mechanism). These two issues are what I call 'jams' and 'leaks'.
>
> Leaks happen when a ball (or balls) goes somewhere where it isn't supposed to
> go. External leaks are leaks where the ball leaves the system completely, like
> onto the floor. Internal leaks result in the ball ending up somewhere within
> the module but they are typically not readily available, such as they would be
> if they were on the floor. Leaks are fine as long as they are relatively
> infrequent. That being said, a module that leaks 100% of the balls it is given
> isn't a successful module. On the other hand, it is possible for a module to
> never leak, but simple "never leaking" could be acheived by just catching all
> the balls in a big tub, so that's not optimal either.
>
> The worst kinds of leaks lead to 'jams', a situation where the ball falls out of
> the system and then does something untoward, like getting stuck between two
> moving pieces. In the dramatic situation, pressure builds up and parts
> eventually go flying; in a less dramatic situation, a jam just backs things up
> (e.g., a motor stops turning and the balls stop moving), but even that type of
> jam likely eventually will lead to a leak.
>
> So, leaks (can) lead to jams and jams can lead to leaks and both lead to modules
> that don't create throughput at a rate of at least 1 ball per second (bps). (A
> topic for another discussion: "one ball per second" --- over what time period?)
>
> So, in playing with my modules and tweaking and adjusting, I'm think that there
> needs to be more to the spec than "1 ball per second"; there also need to be
> error rates estimated, in particular jam and leak rates. I can easily build a
> module that can absorb balls at 1 bps but has an equivalent leak rate so that's
> not right. Judging from what I saw last year, few of the modules had error
> rates of zero, although I am sure that there are some.
>
> And I think that these error rates need to be quite low, really low, since when
> putting all the machines together in series means that one jam stops the flow
> downstream and creates leaks upstream.
>
> A jam rate of 1 ball per thousand at 1 bps is a jam essentially once every 17
> minutes but with 40 modlues in sequence, the probability of *at least one jam*
> rises to about 4 percent (1-.999^40), or about 1 every 25 seconds. To get the
> probability of at least one jam across 40 modules to less than 1/1800 (once per
> half-hour), the individual jams rates have to be less than 0.000013892652, or
> 1.4 out of 10,000. Yikes. No wonder it is so hard to keep them all running.
>
> How much testing does one have to do to determine that the rate is actually that
> small? An exact 95% confidence interval for the true error rate when you get 0
> jams out of 265,524 balls is [0, 1.389264x10^(-5) ), meaning, essentially, that
> you need to run 250,000 balls through your module (and get no jams) to be
> relatively sure that you have a jam rate low enough to keep 40 modules running
> for 30 minutes with an exceptation of less than one jam in that half-hour.
>
> That's nearly 70 hours of testing at 1 bps with no jams.
>
> Ouch. Get testing! And don't think that 100 balls with no jams is good enough.
> And (external) leaks are better than jams, since we can intervene as humans and
> pick up the loose balls.
>
> Ok, that's all for now.
>
> Rafe
>
|
|
Message has 1 Reply:
 | | Re: thoughts on gbc module reliability
|
| "Steve Hassenplug" <Steve@TeamHassenplug.org> wrote in message news:35326.66.84.205...air.com... (...) Thread HiJack!!!!!! The new Bionicle sets have some shotting balls in them and they are a little bit bigger than soccer balls (and a little (...) (18 years ago, 29-Jun-06, to lugnet.robotics)
|
Message is in Reply To:
| | thoughts on gbc module reliability
|
| All GBCers, This will likely be a long post, so be forwarned. It contains some rambling thoughts on development and reliability of GBC modules. Now that I have started writing, I'm not sure exactly where this is headed, but I have this need to try (...) (18 years ago, 29-Jun-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
|
|
|
|
