| |
> This is great! I'm excited! Maybe I'll convince Calum to get rtl going on
> this--static GBC displays at our robotic events!
>
> Dave K
Cool -
That works for me :)
Steve -
on the page it says "The IN basket should be 10 studs by 10 studs
(outside dimension) with an 8x8 opening, and should be 10 bricks
(beams) tall." and "Each module should be able to accept balls at an
average rate of 1 ball per second. Balls can be passed continueously,
or in a batch. A batch should not exceed 30 balls."
Does this mean the IN basket can have any type of
internals/mechanicals, so long as the entry point is 10x10 with an 8x8
opening located 10 bricks off the ground, having a capacity of 30
balls, and being able to flush those said thirty balls in 30 seconds?
(as opposed to a 10x10x10 hopper that has to be scraped/dumped out?)
I'm also guessing that the IN hopper must always be there :)
-Rob A.
|
|
| |
In lugnet.robotics, Rob Antonishen wrote:
> Does this mean the IN basket can have any type of
> internals/mechanicals, so long as the entry point is
> 10x10 with an 8x8 opening located 10 bricks off the ground,
> having a capacity of 30 balls, and being able to flush
> those said thirty balls in 30 seconds?
Yep. The IN basket is really more of a "target zone" - the upstream module
should drop the balls into your IN basket zone (really, the 8x8 center section)
from a height of at least 10 bricks (no specified upper limit, so when building
your module it might be a good idea to keep the column above your IN basket
clear of structure).
The source for this is the SMART folks Crate Contraption - that standard
makes it possible (we hope) for a backward-compatible Type II standard which
allows filling and moving crates. Note that this type of module would work in a
Type I standard as well, but it makes each module using/moving such crates
responsible for dumping their own into the next module downstream.
> I'm also guessing that the IN hopper must always be there :)
Catching/corraling all these dang soccer balls is already going to be tough
enough. Yes, you should have an input hopper.
As to the throughput rate standard, modules really should be able to handle
either a nearly continuous feed, or "episodic" feeds of around 30 balls without
choking, and still maintain the 1 bps (ball per second) minimum rate. Yes,
minimum - you could have a module that can process and handoff balls much faster
than that, and it shouldn't swamp the downstream module, because the line as a
whole will be regulated by a "timing module" at the start.
--
Brian Davis
|
|
|
