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