 | | 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)
|
| |
| | 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
|
|
"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)
|
| |
| | 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
|
|
(...) They are a little bigger and a little heavier. If either of these is a problem for your module, then it's a problem. :) They will work with most of my modules, but not all. However, they are good for shooting with an NXT... Steve (18 years ago, 29-Jun-06, to lugnet.robotics)
|
| |
| | 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)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) I've worked with these as well. They look nice, and like Steve I have some modules that can handle them, and some that can't. More interesting (to me) is that a simple mechanical sorter works great, so potentially you could have a GBCm that (...) (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
|
|
(...) This brings me to a question: is there any restriction on bringing last year's modules to this year's Brickfest? On one hand it seems like that could make it even bigger (!) but on the other hand we want some new stuff, right? Thoughts, (...) (18 years ago, 29-Jun-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) If you have a module, then bring it - old or new. I'm not sure how many new ones I'll have, especially as one of mine is now a virtual GBC antique, having been one of the very first modules ever made to the standard. And the others that will (...) (18 years ago, 29-Jun-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
I wonder whether some cause of instability for seemingly well tested modules when they are put into a real GBC is that the specification doesn't specify the speed, or the angle of entry of balls into your input hopper. If your upstream 'test' module (...) (18 years ago, 30-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
|
|
(...) Yeah, that's a good point. I've yet to have a module fail due to wear, but for at least one of my modules I've actually found a dusting of yellow ABS under certain axles by the end of the day. I guess part of this is just due to the fact that (...) (18 years ago, 30-Jun-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) My pirate ship fired balls using a spinning LEGO tire like a pitching machine. By the end of Brickfest the tire was completely bald, and there were small flecks of black rubber all over the place. You can test, test, and test some more, but (...) (18 years ago, 30-Jun-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) Agreed. That's why I think that testing is one thing, but situational testing is something else. Over the last week, I have run nearly 25000 balls through my latest experiment. I think the trick is to set things up to feed themselves, (...) (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)
|
| |
| | 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)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) 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, (...) (18 years ago, 5-Jul-06, to lugnet.robotics)
|
| |
| | 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)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) The idea of combining a number of small subunits, each of which work as desired (high reliability and throughput), can create complexity *with* reliability. That's the idea I will be unveiling in August. Bring an extra pair of socks for when (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) You could maybe design a special module to split the fast rate stream into some number of slower streams - to be recombined later. So if (for example), you had a bunch of 0.5bps modules, you could build two chains of them and dump alternate (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
what is the standard for the balls - in other words where can I get a bunch for testing? (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) The balls are just regular Lego soccer balls - with the occasional basketball thrown in (they are all the same size - just different colours). Someone (I forget who) had a whole bunch of them that Lego had donated that he was giving away to (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | GBC Soccer Balls
|
|
(...) Yes, I have a whole bunch. If you would like some, send me your address, and I'll send you some balls. Steve (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) Steve Hassenplug. See (URL) Brian Davis (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) Plus, one of the train motors died, which required Steve to go to the LEGO store and buy the 4512 Cargo Train as a replacement. I also think the track was dirty and stopped conducting well, since by the end of the weekend the volunteers were (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) I'm not sure this is the way to do things... I don't want to seem cruel or anything (but I will be blunt), but this module of yours doesn't meet the GBC spec of 1 bps. It is your responsibility as a builder to make it fit the spec, not change (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) FWIW I do have a bypass on my module. I just have it blocked right now while I am testing the remainder of it. My earlier post was an acknowledgement of the difficulties that exist in meeting the minimum rate. I certainly am not trying to make (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) Roger that on the spouse kicking out part. We already had our annual Brickfest argument! She says I run and hide in my Lego room for endless hours. She's wrong: I walk there! I have one more tidbit: please email me at (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) I don't think it's a question of being offensive. It's simply a question of how it would work. The "Leaky Bucket" analogy only works if all modules can handle the same average throughput over an extended period of time. Otherwise, the "bucket" (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) What about a 'splitter' with two outputs (nominally 0.5 bps/output) and a 'joiner' for combining the two streams later on? (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) That works, but it's not as simple as it sounds. Keep in mind with all the below, it *can* be made to work: I'm not nearly as negative as I seem below :-). First, you need a splitter and combiner that... (a) work At Least as well as a "normal" (...) (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) Another thing we might try is to implement this splitter at the junction of the throughput zones to catch any ball overflow from the leaky bucket module. Then this shunted ball flow could be loaded onto several train cars and haulled around (...) (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) I guess I don't understand what you mean by a leaky bucket module. I'm imagining something that would work well for "smoothing" the flow, but it will require the output to match the average input. (...) Last year, one section of the GBC was (...) (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) Or to put it another way, use a GBC train system to handle 0.5 bps at a splitter module, so that downstream of the splitter the thinned stream would be 0.5 bps. This would seem to require (a) a dedicated train (& room for it), (b) a splitter (...) (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) I have three designs on paper for leaky bucket modules. The basic version of what I had in mind was a simple large hopper to receive balls from either the faster modules, the train, or both. The output would be a simple lifter, which was run (...) (18 years ago, 7-Jul-06, to lugnet.robotics, FTX)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) David, Sorry I can't explain this very well, but the leaky bucket will not provide an acceptable interface between the fast & slow modules, like you're suggesting. Steve (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) This is what Steve and I call "clocker" modules, and they have always been present. Here's a good example of Steves: (URL) can also redirect the output to a number of directions and heights. Very useful, in fact critical for the trains, as (...) (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) A simple explaination: the rate in must equal the rate out, or the bucket overflows. Period. (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) <sigh> This is why one of designs I mentioned had a second, variable output. One in::two out. If the input rate was say 3 bps, then the two outputs would be equal to 3 (in this case) 1bps and 2bps. I didn't give a very detailed explanation of (...) (18 years ago, 8-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) I recall reading about Steve's ideas of sectors to handle downed modules. Is this a given or some optional aspect? I would think it would be mandatory. I think at this point, I'm going with the KISS plan, but I'm trying to learn as much as (...) (18 years ago, 8-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
John Brost writes: > The idea of the spec was so that EVERY module could be put ANYWHERE > in the GBC and it would all work. In the past, this has been bent > so that modules that can't handle large batches are not placed > downstream of a batch- (...) (18 years ago, 10-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) If I understand what you mean, yes, you can make an arrangement of modules that satisfys the GBC spec input/output as a whol, even though they don't individually. That's fine (like Rafe's "supermodule", for instance). But then the individual (...) (18 years ago, 10-Jul-06, to lugnet.robotics)
|
