Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 29 Jun 2006 20:11:09 GMT
|
Viewed:
|
3701 times
|
| |
|
|
In lugnet.robotics, Rafe Donahue wrote:
> 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
> 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
Ahh the lamentations of the GBC slave...I feel your pain. After beginning my
primary GBC module a week after BF'05, I am *still* testing it. It is extremely
complicated and and I've had to make countless design decisions and tradeoffs.
At one time I had an external leak rate out the back of my module of about one
ball in 3. I had to bypass it completely in order to achieve a more sane ball
throughput. You didn't mention how much testing and redesign it takes to even
get to the point of 95% confidence before you run a quarter million balls
through it! You effectively get to the point of diminishing returns after a
while. I think babysitting our modules as Steve said is an inevitable
occupational hazzard. Hence the term.
Good lifter feeding is definitely a bit of an art. I have two on mine that are
pretty good. MUCH trial and error, but once you find a combo that works, you
can just duplicate it to other modules!
I've managed to get my jam rate down to less than once an hour of operation.
External leaks are about one ball a minute, internal leaks are about one per
fifteen minutes. My problem is low overall ball throughput: about .3 to .4
balls per second on average. When you see how much I am doing every second in
it, you'd understand why ;)
I think the standard is always open for interpretation and revision, but I think
it's written with enough wiggle room for most situations. I think it would be
an accomplishment if we were able to get a large majority of people to follow
it! That's my 2.0000x10^0 cents.
Dave H.
|
|
Message has 1 Reply:
 | | Re: thoughts on gbc module reliability
|
| (...) This may be where some people get into trouble. The height & placement of the in & out baskets is a hard requirement. So is the minimum of 1 bps. People MUST follow the standard, in order for the GBC to work. Last year at BrickFest, every one (...) (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
|
|
|
|
