 | | 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
|
|
(...) 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)
|
