 | | Re: thoughts on gbc module reliability —Steve Hassenplug
|
| | | (...) 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 —David Hurley
|
| | | | (...) 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 —Rafe Donahue
|
| | | | | (...) 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 —Brian Davis
|
| | | | | | | (...) 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 —Rafe Donahue
|
| | | | | | | | | (...) 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 —Jordan Bradford
|
| | | | | | | | (...) 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 —robert hampton
|
| | | | | | 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 —steve
|
| | | | | | (...) 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 —Steve Hassenplug
|
| | | | | | | (...) 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 —Brian Davis
|
| | | | | | (...) Steve Hassenplug. See (URL) Brian Davis (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| | | | | | |
| | | | | | Re: thoughts on gbc module reliability —steve
|
| | | | | (...) 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 —John Brost
|
| | | | (...) 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 —David Hurley
|
| | | | | (...) 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 —Steve Hassenplug
|
| | | | | | (...) 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 —Anders Isaksson
|
| | | | | | (...) 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 —Brian Davis
|
| | | | | | | (...) 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 —David Hurley
|
| | | | | | (...) 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 —Steve Hassenplug
|
| | | | | | | (...) 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 —David Hurley
|
| | | | | | | | (...) 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 —Steve Hassenplug
|
| | | | | | | | | (...) 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 —Brian Davis
|
| | | | | | | | | | | (...) 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 —David Hurley
|
| | | | | | | | | | (...) <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 —Brian Davis
|
| | | | | | | | (...) 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 —Brian Davis
|
| | | | | | (...) 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 —David Hurley
|
| | | | | | (...) 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 —Russ Nelson
|
| | | | 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 —Brian Davis
|
| | | | (...) 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)
|
| | | | |
