 | | | | | | |
| |
|
In lugnet.robotics, Russell Nelson <nelson@crynwr.com> wrote:
> Steve Baker writes:
> > Another thought I had was that the organisers might want to consider
> > building a stage that has one input hopper and TWO outputs that sends
> > balls alternately to the two places.
>
> Yes! Since the soccer and basket balls are the same physical size,
> there is no reason why a module can't work with both. There is also
> no reason why a module couldn't sort soccer balls out one side, and
> basketballs out another.
>
> To that end, you need a specification for a "Y" module, which has two
> output faces. Also for a module which has two input faces! And a
> module which is a 90-turning corner and a 270-turning corner. It's
> pretty obvious what's needed for them; it just needs to be written down.
I made a device that sends balls alternately down two chutes.
Balls enter through a 2x2 hole in the top, onto the centre of a 7L studless
beam, set up as a see-saw.
Which ever way a ball goes, it drops onto another, longer, see-saw that tilts
the first see-saw the other way to send the next ball down the other chute.
Balls exit though 2x2 holes in the bottom at each side.
I used two more studless beams (liftarms work well too) crossed over to do the
reversing links between the see-saws.
This contraption is about 13 bricks high and 4L deep, but could be made smaller
in height. Its advantage it that it doesn't need a motor. The minimum height
is dictated by the need for the energy from a ball dropping nto the lower
see-saw being more than enough to tilt both see-saws.
Of course this device won't sort balls by colour, but that's a slow process.
Also, soccer balls have black and white bits so you can't predict which bit a
light sensor will see, and hence whether the reading from a soccer ball will be
greater or less than the reading from a basketball.
I used the see-saw device with a vertical ball lifter, based on transmission
chain with a few track links. It was possible to over-run the see-saw device
with too many balls, so that two went the same way, but the through-put had to
be quite fast before that happened.
A module with 2 input faces would probably be a hopper with 2 chutes entering
it. The greatest problem I've had with ball contraptions is balls clogging in
the hopper - sometimes you need an agitator like they use in factories.
Mark
| | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Mark Bellis wrote:
> A module with 2 input faces would probably be a hopper with 2 chutes entering
> it. The greatest problem I've had with ball contraptions is balls clogging in
> the hopper - sometimes you need an agitator like they use in factories.
Any operation involving a long sequence of events as in The Great Ball
Contraption (TGBC) is likely to be fouled up by failure of one of the events in
the chain - the so called weakest link.
Is there allowance for the fact that one of the modules may act up and not
deliver the requisite balls for the next module to act on?
Each module must at minimum be able to sense that there are indeed balls in the
input bin before acting on them and that there are balls in the output bin for
the next module to do its stuff.
A fail-safe mechanism would be such that the offending module can be by-passed
so that the sequence can still go on. I envisage Steve's train could be just the
thing to do the job, running hither and thither to make sure the whole
contraption is working.
But to complicate matters, the weakest link may not be just one module.
Different modules could act up at various times.
CS
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Chio Siong Soh wrote:
> Is there allowance for the fact that one of
> the modules may act up and not deliver the
> requisite balls for the next module to act
> on?
First, test the modules as they are added to the system to make sure they
meet the minimum requirement. Second, watch the whole thing like a hawk, being
ready to shut it down to fix such problems. Third, there will have to be some
special-purpose modules within the system, such as the first "timing module", a
"return module" (like Steve's train), perhaps turn modules, etc. A very simple
bypass module can be built (I'm working in it) that can easily be adjusted in
length "on the fly" so a malfunctioning module can be hot-swapped out of the
line.
> Each module must at minimum be able to sense
> that there are indeed balls in the input bin
> before acting on them and that there are balls
> in the output bin for the next module to do
> its stuff.
At this point, most if not all of the modules I've seen can "run dry", so
there's not need for a module to check for itself.
> But to complicate matters, the weakest link
> may not be just one module. Different modules
> could act up at various times.
Yes. Babysitting will be needed.
--
Brian Davis
| | | | | | | | | | | | | | | | | | |
| |
|
> In lugnet.robotics, Mark Bellis wrote:
> > A module with 2 input faces would probably be a hopper with 2 chutes entering
> > it. The greatest problem I've had with ball contraptions is balls clogging in
> > the hopper - sometimes you need an agitator like they use in factories.
>
> Any operation involving a long sequence of events as in The Great Ball
> Contraption (TGBC) is likely to be fouled up by failure of one of the events in
> the chain - the so called weakest link.
>
> Is there allowance for the fact that one of the modules may act up and not
> deliver the requisite balls for the next module to act on?
Not really. :)
However, we're not expecting the GBC to run 100% of the time. It's not like letting
a train run in a circle for eight hours. There are all kinds of things going on at
the same time. In our testing, we seemed to run for about 20 minutes at a time,
before someone would say, "Stop..."
Then, we'd shut down the contraption, pick-up loose balls, check weak spots, and
power it up, again.
Generally, if one module doesn't work, we'll just take it out, slide the other
modules together, and start going again. Given that there are no "special" modules
(beyond the first and last modules) any other module can be placed in any location.
> Each module must at minimum be able to sense that there are indeed balls in the
> input bin before acting on them and that there are balls in the output bin for
> the next module to do its stuff.
I'd kind of like to see a module that won't "work" if it's empty. :)
| | | | | | |
