Subject:
|
thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 29 Jun 2006 17:30:49 GMT
|
Viewed:
|
3535 times
|
| |
|
|
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
|
|
Message has 5 Replies:
 | | Re: thoughts on gbc module reliability
|
| (...) 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 (...) (18 years ago, 29-Jun-06, to lugnet.robotics)
| | | Re: thoughts on gbc module reliability
|
| (...) 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 (...) (18 years ago, 29-Jun-06, to lugnet.robotics)
| | | Re: thoughts on gbc module reliability
|
| [Others have addressed most of this, so I'm just putting in my 2 cents and not a bunch of "me too"s] (...) Ok, but that one I do have to add a "me too" :-). (...) Over any long-term average. This could be 1 ball every second, or a batch of four (...) (18 years ago, 29-Jun-06, to lugnet.robotics)
| | | Re: thoughts on gbc module reliability
|
| ...and then, after lots of testing and verifications, you get the problem of mechanical wear! Some designs are more sensitive to that than others. For example my Archimede screw ((URL) that initially worked reliably is now unusable after several (...) (18 years ago, 30-Jun-06, to lugnet.robotics)
| | | Re: thoughts on gbc module reliability
|
| I built a few modules for an Australian AFOL meeting. I must say i did very little testing. (2 URLs) The three components were: 1 conveyor belt (excellent reliablility and throuput) 2 screw (inspired by Philo) which had a tiny bow in the 32L axle (...) (18 years ago, 5-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
|
|
|
|
