To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 26146
26145  |  26147
Subject: 
Re: thoughts on gbc module reliability
Newsgroups: 
lugnet.robotics
Date: 
Thu, 29 Jun 2006 20:11:09 GMT
Viewed: 
3693 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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR