| |
In an attempt to provide Technic & Mindstorms builders the same cooperative
building opportunity that's available to Moonbase, Castle, and Town/Train
builders at Brickfest, we present to you: The Great Ball Contraption.
When it's assembled at Brickfest '05 (DC), The Great Ball Contraption will be
made up of many modules by builders from all over the country, any beyond.
This device will be a combination of Rube Goldberg and the Bucket Brigade,
passing soccer balls from one module to the next, where they will be pushed,
pulled, lifted, flipped, shot, rolled, dropped, etc... before being passed
again.
If a picture is worth 1,000 words:
http://www.teamhassenplug.org/GBC/GBCpreview.JPG
Then a 28 second video (5mb) should be worth about 840,000 words:
http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbcoverview.mpg
And, a 92 second video (15mb)... priceless. Here's one ball passing through
our entire 10 module test assembly.
http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbconeball.mpg
Keep in mind, that was built by me, and just a couple friends. Imagine the
madness when AFoLs from all over contribute their modules to one of the greatest
works of moving LEGO artwork ever assembled...
To learn more, check out the web site:
http://www.teamhassenplug.org/GBC/
Or if you have questions, feel free to post here.
Steve
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> In an attempt to provide Technic & Mindstorms builders the same cooperative
> building opportunity that's available to Moonbase, Castle, and Town/Train
> builders at Brickfest, we present to you: The Great Ball Contraption.
>
> When it's assembled at Brickfest '05 (DC), The Great Ball Contraption will be
> made up of many modules by builders from all over the country, any beyond.
>
> This device will be a combination of Rube Goldberg and the Bucket Brigade,
> passing soccer balls from one module to the next, where they will be pushed,
> pulled, lifted, flipped, shot, rolled, dropped, etc... before being passed
> again.
>
> If a picture is worth 1,000 words:
> http://www.teamhassenplug.org/GBC/GBCpreview.JPG
>
> Then a 28 second video (5mb) should be worth about 840,000 words:
> http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbcoverview.mpg
>
> And, a 92 second video (15mb)... priceless. Here's one ball passing through
> our entire 10 module test assembly.
> http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbconeball.mpg
>
> Keep in mind, that was built by me, and just a couple friends. Imagine the
> madness when AFoLs from all over contribute their modules to one of the greatest
> works of moving LEGO artwork ever assembled...
>
> To learn more, check out the web site:
> http://www.teamhassenplug.org/GBC/
>
> Or if you have questions, feel free to post here.
>
> Steve
Oh My Goodness!!! I'm so there for this!!!
This looks like the funnest thing to happen to RCX's since rtl events.
Where does one purchase 20-30 soccer balls?
Dave K
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> And, a 92 second video (15mb)... priceless. Here's one ball passing through
> our entire 10 module test assembly.
> http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbconeball.mpg
>
> Keep in mind, that was built by me, and just a couple friends. Imagine the
> madness when AFoLs from all over contribute their modules to one of the greatest
> works of moving LEGO artwork ever assembled...
>
> To learn more, check out the web site:
> http://www.teamhassenplug.org/GBC/
This is fantastic. The movie is well worth the download, because if the words
don't encourage, the pictures certainly will.
If enough people sign up, we'll need a seperate GBC room :)
JB
|
|
| |
> > To learn more, check out the web site:
> > http://www.teamhassenplug.org/GBC/
>
> Oh My Goodness!!! I'm so there for this!!!
>
> This looks like the funnest thing to happen to RCX's since rtl events.
>
> Where does one purchase 20-30 soccer balls?
>
> Dave K
Hidden somewhere on the page above, it says I can suppily you with soccer balls.
Thanks to Christina, I have exactly enough to suppily EVERYONE with soccer balls.
If I run short, I'll just talk with Larry... :)
And, for the record, the you are not required to use an RCX. I think 4 of the 10
modules in the video run off a 9v suppily.
Steve
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> > > To learn more, check out the web site:
> > > http://www.teamhassenplug.org/GBC/
> >
> > Oh My Goodness!!! I'm so there for this!!!
> >
> > This looks like the funnest thing to happen to RCX's since rtl events.
> >
> > Where does one purchase 20-30 soccer balls?
> >
> > Dave K
>
>
> Hidden somewhere on the page above, it says I can suppily you with soccer balls.
> Thanks to Christina, I have exactly enough to suppily EVERYONE with soccer balls.
> If I run short, I'll just talk with Larry... :)
>
> And, for the record, the you are not required to use an RCX. I think 4 of the 10
> modules in the video run off a 9v suppily.
>
> Steve
To clarify--are we allowed to use 2 'module spaces' if we want? As well, I
notice that the train ran along 'outside' the designated module area--is that
allowed as well? Do we then have to get permission from our neighbouring module
owners to make sure there's no overlapping stuff?
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
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> > > To learn more, check out the web site:
> > > http://www.teamhassenplug.org/GBC/
> >
> > Oh My Goodness!!! I'm so there for this!!!
> >
> > This looks like the funnest thing to happen to RCX's since rtl events.
> >
> > Where does one purchase 20-30 soccer balls?
> >
> > Dave K
>
>
> Hidden somewhere on the page above, it says I can suppily you with soccer balls.
> Thanks to Christina, I have exactly enough to suppily EVERYONE with soccer balls.
> If I run short, I'll just talk with Larry... :)
I read that, I just decided to be a little more apparent, as in 'Gee Steve, send
me some balls!' ;)
I have a grande total of, wait for it... 1 soccer ball, and it came with my
Brickfest '04 set.
At your convenience, of course :)
Dave K
|
|
| |
> 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, David Koudys wrote:
> I read that, I just decided to be a little more apparent, as in 'Gee Steve, send
> me some balls!' ;)
>
> I have a grande total of, wait for it... 1 soccer ball, and it came with my
> Brickfest '04 set.
>
> At your convenience, of course :)
Or someone who owns a soccer ball could measure it and publish the size.
Most craft stores sell a selection of little wooden balls. It might be cheaper
to buy a few about the right size rather than paying to mail genuine Lego ones?
Of course, I'm not a purist :) Would a wooden ball start to infect the rest of
the contraption's Lego parts I wonder .....
"Oh no! Look! A knot hole is forming in that Technic beam over there!!!"
JB
|
|
| |
In lugnet.robotics, John Barnes wrote:
> In lugnet.robotics, David Koudys wrote:
> > I read that, I just decided to be a little more apparent, as in 'Gee Steve, send
> > me some balls!' ;)
> >
> > I have a grande total of, wait for it... 1 soccer ball, and it came with my
> > Brickfest '04 set.
> >
> > At your convenience, of course :)
>
>
> Or someone who owns a soccer ball could measure it and publish the size.
>
> Most craft stores sell a selection of little wooden balls. It might be cheaper
> to buy a few about the right size rather than paying to mail genuine Lego ones?
> Of course, I'm not a purist :) Would a wooden ball start to infect the rest of
> the contraption's Lego parts I wonder .....
>
> "Oh no! Look! A knot hole is forming in that Technic beam over there!!!"
>
> JB
Sure enough, that'll happen. What about the sawdust envy that LEGO soccer balls
will inevitably suffer from?
Ed
|
|
| |
In lugnet.robotics, David Koudys wrote:
> To clarify--are we allowed to use 2 'module spaces' if
> we want?
Really, the only thing defining a "module space" is a flat L & R edge, and no
part of the module extending more than 32 studs from the front edge of the input
bin "zone" - the footprint need not be remotely rectangular, nor is there a set
distance between the L & R edges. We suggest 32 or 48 stud widths, as that's the
standard baseplates that people are likely (not required!) to use, but it's a
suggestion only. Some of the modules in the first GBC setup are examples of this
"small is beautiful" thinking, and some are monsters - I know of one person
who's "module" is about 3' wide now, and I've got one that only just barely fits
on a 48x48 baseplate (& may grow larger).
And yes, build as many modules as you want. I've got two built, and 2-3
others partially built, and only one uses an RCX at this point.
> As well, I notice that the train ran along 'outside'
> the designated module area--is that allowed as well?
In the example GBC, there's actually a number of "non-standard" things -
first, the train (nominally it runs "behind" the long line of modules, and was a
way for Steve to "close the loop"), and second there are two module that turn
corners, allowing the (standard-defined) linear GBC to wrap more neatly on the
tabletop.
Right Now, the idea is a "linear" standard, but obviously we're thinking (&
building!) beyond this. But we're trying to stick to the linear standard so that
we can ensure *every* builder can participate. Obviously some modules may be
designed to turn corners or otherwise "break" the standard (& fit the entire GBC
in one room?), but to ensure that the device as a whole can work the standard is
semi-limited right now.
One other possible limitation not mentioned in the document as yet - we don't
know if this would be on the floor or a line of tables (or both). If it's
tables, there will be a maximum depth to the module, but we don't know what that
is. This is one of the reasons for the suggestion that modules be wider than
they are deep.
Even they battery-box options are huge, and a lot of fun - we previewed one
of these at the Cantigny show near Chicago, and it was a big hit, especially
with kids. Although I should add that the sound of tens of falling, bouncing
soccerballs can drive NLSO's slightly batty.
--
Brian Davis
|
|
| |
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
|
|
| |
In lugnet.robotics, John Barnes wrote:
> Or someone who owns a soccer ball could measure
> it and publish the size.
Well, it's LEGO - it's just a tad smaller than 2 studs in diameter. If you've
got a marble or wooden ball that will roll between two walls two studs apart
(clearance about 1.5 mm on each side) you've got the size. The only real problem
is weight. Regular (glass) marbles are much denser than ABS (how does wood
compare?), so weight-activated devices (tipping platforms, counterweights) may
be tough.
Another option is the LEGO basketballs - we chose soccer balls because, well,
Steve might have a few extra <cough>. But the basketballs are the same size. And
(thank you SMART!) they can be sorted from the soccer balls by the careful
application of a light sensor...
--
Brian Davis
|
|
| |
> In lugnet.robotics, John Barnes wrote:
>
> > Or someone who owns a soccer ball could measure
> > it and publish the size.
>
> Well, it's LEGO - it's just a tad smaller than 2 studs in diameter. If you've
> got a marble or wooden ball that will roll between two walls two studs apart
> (clearance about 1.5 mm on each side) you've got the size. The only real problem
> is weight. Regular (glass) marbles are much denser than ABS (how does wood
> compare?), so weight-activated devices (tipping platforms, counterweights) may
> be tough.
I'd really recommend against using anything but LEGO balls. If you just want to
play around and test, one good place to get a couple balls are the LEGO NBA sets.
I've seen them on sale all over.
Using any other type of balls will not give you a good test of exactly how soccer
balls will operate in a machine. I'm 100% sure of that.
Steve
|
|
| |
> > To clarify--are we allowed to use 2 'module spaces' if
> > we want?
>
> Really, the only thing defining a "module space" is a flat L & R edge,
> and no part of the module extending more than 32 studs from the front
> edge of the input bin "zone" - the footprint need not be remotely
> rectangular, nor is there a set
> Right Now, the idea is a "linear" standard, but obviously we're
> thinking (& building!) beyond this. But we're trying to stick to
> the linear standard so that we can ensure *every* builder can participate.
I'll point out that the standard as it's defined pictorially allows for a
non-linear layout just as it stands. As long as the input in in the correct
place relative to the previous block's output, and the output is placed
correctly relative to the next module's input, you can have the input and
output on any side of the 32 stud square you want.
For instance, properly configured, the input and output could be placed
right next to one another on a 32x64 platform, and still meet the standard:
-------- --------
| 2 | | 1 |
| -| |-- |
| |I| |O| |
| -| --------
| |O|
| -| Next module goes here, possibly a mirror image of #1.
| |
--------
Hope the simple graphics make it to the list.
|
|
| |
In lugnet.robotics, Ed McGlynn wrote:
> In lugnet.robotics, John Barnes wrote:
> > In lugnet.robotics, David Koudys wrote:
> > > I read that, I just decided to be a little more apparent, as in 'Gee Steve, send
> > > me some balls!' ;)
> > >
> > > I have a grande total of, wait for it... 1 soccer ball, and it came with my
> > > Brickfest '04 set.
> > >
> > > At your convenience, of course :)
> >
> >
> > Or someone who owns a soccer ball could measure it and publish the size.
> >
> > Most craft stores sell a selection of little wooden balls. It might be cheaper
> > to buy a few about the right size rather than paying to mail genuine Lego ones?
> > Of course, I'm not a purist :) Would a wooden ball start to infect the rest of
> > the contraption's Lego parts I wonder .....
> >
> > "Oh no! Look! A knot hole is forming in that Technic beam over there!!!"
> >
> > JB
>
> Sure enough, that'll happen. What about the sawdust envy that LEGO soccer balls
> will inevitably suffer from?
>
> Ed
This post will be overkill I am sure but this Bricklink store sells has 42
soccer balls $.10 US a piece
<http://www.bricklink.com/store.asp?p=UBL>
|
|
| |
> In lugnet.robotics, David Koudys wrote:
> > To clarify--are we allowed to use 2 'module spaces' if
> > we want?
The standard doesn't explain this very well, because I'm really not sure how to
write it.
A module can be any size, but the input and output should be on opposite sides, with
the front of the input being no more than 32 studs from the back of the module, and
on the left side.
We could allow modules to make turns of different types, but then setting up the
whole contraption will be very complex.
Right now, the goal is to have one long line of modules. In the video, one of the
modules can be set-up as either a straight module, or a 90 degree turn, and another
is just dumping into the side. However all modules must be built so they can
connect in a straight line.
> We suggest 32 or 48 stud widths, as that's the standard baseplates that people
> are likely (not required!) to use, but it's a suggestion only.
This blue "module" is a good example of a non-standard size:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1049771
It's a simple module built by a 12 yr old.
You'll notice the "in" box is very shallow. It will most likely not hold 30 balls.
However, because of the flexibility of the contraption (any two modules can be
switched) it can easily be placed after a module that has a constant output, and
therefore doesn't have to deal with large "batch" outputs.
As long as your module fits the in & out rules, it should work.
Steve
|
|
| |
"Brass Tilde" <brasstilde@insightbb.com> wrote on 01/07/2005 01:52:19 PM:
> > > To clarify--are we allowed to use 2 'module spaces' if
> > > we want?
> >
> > Really, the only thing defining a "module space" is a flat L & R • edge,
> > and no part of the module extending more than 32 studs from the front
> > edge of the input bin "zone" - the footprint need not be remotely
> > rectangular, nor is there a set
>
> > Right Now, the idea is a "linear" standard, but obviously we're
> > thinking (& building!) beyond this. But we're trying to stick to
> > the linear standard so that we can ensure *every* builder can • participate.
>
> I'll point out that the standard as it's defined pictorially allows for • a
> non-linear layout just as it stands. As long as the input in in the • correct
> place relative to the previous block's output, and the output is placed
> correctly relative to the next module's input, you can have the input • and
> output on any side of the 32 stud square you want.
While what you're saying will work fine, the standard does say:
Each module should have an "in" basket, and will move balls to the next
module's "in" basket, which must be directly in line.
It also says:
The In basket should be located on the left side of the module, and output
should go to the right.
So the standard *does* specify a lineary progression. Of course, there's
no reason why you couldn't have 4 "non-standard" modules designed for a 90
degree bend to act as corners... But the standard does specify linearity.
An aside: Depending on how rigorous you want this standard to be, I would
think that you might want to specify exactly how much clearance must be
left around the in basket so that each module is compatible. For example,
should that entire vertical column be left free? Or only to a certain
height? Should extra width be reserved around the in basket to allow
space for some sort of container to fit over the basket with room for,
say, tipping?
Tim Massey
|
|
| |
In lugnet.robotics, tmassey@obscorp.com wrote:
> "Brass Tilde" wrote:
>
> > I'll point out that the standard as it's defined
> > pictorially allows for a non-linear layout just as
> > it stands... you can have the input and output on
> > any side of the 32 stud square you want.
>
> While what you're saying will work fine, the standard does say:
>
> Each module should have an "in" basket, and
> will move balls to the next module's "in"
> basket, which must be directly in line...
> ...The In basket should be located on the
> left side of the module, and output should
> go to the right.
>
> So the standard *does* specify a lineary progression.
In addition, there's an actual *reason* why that is set up that way. Can you
picture trying to set up a large scale GBC if we need a certain number of
"turns" and "straights"? There could also be interference issues if the rear of
the GBC line needs to be used for something (as it currently may using Steve's
train module, as it certainly would for *LOTS* of power cords, etc.).
If you wish to make modules that turn corners or anything else, great -
personally I'd like to see as much variation as possible. But for the sake of
trying to get it all in one room, and all working *together*, we defined this
Type I standard to be as painless and robust as possible.
So here's an option for all you who want to exceed the standard already -
build to fit the Type I standard, but build the module with the ability to
reconfigure to produce turns (for instance). This way every module can be
incorperated in a Type I GBC, and then people can have fun "breaking" the
standard in new & innovative ways. If we thought the standard was never going to
change or evolve, we wouldn't have bothered naming it "Type I" :-)
Tim followed up with:
> An aside: Depending on how rigorous you want this standard
> to be, I would think that you might want to specify exactly
> how much clearance must be left around the in basket so that
> each module is compatible. For example, should that entire
> vertical column be left free?
I'd suggest that this be the case, as it insures a rigid standard. But I
suspect that if a *few* modules break this, they can be paired up with modules
that can handle it. For instance, all my modules so far deliver balls to the
downstream module using low-angled chutes; no need for more than about four
bricks of overhead space, and can hit an input hopper only three studs wide.
> Should extra width be reserved around the in basket to
> allow space for some sort of container to fit over the
> basket with room for, say, tipping?
At this point no - for one thing, the upstream module dumping needs only have
an output 6 studs wide or so to make sure it all goes into the downstream input
hopper. The only place I see a strong need for such "extra space" is if one
robot tries dumping a standard crate into another standard crate (and in the
Type I standard, we're avoiding the whole issue).
--
Brian Davis
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> In an attempt to provide Technic & Mindstorms builders the same cooperative
> building opportunity that's available to Moonbase, Castle, and Town/Train
> builders at Brickfest, we present to you: The Great Ball Contraption.
> And, a 92 second video (15mb)... priceless. Here's one ball passing through
> our entire 10 module test assembly.
> http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbconeball.mpg
I watched this (and considering I am on dial up) it was well worth the wait.
Man, this project is so cool!!!!!!!
> Keep in mind, that was built by me, and just a couple friends. Imagine the
> madness when AFoLs from all over contribute their modules to one of the greatest
> works of moving LEGO artwork ever assembled...
I am so looking forward to it.
>
> To learn more, check out the web site:
> http://www.teamhassenplug.org/GBC/
>
> Or if you have questions, feel free to post here.
No questions...... but one comment.....
Chris may be King of rtl, and Dave is King of the Sheets!
Move over guys, because Steve has got balls, and that makes him the *real* King,
at least in this FAFOL eyes.
Janey "Red Brick"
|
|
| |
This is outstanding! I have absolutely no expertise at this sort of thing, so I
can't contribute anything but to stand on the sidelines cheering, but I look
forward to seeing what sort of things people come up with.
Bruce
|
|
| |
> This is outstanding! I have absolutely no expertise at this sort of thing, so I
> can't contribute anything but to stand on the sidelines cheering, but I look
> forward to seeing what sort of things people come up with.
Just because you haven't done it, yet, doesn't mean you won't be able to do it in
seven or eight months...
Earlier today, someone said this, and it really sums up the possibilities with The
Great Ball Contraption:
"It can be really simple, or devilishly complex as time allows!"
But, if you do end up on the sidelines, make sure you get there early, because I'm
sure there will be a big crowd...
Steve
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> In an attempt to provide Technic & Mindstorms builders the same cooperative
> building opportunity that's available to Moonbase, Castle, and Town/Train
> builders at Brickfest, we present to you: The Great Ball Contraption.
Are non-LEGO items allowed? I'm just talking small parts of a mostly LEGO
module, not a whole non-LEGO module. One obvious possibility I'm thinking about
is string, but there may be others.
ROSCO
|
|
| |
news-gateway@lugnet.com wrote on 01/07/2005 04:11:02 PM:
> > Should extra width be reserved around the in basket to
> > allow space for some sort of container to fit over the
> > basket with room for, say, tipping?
>
> At this point no - for one thing, the upstream module dumping
> needs only have
> an output 6 studs wide or so to make sure it all goes into the
> downstream input
> hopper. The only place I see a strong need for such "extra space" is if • one
> robot tries dumping a standard crate into another standard crate (and in • the
> Type I standard, we're avoiding the whole issue).
This was my *exact* reason for asking: tipping containers. If the tip
left to right (from their space to the next module's space), there is no
need for extra width: you steal it from your own space.. But if they tip
from front to back (or some other sort of, say, flat rotation of a square
shape), there is.
But that's what Type II is for, I guess...
Tim Massey
|
|
| |
> In lugnet.robotics, Steve Hassenplug wrote:
> > In an attempt to provide Technic & Mindstorms builders the same cooperative
> > building opportunity that's available to Moonbase, Castle, and Town/Train
> > builders at Brickfest, we present to you: The Great Ball Contraption.
>
> Are non-LEGO items allowed? I'm just talking small parts of a mostly LEGO
> module, not a whole non-LEGO module. One obvious possibility I'm thinking about
> is string, but there may be others.
Well, at this point, it's not really a competition, so there aren't many "rules"
beyond the "standard".
So, you can use whatever you want. For example, the module at the bottom of this
picture has a red & white distance sensor to detect when balls are present.
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1049779
Of course, if it does turn into a competition, I'm sure some construction rules will
be applied...
Steve
|
|
| |
> news-gateway@lugnet.com wrote on 01/07/2005 04:11:02 PM:
>
> > > Should extra width be reserved around the in basket to
> > > allow space for some sort of container to fit over the
> > > basket with room for, say, tipping?
> >
> > At this point no - for one thing, the upstream module dumping
> > needs only have
> > an output 6 studs wide or so to make sure it all goes into the
> > downstream input
> > hopper. The only place I see a strong need for such "extra space" is if • one
> > robot tries dumping a standard crate into another standard crate (and in • the
> > Type I standard, we're avoiding the whole issue).
>
> This was my *exact* reason for asking: tipping containers. If the tip
> left to right (from their space to the next module's space), there is no
> need for extra width: you steal it from your own space.. But if they tip
> from front to back (or some other sort of, say, flat rotation of a square
> shape), there is.
In our test, when people dump, they usually dump onto a ramp in their own module,
that drains onto the next module. Like on John's back hoe:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1049775
As you can see, it hangs over it's neighbor a bit.
Of course, if you ass-u-me anything about the neighboring modules you could run into
problems.
But, again with the flexibility of arranging modules, we'll be able to work around
most problems.
Steve
|
|
| |
"Steve Hassenplug" <steve@teamhassenplug.org> wrote in message
news:I9yEEL.1s4z@lugnet.com...
> And, a 92 second video (15mb)... priceless. Here's one ball passing
> through
> our entire 10 module test assembly.
> http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbconeball.mpg
This played quite well in RealPlayer, although for some odd reason the first
time was very jerky and the sound was all messed up. If anyone else strikes
this problem remember to hit play a second time, as I believe it should be
playing properly the second time.
On TGBC itself, congratulations! That is one great setup you and your
friends have there!! I can't wait to see if you guys make a video of a
whole series of balls running through the machine at once.
Cheers ...
Geoffrey Hyde
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> > In lugnet.robotics, John Barnes wrote:
> >
> > > Or someone who owns a soccer ball could measure
> > > it and publish the size.
> >
> > Well, it's LEGO - it's just a tad smaller than 2 studs in diameter. If you've
> > got a marble or wooden ball that will roll between two walls two studs apart
> > (clearance about 1.5 mm on each side) you've got the size. The only real problem
> > is weight. Regular (glass) marbles are much denser than ABS (how does wood
> > compare?), so weight-activated devices (tipping platforms, counterweights) may
> > be tough.
>
> I'd really recommend against using anything but LEGO balls. If you just want to
> play around and test, one good place to get a couple balls are the LEGO NBA sets.
> I've seen them on sale all over.
>
> Using any other type of balls will not give you a good test of exactly how soccer
> balls will operate in a machine. I'm 100% sure of that.
>
> Steve
Over time, as I gaze at my collection of parts, notably as my interests change,
and curiosity is peaked, I realise that the floccinaucinihilipilification
parts, such as soccer/basketballs, now are not only useful but in serious
demand. I guess that also means eventually I will also find uses for all those
wheels, that seem to multiply on their own, as well. Sigh.
Janey "Red Brick"
|
|
| |
Do you have any better photos (particularly a top-down view) of that
particular module? I don't quite understand how his module managed to fling
the ball out instead of pushing or dropping it. I'd also like to see more
photos of the individual modules, if possible, particularly top-down views.
One thing I'd also like to see is requirements for typical modules, there
are obviously several different pickup and delivery methods in the modules
shown in the video, but there doesn't seem to be an easy way to guess or
estimate what one would need for a typical module parts-wise.
It'd be interesting to see what we could do in Australia, could make for an
interesting Australian meet-up event.
Cheers ...
Geoffrey Hyde
"Steve Hassenplug" <Steve@TeamHassenplug.org> wrote in message
news:23738.66.84.205.186.1105125621.squirrel@66.84.205.186...
> This blue "module" is a good example of a non-standard size:
> http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1049771
>
> It's a simple module built by a 12 yr old.
>
> You'll notice the "in" box is very shallow. It will most likely not hold
> 30 balls.
> However, because of the flexibility of the contraption (any two modules
> can be
> switched) it can easily be placed after a module that has a constant
> output, and
> therefore doesn't have to deal with large "batch" outputs.
>
> As long as your module fits the in & out rules, it should work.
|
|
| |
steve krass wrote:
> Best idea I have seen in a while.
> Will be quite a machine when done.
>
> You should try to paint or die a few balls a different
> color so spectators can follow a particular ball thruoghout the whole machine.
Having different coloured balls would also be cool because it would allow
machines to do things like sorting them so that one colour does one thing
and another colour does something different.
Mixing soccer and basket balls would let people do that and yet still
preserve Lego 'purity'.
However, introducing coloured balls isn't something you can 'just do'
without warning people because they may be relying on light sensor
readings to do specific things with them.
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. This would allow you to take
any machines that cause problems because they don't run fast enough
and put them after this special stage so they don't mess up the whole
timing of the system.
You'd also need to build a machine to combine two slow streams back into
a single 'standard rate' stream sometime later.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
| |
In lugnet.robotics, Geoffrey Hyde wrote:
> I don't quite understand how his module
> managed to fling the ball out instead
> of pushing or dropping it.
As I recall (I was not present, but talked with Steve about it) that module
had problems with jamming - I think what you see in the video is a single ball
partially jamming the mechanism and being kicked out hard. That particular
module used rotating liftarms (the ones with three blades) to move the ball up
the ramp (similar, I'd imagine, to the tri-blade liftarm lift that SMART has
used).
> One thing I'd also like to see is
> requirements for typical modules, there
> are obviously several different pickup
> and delivery methods in the modules
> shown in the video, but there doesn't
> seem to be an easy way to guess or
> estimate what one would need for a
> typical module parts-wise.
Use your imagination! One of the reasons Steve included my (huge, poorly
spelled, not-yet-ready-for-primetime) list was to show the options that just a
few people could come up with... and there's several of the lift mechanisms in
the video that are not in my list*, so long as it is, it is hardly complete!
Many of us used chain links and tread links to form some sort of lift or
conveyor, but no two people came up with the same system. The downside of this
method is that LEGO chain links (& especially tread links) tend to be uncommon.
At the other extreme, I've built one module that lifts balls at around 2-3 bps,
but uses only system bricks and slopes with the exception of 1 technic beam, an
axle, a technic plate or two, & the gears used to drive the system.
For other ideas, check out SMART's Crate Contraption... or do a Brickshelf
search on the word "marble" (the Rolling Ball Clock is an example here)... or do
a Google search for "rolling ball machines" or sculptures. There is a HUGE
amount of inspiration out there for this type of thing.
*about that list. I really can spell better than that.
--
Brian Davis
|
|
| |
Best idea I have seen in a while.
Will be quite a machine when done.
You should try to paint or die a few balls a different
color so spectators can follow a particular ball thruoghout the whole machine.
Good luck guys.
|
|
| |
In lugnet.robotics, Steve Baker <sjbaker1@airmail.net> wrote
<snip>
>
> 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. This would allow you to take
> any machines that cause problems because they don't run fast enough
> and put them after this special stage so they don't mess up the whole
> timing of the system.
>
> You'd also need to build a machine to combine two slow streams back into
> a single 'standard rate' stream sometime later.
That's a just a cool idea in general, to have a branching arrangement. Maybe
some 'special' builders could produce modules that either divide or recombine
streams? I am really looking forward to seeing the GBC, and even though I've
never built anything like this, maybe I'll try to make a simple module. Steve,
this is a fabulous concept!
Cyndi
|
|
| |
> Best idea I have seen in a while.
> Will be quite a machine when done.
>
> You should try to paint or die a few balls a different
> color so spectators can follow a particular ball thruoghout the whole machine.
Actually, we've tried this.
Our first get-together was an all-day event, where we did all sort of messing
around. In addition to a ton of soccer balls, I've receintly picked up a few
different basket ball sets, including a set that had two blue and two red
basketballs. So, I have about seven or eight different types.
John used a light sensor to detect balls in his backhoe, and he discovered sometimes
the black spot on the soccer balls ends up in front of the sensor. So, if his robot
sits for a short time, without seeing any balls, it will "stir" the balls (scoop,
but not pick any up).
I do have video of us tracking a blue ball through the contraption. It seemed like
it just missed every scoop, lift and everything else. The ball took about three
minutes to make one "lap".
Steve
|
|
| |
Steve Hassenplug wrote:
<snip>
> Steve
Steve,
What can you tell me about the Yellow "step feeder" type device in the
"lower left corner" of the GBC ?
A step feeder is a solution to a lego idea I wanted to build.
How complex is it?
Thanks
Chris
|
|
| |
> What can you tell me about the Yellow "step feeder" type device in the
> "lower left corner" of the GBC ?
>
> A step feeder is a solution to a lego idea I wanted to build.
>
> How complex is it?
That module is pretty simple and small. The whole thing is just 10 studs x 13 studs
(with a power cord coming out)
Here's a picture I just uploaded to brickshelf. More waiting for moderation.
http://www.brickshelf.com/gallery/Hassenplug/GBC/StepModule/p1080023.jpg
Steve
|
|
| |
Steve Hassenplug writes:
> As you can see, it hangs over it's neighbor a bit.
>
> Of course, if you ass-u-me anything about the neighboring modules
> you could run into problems.
You can assume anything that's in the specification! Speaking of
which, you should probably add a requirement that the top of the input
bin must always be unobstructed. That is, the output part of a module
gets to do anything it wants with the space over the input part of the
next module.
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
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.
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
tmassey@obscorp.com wrote:
> Or not: leave the standard as it is (except for specifying that the space
> above the input belongs to the previous module), and have the organizers
> build (or specificially request) out-of-spec modules to accomplish this.
>
> That way, you don't have to worry about too many Y's and not enough
> straight pieces! :)
Yeah - I agree. You need the 'average builder' to stick to a simple
straight-line standard one-size-fits-all module. If you don't then
everyone will want to build something esoteric and you'll get hardly
any simple modules of the kind that make this work.
I think that the organisers would be VERY wise to take a long a couple
of Y modules of their own design so that people who contribute machines
that are too slow don't cause a build-up of balls on their input side
and foul up the whole system. Those slower modules could be placed
downstream of a 'Y' module and thus keep working.
There is more than enough scope for innovation within the standard
specification to keep even the most sophisticated builder busy.
The art here for the average contributor is to make something that
fits within the basic rules and yet produces such an AMAZING show
that the audience will be crowding around that module going "Ooooh!"
throughout the show.
However, I imagine that the organisers need to break the rules for
their own work in order to be able to make the system continue to
play nicely even in the (likely) event that some of the modules
are balky.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
| |
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
|
|
| |
Steve Hassenplug wrote:
> > That way, you don't have to worry about too many Y's and not enough
> > straight pieces! :)
>
>
> Yes, that's something to consider. It's possible everyone would create a 90 degree
> left-hand turn. Then what? :)
I think you can handle this with a little care in the design of the
rules.
If the table you are setting it up on is deep enough to permit it,
you could always use four 90 degree pieces in a LEFT/RIGHT/RIGHT/LEFT
sequence to keep the overall pipeline going straight. All you'd need
to do is to have the module design rules enforce more strict dimensions
on 90 degree pieces so that a LEFT/RIGHT/RIGHT/LEFT sequence wouldn't
result in a 'jog' in the line of modules - and to be sure it'll fit
the width of your tables.
That only works if you have the same number of left and right turns.
So simply write into the rules that everyone who submits a left hand
turn has to submit a corresponding right hand turn or they won't
be accepted.
Now, at *worst* you can only have one more pair of turns than you
needed - and you can always stick them at one end of the machine.
You'll need to design your table layout to have an equal number
of left and right turns too - but that should be simple enough.
Similarly, for Y pieces, you could make a rule that everyone who
submits a Y piece must also contribute a corresponding reverse-Y
to recombine the balls back into a single stream.
That guarantees that you'll never have too many Y's or reverse-Y's
and that all L's can be used...and it'll also dissuade most people
from making non-straight pieces because of the need to commit to
making two of them.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
| |
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
|
|
| |
Russell Nelson <nelson@crynwr.com> wrote on 01/09/2005 04:20:10 PM:
> 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.
Or not: leave the standard as it is (except for specifying that the space
above the input belongs to the previous module), and have the organizers
build (or specificially request) out-of-spec modules to accomplish this.
That way, you don't have to worry about too many Y's and not enough
straight pieces! :)
That was something I saw with the Moonbase specification. A *lot* of the
samples they showed had just a single connection to their neighbor. Maybe
nobody wanted to build "boring" straight-through pieces. They also talked
about making modules configurable. But configurable in that context was
easy: a few simple pieces of non-moving Lego bolted on as necessary.
Here we're talking about moving, intelligent systems that I'm sure make a
number of assumptions that will not be easy to reconfigure on the fly.
Hence, having a specification that allows those assumptions be made with a
minimum of fuss seems like a strong point, not something that needs
adjustment...
Tim Massey
|
|
| |
"Brian Davis" <brdavis@iusb.edu> wrote in message
news:IA02Dv.1DH7@lugnet.com...
> Use your imagination! One of the reasons Steve included my (huge, poorly
> spelled, not-yet-ready-for-primetime) list was to show the options that
> just a
> few people could come up with... and there's several of the lift
> mechanisms in
> the video that are not in my list*, so long as it is, it is hardly
> complete!
Hmm I must have missed that list post. I am kind of working on a
contraption, but it's main aim is to sort LEGO bricks, which are a lot less
likely to slide than soccer balls are. :) It may require some form of
Mindstorms help, along with a visual recognition system, but I am going to
see if I can get it to sort mechanically or with sensors first. It should
be fairly useful for sorting out basic brick sizes from one another, at any
rate, if I can get a workable prototype built.
> Many of us used chain links and tread links to form some sort of lift or
> conveyor, but no two people came up with the same system. The downside of
> this
> method is that LEGO chain links (& especially tread links) tend to be
> uncommon.
> At the other extreme, I've built one module that lifts balls at around 2-3
> bps,
> but uses only system bricks and slopes with the exception of 1 technic
> beam, an
> axle, a technic plate or two, & the gears used to drive the system.
Yes, Rebelscum has a very interesting set shown: 7258 Wookiee Attack. It's
an Episode III set, so there is no telling what will happen if the sets
contain what the pic shows of these sets. Technic Link Tread*, if I am
reading that preview pic right. I imagine it would be popular if that's
really the case - I know I am going to try and get a lot of them myself if
it really does have the Technic Link Tread. ;)
> For other ideas, check out SMART's Crate Contraption... or do a
> Brickshelf
> search on the word "marble" (the Rolling Ball Clock is an example here)...
> or do
> a Google search for "rolling ball machines" or sculptures. There is a HUGE
> amount of inspiration out there for this type of thing.
Wonderful, if I can find some spare time in between my current project and
playing a favourite old game of mine, I might just do that. ;-)
> *about that list. I really can spell better than that.
*About the Technic Link Tread, that's the Bricklink catalog reference for
it.
Cheers ...
Geoffrey Hyde
|
|
| |
In lugnet.robotics, Geoffrey Hyde wrote:
> > and there's several of the lift mechanisms
> > in the video that are not in my list...
>
> Hmm I must have missed that list post.
The list is on Steve's GBC page, below the Type I standard - just scroll
down.
--
Brian Davis
|
|
| |
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. :)
|
|
| |
> Russell Nelson <nelson@crynwr.com> wrote on 01/09/2005 04:20:10 PM:
>
> > 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.
>
> Or not: leave the standard as it is (except for specifying that the space
> above the input belongs to the previous module), and have the organizers
> build (or specificially request) out-of-spec modules to accomplish this.
Or create other "Types" That's the long-term plan.
Of course, any GBC that uses some of these other module types will require
considerabily more planning prior to set-up, and it will also make the whole
contraption less tolerant to the "weak-link" modules.
For example, if the whole contraption is laid out, and the splitter module doesn't
function, the whole contraption will not be able to run.
> That way, you don't have to worry about too many Y's and not enough
> straight pieces! :)
Yes, that's something to consider. It's possible everyone would create a 90 degree
left-hand turn. Then what? :)
>
> Here we're talking about moving, intelligent systems that I'm sure make a
> number of assumptions that will not be easy to reconfigure on the fly.
> Hence, having a specification that allows those assumptions be made with a
> minimum of fuss seems like a strong point, not something that needs
> adjustment...
right.
Steve
|
|
| |
In lugnet.robotics, Russell Nelson <nelson@crynwr.com> wrote:
> Speaking of which, you should probably add a
> requirement that the top of the input bin must
> always be unobstructed. That is, the output
> part of a module gets to do anything it wants
> with the space over the input part of the
> next module.
Instead of that, just make sure that your module delivers through the "side"
of the downstream module's territory. In other words, using a chute (even a very
short one) is a pretty easy solution. And that way the standard isn't further
complicated. At least one practical reason for this is for a Type II
(crate-passing) standard, allocating the space above your neighbor's input crate
zone might really limit the solutions.
--
Brian Davis
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> Hidden somewhere on the page above, it says I can suppily you with soccer balls.
> Thanks to Christina, I have exactly enough to suppily EVERYONE with soccer balls.
> If I run short, I'll just talk with Larry... :)
Who will promptly tell you to talk to Nik. They're his, not mine. However I
CERTAINLY will be advising him to hold out for good space parts in trade. :)
I might have to see if we can build one or two of these, seems like good fun. I
might even try to see if I can use the MOST RCXs... since the least (0) has
already been done.
To the point of standards extension, I guess I would argue that just getting
this to work right the first (massively public, I know Steve and friends did
this already) time suggests that sticking to type I the first go might be a good
approach. If some wizards want to try their hand at 90s or 180s or
splitters/joiners that's all well and good but if they do not get into the
layout, so be it.
That's my view anyway. Not that I have a lot of street cred here.
|
|
| |
> Steve Hassenplug wrote:
>
> > > That way, you don't have to worry about too many Y's and not enough
> > > straight pieces! :)
> >
> >
> > Yes, that's something to consider. It's possible everyone would create a 90
> > degree
> > left-hand turn. Then what? :)
>
> I think you can handle this with a little care in the design of the
> rules.
Actually, it's pretty interesting, if you consider how complex making a pair of
turns really is. If you make a 90 degree right hand turn on a 32x32 baseplate, the
module must output right next to it's own input. But, bins on a left-hand turn are
on opposite corners of the plate.
Again, a big problem comes when one of the turns don't "work". So, if you have
exactly four turns (two right, two left) and one doesn't work, then none of them can
be used.
In any case, there's not much you can do on two modules that you can't do on one,
more complex module. For example, the splitter/combiner could be built as one
module.
Even things like my "train" can be laid out as "one module". By switching the
direction of the train, instead of taking balls back to the beginning, it can just
carry them and deliver them to the next module downstream.
One challenge would be to make a module that can be configured as a straight
pass-through OR a turn.
At this point, we're not interested in making the standard more complex, and
increasing the difficulty of setting it up, when it really doesn't add any
functionality to the whole contraption.
Steve
|
|
| |
"Steve Hassenplug" <Steve@TeamHassenplug.org> wrote:
> Actually, it's pretty interesting, if you consider how complex making a
> pair of
> turns really is. If you make a 90 degree right hand turn on a 32x32
> baseplate, the
> module must output right next to it's own input. But, bins on a left-hand
> turn are
> on opposite corners of the plate.
Why not universalize the standard so that a module that can turn must be
configurable to turn either to the left or the right? A few ways this could
be done are movable output stages, EG a sliding or drop-in output that can
be placed where needed.
> Again, a big problem comes when one of the turns don't "work". So, if you
> have
> exactly four turns (two right, two left) and one doesn't work, then none
> of them can
> be used.
Have the standard changed so that a module that can turn must also accept a
feed from the back if needed.
> In any case, there's not much you can do on two modules that you can't do
> on one,
> more complex module. For example, the splitter/combiner could be built as
> one
> module.
Question on the splitter/combiner modules, will there be rules for what
modules can be placed before/after them? Obviously it's not going to be
much use if someone builds a mechanical feeder that doesn't care what balls
it passes on unless there's a splitter/combiner module ahead of it, and not
one behind it.
> Even things like my "train" can be laid out as "one module". By switching
> the
> direction of the train, instead of taking balls back to the beginning, it
> can just
> carry them and deliver them to the next module downstream.
The only problem I can see there is that a module which expects the train
will have to be equipped with a holding crate which can hold a certain
number of balls, if there are going to be multiple pickup and delivery
points, in case a train is overfilled for some reason.
> One challenge would be to make a module that can be configured as a
> straight
> pass-through OR a turn.
That's not so much a challenge as a necessity. If all modules had standard
left-feed and straight-feed rules to obey, you could theoretically make any
module into a turn module without any trouble at all, as per my earlier
statement above.
> At this point, we're not interested in making the standard more complex,
> and
> increasing the difficulty of setting it up, when it really doesn't add any
> functionality to the whole contraption.
Well, perhaps some things need more complexity, although I would agree a
standard anyone can use is preferable. The big challenge is getting the
degree of complexity as best you can for all parties which will be involved.
Cheers ...
Geoffrey Hyde
|
|
| |
Brian Davis writes:
> Instead of that, just make sure that your module delivers through
> the "side" of the downstream module's territory.
Then the spec should say that the ball should go through a vertical
plane, and specify the size of the opening.
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
tmassey@obscorp.com writes:
> Or not: leave the standard as it is (except for specifying that the space
> above the input belongs to the previous module), and have the organizers
> build (or specificially request) out-of-spec modules to accomplish this.
I agree with the principle of simplicity. I notice that the spec
implicitly allows you to make an interior corner simply by rotating
the input bin by 90 degrees clockwise as viewed from above. Any
module which has its input bin in the corner of its module will work
this way. After all, the specification specifies the output in terms
of a horizontal plane, and *doesn't* specify the path of the ball as
it goes through the opening in the plane.
So every module is an interior corner module already! And if you have
four people build their modules on a 32x32 baseplate with input and
output boxes to match, you have a continuous loop.
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
Steve Baker writes:
> So simply write into the rules that everyone who submits a left hand
> turn has to submit a corresponding right hand turn or they won't
> be accepted.
Excellent idea! But it's even easier than that!! Do NOT change the
specification on this account. It's not necessary! If somebody wants
to make a single module which can be split into a right-hand turn and
left-hand turn, they can do it without any change in the spec. Their
module will simply have its own (spec-conforming) internal pair of
input and output boxes that happens to be at right angles to the rest
of the Contraption.
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
> > At this point, we're not interested in making the standard more complex,
> > and
> > increasing the difficulty of setting it up, when it really doesn't add any
> > functionality to the whole contraption.
>
> Well, perhaps some things need more complexity, although I would agree a
> standard anyone can use is preferable. The big challenge is getting the
> degree of complexity as best you can for all parties which will be involved.
>
> Geoffrey Hyde
Is there something that a module builder can not do because the standard is too simple?
Steve
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> > > At this point, we're not interested in making the standard more complex,
> > > and
> > > increasing the difficulty of setting it up, when it really doesn't add any
> > > functionality to the whole contraption.
> >
> > Well, perhaps some things need more complexity, although I would agree a
> > standard anyone can use is preferable. The big challenge is getting the
> > degree of complexity as best you can for all parties which will be involved.
> >
> > Geoffrey Hyde
>
>
> Is there something that a module builder can not do because the standard is too simple?
>
> Steve
Not to oversimplify, but I mean if the 'standard' for the ball contraption is 32
studs from the front of the hopper to the back edge of the baseplate, and thus I
personally would probably grab a 32 x 32 stud baseplate to build on, thus the
'in' hopper would be in the bottom left hand corner anyway, wouldn't my module,
by its very nature, be able to be placed 'in line' with the other ones, or 90
degrees, placing the hopper in the same location?
I think that making 90 degree turns (only to the right) would be able to be done
on many modules, just the way they are--phenominal ASCII graphix below!
XXXXXXXXXXYYYYYYYYYY
X XY Y
X XY Y
X XY Y
X XY Y
OOO XOOO YOOO
O O XO O YO O
OOOXXXXXXXOOOYYYYYYYOOO
XXXXXXXXXX
X X
X X
X X
X X
OOO XOOOYYYYYYY
O O XO O Y
OOOXXXXXXXOOO Y
Y Y
Y Y
Y Y
Y Y
YYYYYYYYYY
OOO
O O
OOO
X-Module 1
Y-Module 2
O-Input/Output Bin
See, if you leave both 'outer edges' of the bin open, both orientations work
But maybe I'm missing something.
Dave K
|
|
| |
In lugnet.robotics, tmassey@obscorp.com wrote:
> news-gateway@lugnet.com wrote on 01/10/2005 10:01:48 AM:
>
> > > Is there something that a module builder can not do because the
> > standard is too simple?
> >
> > Not to oversimplify, but I mean if the 'standard' for the ball
> > contraption is 32
> > studs from the front of the hopper to the back edge of the
> > baseplate, and thus I
> > personally would probably grab a 32 x 32 stud baseplate to build on, thus the
> > 'in' hopper would be in the bottom left hand corner anyway, wouldn'tmy module,
> > by its very nature, be able to be placed 'in line' with the other ones, or 90
> > degrees, placing the hopper in the same location?
>
> That assumes that there is nothing in front of the hopper. There is
> nothing to say that you are limited to a module 32 studs deep. If you
> choose to build it that way, great, but there is nothing that says you
> can't build a 3-foot-deep module (and according to the spec, that *should*
> be longer than deep, so it would have to be at *least* 3 feet long!). In
> that case, it could not turn the corner as you've described.
>
> However, to me, that's even more reason to leave the spec alone. You have
> described a simple way to make a spec-compliant module that makes right
> corners. Therefore, there is no reason to define corner pieces! They're
> already defined! :)
>
> Tim Massey
I completely agree with that assessment. However, the premise is that I'm using
a 32x32 baseplate with the hopper in the bottom left hand corner--using that
premise, the module can be used either in-line, or 90 degrees. If one does not
use the 32x32 baseplate with the hooper in the bottom left-hand corner, then all
bets are off ;)
Dave K
|
|
| |
news-gateway@lugnet.com wrote on 01/10/2005 10:01:48 AM:
> > Is there something that a module builder can not do because the
> standard is too simple?
>
> Not to oversimplify, but I mean if the 'standard' for the ball
> contraption is 32
> studs from the front of the hopper to the back edge of the
> baseplate, and thus I
> personally would probably grab a 32 x 32 stud baseplate to build on, • thus the
> 'in' hopper would be in the bottom left hand corner anyway, wouldn'tmy • module,
> by its very nature, be able to be placed 'in line' with the other ones, • or 90
> degrees, placing the hopper in the same location?
That assumes that there is nothing in front of the hopper. There is
nothing to say that you are limited to a module 32 studs deep. If you
choose to build it that way, great, but there is nothing that says you
can't build a 3-foot-deep module (and according to the spec, that *should*
be longer than deep, so it would have to be at *least* 3 feet long!). In
that case, it could not turn the corner as you've described.
However, to me, that's even more reason to leave the spec alone. You have
described a simple way to make a spec-compliant module that makes right
corners. Therefore, there is no reason to define corner pieces! They're
already defined! :)
Tim Massey
|
|
| |
Steve Hassenplug writes:
> http://www.teamhassenplug.org/GBC/
I notice that the spec says "Currently, there is no standard for
physically connecting modules together." One possibility is for a
module to grab onto the two corner studs of the input bin of the
module to the right, since that's already a given.
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
> Steve Hassenplug writes:
> > http://www.teamhassenplug.org/GBC/
>
> I notice that the spec says "Currently, there is no standard for
> physically connecting modules together." One possibility is for a
> module to grab onto the two corner studs of the input bin of the
> module to the right, since that's already a given.
That's a good idea, which I don't think has been suggested, yet. However, that sort
of requires a module to have corner studs... :)
This module mostly uses liftarms:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1051690
As it turns out, I suspect 90% of the modules will not require interconnection, and
those that do, should be mounted on baseplates, or maybe we can just squeeze them
together with other modules...
Steve
|
|
| |
"Steve Hassenplug" <Steve@TeamHassenplug.org> wrote in message
> Is there something that a module builder can not do because the standard
> is too simple?
Yes. Currently it's not being able to make turns in both directions with
the hopper feed setup the way it is. Someone did point out that there would
be a lot of wasted space if there was a large assembly of machines. I think
standards should be there to be helpful, not cumbersome.
Cheers ...
Geoffrey Hyde
|
|
| |
>
> "Steve Hassenplug" <Steve@TeamHassenplug.org> wrote in message
>
> > Is there something that a module builder can not do because the standard
> > is too simple?
>
> Yes. Currently it's not being able to make turns in both directions with
> the hopper feed setup the way it is.
That's really not true. As a module builder, you can make all the turns you want.
This one makes a whole bunch:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1049772
If you can't figure out how to put the output in the correct place, with respect to
the input, that's not a problem with the standard.
See, there are two different things being talked about here.
A) Before Brickfest, many people will be building modules for the GBC
B) At Brickfest, we'll be assembling the modules to create a complete Great Ball
Contraption.
(A) should be possible, no matter how the input/output is arranged.
And, I have no doubt when we're at Brickfest we will succeed at (B), given the
current standard. Adding turns and things will only make that much more difficult.
If people are not able to make standard modules, that will be a bummer. But, I
don't really see it as a issue.
Steve
|
|
| |
Russell Nelson <nelson@crynwr.com> wrote on 01/10/2005 12:03:04 PM:
> Steve Hassenplug writes:
> > http://www.teamhassenplug.org/GBC/
>
> I notice that the spec says "Currently, there is no standard for
> physically connecting modules together." One possibility is for a
> module to grab onto the two corner studs of the input bin of the
> module to the right, since that's already a given.
Or specify that the input bin must have a technic beam at the front edge
of the input bin to accept technic pins: this is very similar to how the
castle walls connect...
Tim Massey
|
|
| |
tmassey@obscorp.com writes:
> Or specify that the input bin must have a technic beam at the front edge
> of the input bin to accept technic pins: this is very similar to how the
> castle walls connect...
Excellent idea. What do you mean, though, by "front edge"? Do you
mean the beam which is 10 studs long and which is 10 bricks off the
tabletop? That would impose a requirement on the next-door module to
build up and reinforce a wall 10 bricks high. Many of the prototype
GBC modules either throw or dump the ball into the input bin, with
nothing abutting its front edge.
Wouldn't it be better to have this beam be one brick off the tabletop
(leaving room for a baseplate and spacers adding up to one brick)?
That would reduce the requirements on a module and 2) reduce the
amount of levering action.
In any case, it's perfectly optional. If one module implements it and
another doesn't, then you just remove the technic pins. Yes,
excellent idea, well done, Tim!
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
> tmassey@obscorp.com writes:
> > Or specify that the input bin must have a technic beam at the front edge
> > of the input bin to accept technic pins: this is very similar to how the
> > castle walls connect...
>
> Excellent idea. What do you mean, though, by "front edge"? Do you
> mean the beam which is 10 studs long and which is 10 bricks off the
> tabletop? That would impose a requirement on the next-door module to
> build up and reinforce a wall 10 bricks high. Many of the prototype
> GBC modules either throw or dump the ball into the input bin, with
> nothing abutting its front edge.
I'm still a bit torn on this. There is NO interconnection type that will work with
all the modules we already have (only 10 or 12) but not all need to be
interconnected. The connection is only required in a few cases (where modules are
moving enough mass to slide on the table).
One idea is to use a couple 2x4 plates to connect baseplates together. But not all
modules have baseplates.
With Tim's idea, the modules would need to be connected by adding a beam to the
"front", not connecting "between" the modules, otherwise if you need to remove a
module from the middle, it will take a great deal of work to get them apart.
We're having another gathering this weekend, so I'll have more info after that.
Steve
|
|
| |
Russell Nelson <nelson@crynwr.com> wrote on 01/11/2005 04:25:15 PM:
> tmassey@obscorp.com writes:
> > Or specify that the input bin must have a technic beam at the front • edge
> > of the input bin to accept technic pins: this is very similar to how • the
> > castle walls connect...
>
> Wouldn't it be better to have this beam be one brick off the tabletop
> (leaving room for a baseplate and spacers adding up to one brick)?
> That would reduce the requirements on a module and 2) reduce the
> amount of levering action.
Yes, yes it would! :)
Tim Massey
|
|
| |
In lugnet.robotics, Brian Davis wrote:
(snip)
>
> Use your imagination! One of the reasons Steve included my (huge, poorly
> spelled, not-yet-ready-for-primetime) list was to show the options that just
> a few people could come up with... and there's several of the lift
> mechanisms inthe video that are not in my list*, so long as it is, it is
> hardly complete! • (snip)
> For other ideas, check out SMART's Crate Contraption... or do a
> Brickshelf search on the word "marble" (the Rolling Ball Clock is an example
> here)... or do a Google search for "rolling ball machines" or sculptures.
> There is a HUGE amount of inspiration out there for this type of thing.
>
> *about that list. I really can spell better than that.
Another awesome source which you may want to link the main page to is:
<http://www.kugelbahn.info/deutsch/haupt/einl.html>
While not in English, it does contain animations of nearly every idea on the
list. Wow!
You can get a rough auto-translation at:
<http://www.worldlingo.com/en/websites/url_translator.html>
Paste in the site's address, select German to English, and wait a few moments.
This is a great idea, Steve (et al)! I am already thinking of how to modify my
LEGO ball pump to fit the standard.
Rick C.
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> In an attempt to provide Technic & Mindstorms builders the same cooperative
> building opportunity that's available to Moonbase, Castle, and Town/Train
> builders at Brickfest, we present to you: The Great Ball Contraption. • (snip)
> And, a 92 second video (15mb)... priceless. Here's one ball passing through
> our entire 10 module test assembly.
> http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbconeball.mpg
Really neat!! Looking forward to getting into this!
I'm particularly interested in construction details of the hopper car and
dumping mechanism. More photos, etc would be greatly appreciated. I've been
trying to build a hopper that can be unloaded mechanically, without much success
(but plenty of frustration). Your solution seems simple and reliable.
Thanks!
FUT lugnet.trains
Rick C.
|
|
| |
In lugnet.robotics, Rick Clark wrote:
> > do a Google search for "rolling ball machines"
>
> Another awesome source which you may want to link
> the main page to is:
> <http://www.kugelbahn.info/deutsch/haupt/einl.html>
Thank you! I found this page ages ago when trying to find an easy way to
build a step feeder (I've wanted to build one ever since a certain Playful
Penguin thread in rtlToronto), and it inspired me to start a list, but I
couldn't relocate it!
> While not in English, it does contain animations
> of nearly every idea on the list. Wow!
Additionally, he gives lots of examples, including (for at least some of
them) ones he built out of LEGO! For the folks that have asked about Steve's
step feeder, I think he may have based this of a design I built, but I lifted
the idea for a LEGO version from these pages. It's a great resource!
I really need to update and refine my list, put in this (& other) URLs, and
include a "tips & tricks" section. But I'm having too much fun building!
> I am already thinking of how to modify my
> LEGO ball pump to fit the standard.
The biggest problem I've had with ball pumps (I've got two sitting above my
fireplace right now) is room below the input hopper "floor". The designs I've
build require a cycling piston below the floor of the input hopper, and that
takes up a good bit of vertical room (when the top of the input bin can only be
9-10 brick heights off the baseplate). I can do it... but the resulting input
bin ends up rather shallow, so I have to make it long to hold a "pulse" of 20-30
balls.
--
Brian Davis
|
|
| |
Greetings Steve Hassenplug, Brian Alano and others,
What an incredible idea. I wish I was able to attend so I could participate.
I wanted to let you know that I posted some updated pictures including a .avi
video clip (10Mb) of my marble factory as referenced on Brian's GBC Index page:
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=112880
I'm looking forward to seeing the final product from brickfest.
Roy Nelson
|
|
| |
Would it be possible to get a closeup shot of the conveyor, and the linkarm
assembly it feeds into with all those gears?
What I'd really like to know is how you interleaved the linkarms (which look
suspiciously like 3-arm rotor blade pieces) to me) so that they all shift
the marbles across without jamming up.
Do you think this assembly could be adapted to handle soccer balls and
input/output feeds?
Cheers ...
Geoffrey Hyde
"Roy Nelson" <legoroy@telus.net> wrote in message
news:IAFs81.1Ko6@lugnet.com...
> Greetings Steve Hassenplug, Brian Alano and others,
>
> What an incredible idea. I wish I was able to attend so I could
> participate.
>
> I wanted to let you know that I posted some updated pictures including a
> .avi
> video clip (10Mb) of my marble factory as referenced on Brian's GBC Index
> page:
>
> http://www.brickshelf.com/cgi-bin/gallery.cgi?f=112880
>
> I'm looking forward to seeing the final product from brickfest.
>
> Roy Nelson
|
|
| |
In lugnet.robotics, Geoffrey Hyde wrote:
> Would it be possible to get a closeup shot of the conveyor, and the linkarm
> assembly it feeds into with all those gears?
Done. http://www.brickshelf.com/cgi-bin/gallery.cgi?f=112880
> What I'd really like to know is how you interleaved the linkarms (which look
> suspiciously like 3-arm rotor blade pieces to me) so that they all shift
> the marbles across without jamming up.
On each axle I used four 3-long linkarms. The link arms are positioned in such a
way that they never rub against eachother. I have made another link-arm passer
that uses one 4-long linkarm per axle. The linkarms do rub slightly as they pass
but I've been able to adjust it so that it does not catch.
> Do you think this assembly could be adapted to handle soccer balls and
> input/output feeds?
I did a quick test and they soccer balls do work. Overall I think soccer balls
are easier to use than marbles. I have spent many hours finding and sorting
marbles that have a diameter that is less than a 2x2 brick...but marbles have
nicer weight and colour.
Roy
|
|
| |
"Roy Nelson" <legoroy@telus.net> wrote in message
news:IAH1Kr.7vn@lugnet.com...
> In lugnet.robotics, Geoffrey Hyde wrote:
> > Would it be possible to get a closeup shot of the conveyor, and the
> > linkarm
> > assembly it feeds into with all those gears?
>
> Done. http://www.brickshelf.com/cgi-bin/gallery.cgi?f=112880
Nice work, eventually, I think you should get close-ups of each part the
marbles run through, I especially liked the mechanism you used to bring the
marbles up from the large antenna dish they collected at onto the conveyor
belt, while at the same time spacing them out a bit.
> > What I'd really like to know is how you interleaved the linkarms (which
> > look
> > suspiciously like 3-arm rotor blade pieces to me) so that they all shift
> > the marbles across without jamming up.
>
> On each axle I used four 3-long linkarms. The link arms are positioned in
> such a
> way that they never rub against eachother. I have made another link-arm
> passer
> that uses one 4-long linkarm per axle. The linkarms do rub slightly as
> they pass
> but I've been able to adjust it so that it does not catch.
I see - that sounds like a way to economize somewhat if you run out of
Technic Link Tread, as bricklink calls it. It is also a way to stop the
marbles from running into each other too much so that they start collecting
somwhere.
> > Do you think this assembly could be adapted to handle soccer balls and
> > input/output feeds?
>
> I did a quick test and they soccer balls do work. Overall I think soccer
> balls
> are easier to use than marbles. I have spent many hours finding and
> sorting
> marbles that have a diameter that is less than a 2x2 brick...but marbles
> have
> nicer weight and colour.
What you should do is find a way to handle oversized marbles too, either a
simple grading mechanism, or something that 'rejects' oversized marbles.
You could make a more complicated assembly that loops the marbles from one
hopper to another, and back again, all in a continuous never-ending flow.
Cheers ...
Geoffrey Hyde
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> In an attempt to provide Technic & Mindstorms builders the same cooperative
> building opportunity that's available to Moonbase, Castle, and Town/Train
> builders at Brickfest, we present to you: The Great Ball Contraption. • ...
> Keep in mind, that was built by me, and just a couple friends. Imagine the
> madness when AFoLs from all over contribute their modules to one of the greatest
> works of moving LEGO artwork ever assembled...
>
> To learn more, check out the web site:
> http://www.teamhassenplug.org/GBC/
>
> Or if you have questions, feel free to post here.
But wait, there's more...
First, a friend (another Bryan) came over with his module, and then the next
day, we had a club meeting, where our whole LEGO club had modules. After
running Bryan's for a bit, I considered adding a "Maximum ball velocity" to the
Type 1 spec.
Bryan's Amusement park from heck...
... uses an RC buggy motor, spinning a liftarm to 'bat' balls up a slope. Due
to misfires, they didn't always make it up the slope, so he had to help them.
This clip also includes a good shot of the train, traveling point-to-point.
While you can see balls flying all over the place, no children, or windows were
damaged during the making of this video.
http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbc-bryanb.mpg (6mb)
This video brought to you by Sprite. Obey your thurst.
Next, we configured the train to travel in a loop around the table, with all the
modules in the middle. I should note that the train CAN be configured as a
standard module, with 1 input, and 1 output in a straight line.
Luckily, this time, we had plenty of help finding stray balls...
http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbc-loop.mpg (13mb)
Other info on the train: It's controlled by an RCX. Each station has 1 touch
sensor (attached to a wheel) that the train hits when it passes. (
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1068031 ) In the above video,
the train is traveling at 1/4 speed. After the touch sensor is pressed, the
train stops for 1/2 second, then backs up at 1/8 speed until the touch sensor is
pressed, again. Then, the unloading motor runs, until the "unload" touch sensor
is pressed, at which point, the train dumps. It waits for 1 second, then the
unload motor runs until the touch sensor is not pressed. Then, the train goes
to back to the loading station, where the loading motor runs for 7 seconds. At
that point, the train waits for what's left of 30 seconds, so the whole loop
always takes 30 seconds.
Also shown is a brown pneumatic module, which has a small compressor that runs
continuously, and two cylinder/switch pairs that flip each other.
On Sunday, our whole group got together. Here are some pictures:
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=113135
And a short video. The clicking sound in the background is Bryan's module
shooting balls:
http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbc2short.mpg (2mb)
And, a somewhat detailed video.
http://www.brickshelf.com/gallery/Hassenplug/GBC/Video/gbcv2.mpg (36mb)
As you can see, there are about 17 modules, built by 10 different builders.
If you want to know more details, feel free to ask,
Steve
|
|
| |
What’s funny is the other day I was thinking of building a marble machine with
LEGO. After reading about this contraption system, I got super-motivated and
built myself a ball pump last night. I only spent a few hours on it, but I think
I have it pretty much perfected . . . it’s jam-proof if the marbles come once
every second or so. And even if it does jam, a clutch gear protects my old 9V
motor (which is geared down considerably). It’s built pretty solidly; all I have
to test my stuff are glass marbles, which are pretty heavy in large numbers.
Tonight I started a few conveyor belt designs, and keeping tension in the tread
links is proving difficult. Any ideas on how to do that?
I’m also working on a rollercoaster-type track with the ribbed tubes from my
Mindstorms sets. Building a framework to support it is trickier than I thought
it would be.
I definitely plan to attend Brickfest to add my contribution to the Great Ball
Contraption. I’m going to need someone to send me some soccer balls, please. I
don’t have any LEGO Sports stuff at all.
One suggestion for people: I don’t like mystery mechanisms. I like to see how
stuff works, so please build your stuff with as many internal parts visible as
possible. For example, the stairs are mysterious until you see them from the
bottom -- a cam shaft is the secret. Get rid of the walls and I’ll be happier.
:)
|
|
| |
In lugnet.robotics, Jordan Bradford wrote:
| |
I got super-motivated and built myself a
ball pump last night.
|
Wow, nearly untouched territory... pumping Steve’s... oh, never mind.
On a more pratical note, does your pump meet the height requirement for the GBC?
I’ve got two ball pumps working, but both have the same problem - allowing room
under the hopper for the piston mechanism makes it hard to have a deep hopper
(and I’d really hate to use a “high hopper” for the ball pump that has to be
filled from the standard input via another mechanism).
| |
it’s jam-proof if the marbles come once every
second or so.
|
Mine has no problem with jamming, but occassionally problems with “clotting” in
the hopper starving the pump itself. Can yours handle a crate of balls dumped
all at once? I wonder what the ultimate percentage of “continuous output” vs.
“batch output” modules will end up at.
| |
keeping tension in the tread links is proving
difficult. Any ideas on how to do that?
|
If you need constant tension, one way to do it is tensioner. A third gear in the
chain, that can be moved in and out changing the shape (& therefore length) of
the triangular chain path. This doesn’t have to be hand-tuned either - use a
idler gear on a small free-swingin arm that is held in tension by a weight or
rubber band.
| |
One suggestion for people: I don’t like mystery
mechanisms.
|
Well, one of the ball pump designs I’ve built can have one side of the
mechanism built out of clear panels... that is, if I could *get* any of them.
After I built it, I found S@H had run out, and Bricklink has (currently) *one*.
Sigh... Also, most of my designs are ending up rather skeletal, due to the lack
of pieces left for building.
--
Brian Davis
|
|
| |
> I definitely plan to attend Brickfest to add my contribution to the Great Ball
> Contraption.
We look forward to seeing you there...
> I'm going to need someone to send me some soccer balls, please. I
> don't have any LEGO Sports stuff at all.
E-mail me your address.
> One suggestion for people: I don't like mystery mechanisms. I like to see how
> stuff works, so please build your stuff with as many internal parts visible as
> possible. For example, the stairs are mysterious until you see them from the
> bottom -- a cam shaft is the secret. Get rid of the walls and I'll be happier.
I really like to build my stuff with a very clean look. That usually means hiding
all the inner workings. That's why the stairs looked like this in my first build:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1055888
However, when I rebuilt it to be 32x10, I decided to open the bottom as much as
possible, to allow people to see in:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1068037
This gives it more of a "contraption" look to it.
Steve
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
(snip)
> Other info on the train: It's controlled by an RCX.
(snip)
Nevermind the controls, how'd you build the hopper? ;-) I really like your
solution, with the rotating arm that unloads it, creating an auto-reset for the
hopper. I've been frustrated several times trying to build something like this
and would love additional construction details on the hopper car. Where's the
pivot point? How's it mounted?
More photos and etceteras, please!
Rick Clark
FUT lugnet.trains
|
|
| |
Keep up the great work guys! :)
Iain
|
|
| |
> In lugnet.robotics, Steve Hassenplug wrote:
> (snip)
> > Other info on the train: It's controlled by an RCX.
> (snip)
>
> Nevermind the controls, how'd you build the hopper? ;-)
Alright, alright... :)
> I really like your
> solution, with the rotating arm that unloads it, creating an auto-reset for the
> hopper. I've been frustrated several times trying to build something like this
> and would love additional construction details on the hopper car. Where's the
> pivot point? How's it mounted?
>
> More photos and etceteras, please!
I originally planned to have the "dump arm" activate when the train moved
forward/back into the station. But, I found it took too much pressure to get it to
dump. (the train had to be going fast) Not sure if my explaination is clear, but
that's why the car is not symetrical. The black area in the right of this picture:
http://www.brickshelf.com/gallery/Hassenplug/GBC/Train/p1200048.jpg
was for a 90 degree gear.
As you've seen, I replaced that with an arm that pushes down, putting very little
sideways pressure on the car:
http://www.brickshelf.com/gallery/Hassenplug/GBC/Train/p1200059.jpg
The pivot is located slightly off center, so when the dump arm isn't pressed, it
falls back to rest on some tiles (on one side)
http://www.brickshelf.com/gallery/Hassenplug/GBC/Train/p1200055.jpg
I also wanted to keep the pivot low enough, so the top of the hopper would act as a
ramp, and my unloading ramp didn't need to be right against the track:
http://www.brickshelf.com/gallery/Hassenplug/GBC/Train/p1200052.jpg
Here's another shot of where the pivot is located:
http://www.brickshelf.com/gallery/Hassenplug/GBC/Train/p1200057.jpg
And it also shows the liftarm use to keep it from dumping too far.
The only problem with this car is the plates on the bottom start to come loose after
extended dumping of soccer balls. Usually, just enough to prevent dumping. But,
it's not a big enough problem to warrant rebuilding. It really takes a while for
them to work loose
Here's all the pictures: (when moderated)
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=111336
This car will hold almost 60 soccer balls.
If that's not enough text or pictures, just ask for more...
Steve
|
|
| |
In lugnet.robotics, Brian Davis wrote:
| |
In lugnet.robotics, Jordan Bradford wrote:
| |
I got super-motivated and built myself a
ball pump last night.
|
Wow, nearly untouched territory... pumping Steve’s... oh, never mind.
On a more pratical note, does your pump meet the height requirement for the
GBC? I’ve got two ball pumps working, but both have the same problem -
allowing room under the hopper for the piston mechanism makes it hard to have
a deep hopper (and I’d really hate to use a “high hopper” for the ball pump
that has to be filled from the standard input via another mechanism).
|
I don’t know if it fits into the standard or not. I didn’t plan on using it as
my first device, anyway. I’m going to build a simple large hopper for the
previous person’s contraption to feed into mine, and then I’ll have a feed chute
or something. Maybe I’ll use a conveyor/bucket mechanism to get balls out of the
initial input.
| |
| |
it’s jam-proof if the marbles come once every
second or so.
|
Mine has no problem with jamming, but occassionally problems with “clotting”
in the hopper starving the pump itself. Can yours handle a crate of balls
dumped all at once? I wonder what the ultimate percentage of “continuous
output” vs. “batch output” modules will end up at.
|
My tiny little “hopper” for the pump does “clot” as you say, which is a problem
everyone’s going to encounter sooner or later. But I can guarantee nothing will
get stuck if the balls come one at a time.
| |
| |
keeping tension in the tread links is proving
difficult. Any ideas on how to do that?
|
If you need constant tension, one way to do it is tensioner. A third gear in
the chain, that can be moved in and out changing the shape (& therefore
length) of the triangular chain path. This doesn’t have to be hand-tuned
either - use a idler gear on a small free-swingin arm that is held in tension
by a weight or rubber band.
|
Heh, once again my over-engineering defeats me. I tried using two shock
absorbers to push a gear into the hanging part of the chain, but they just
torqued the gear so that the chain wouldn’t move. I should always try the
simplest approach from now on. Thanks for the tip.
| |
| |
One suggestion for people: I don’t like mystery
mechanisms.
|
Well, one of the ball pump designs I’ve built can have one side of the
mechanism built out of clear panels... that is, if I could *get* any of them.
After I built it, I found S@H had run out, and Bricklink has (currently)
*one*. Sigh... Also, most of my designs are ending up rather skeletal, due to
the lack of pieces left for building.
|
Lack of parts. Yep. Most of my contraptions will be skeletal for the same
reason. However, I have a 4561 (4160), and that has a lot of transparent panels
for the windows. I used one of those for the part of the pump that I think
people would consider mysterious. Now they can see each ball being lowered under
the column of balls and pushed up into it.
|
|
| |
> > > keeping tension in the tread links is proving
> > > difficult. Any ideas on how to do that?
> >
> > If you need constant tension, one way to do it is tensioner. A third gear in
> > the chain, that can be moved in and out changing the shape (& therefore
> > length) of the triangular chain path. This doesn't have to be hand-tuned
> > either - use a idler gear on a small free-swingin arm that is held in tension
> > by a weight or rubber band.
>
> Heh, once again my over-engineering defeats me. I tried using two shock
> absorbers to push a gear into the hanging part of the chain, but they just
> torqued the gear so that the chain wouldn't move. I should always try the
> simplest approach from now on. Thanks for the tip.
I'm not exactly sure how many "teeth" = 1 stud, but I know it's not a whole number.
So, I've found if you can change the length by 1 or 2 studs, and add a few chain
links, you don't need to add a tensioner.
Steve
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> I'm not exactly sure how many "teeth" = 1 stud, but I know it's not a whole number.
It's exactly 2.5. 10 teeth on a gear rack, divided by 4.
Steve
|
|
| |
In lugnet.robotics, Steve Lane wrote:
| |
In lugnet.robotics, Steve Hassenplug wrote:
| |
I’m not exactly sure how many “teeth” = 1 stud, but I know it’s not a whole
number.
|
It’s exactly 2.5. 10 teeth on a gear rack, divided by 4.
Steve
|
I’m using two upside-down 1x16 TECHNIC beams to straddle 24-tooth gears on each
end (see my great ASCII art below, top-down view, not to scale). I might not
even need tension in the chain at all; the tread links slide on the flat bottom
part of the beams, and that seems to work fine. I haven’t yet built a support
structure to test the chain for real.
*
[]*[]
[]*[]
[] []
[] []
[] []
[] []
[] []
[] []
[] []
[] []
[]*[]
[]*[]
*
My “buckets” are simple and work pretty well, even at steep angles. Every fourth
tread link has a 1x4 plate on it, and on each plate are two of those 2x2
right-angle plates making a squarish area for the ball to rest in. Again, some
beautiful ASCII art:
Step 1:
_______
|_______| <- that's a 1x4 plate
Step 2:
_ _
| |_ _| |
|___|___| <- those are right-angle plates
What other bucket designs do people have?
|
|
| |
> In lugnet.robotics, Steve Lane wrote:
> > In lugnet.robotics, Steve Hassenplug wrote:
> >
> > > I'm not exactly sure how many "teeth" = 1 stud, but I know it's not a whole
> > > number.
> >
> > It's exactly 2.5. 10 teeth on a gear rack, divided by 4.
> >
> > Steve
>
> I'm using two upside-down 1x16 TECHNIC beams to straddle 24-tooth gears on each
> end (see my great ASCII art below, top-down view, not to scale). I might not
> even need tension in the chain at all; the tread links slide on the flat bottom
> part of the beams, and that seems to work fine. I haven't yet built a support
> structure to test the chain for real.
Well, my lift for loading the train car uses both chain links, and tracks. Each
track has a 1x4 tile on it, and the balls roll up.
http://www.brickshelf.com/gallery/Hassenplug/GBC/GBC2/p1160046.jpg
That's close to what John did on his roller coaster:
http://www.brickshelf.com/gallery/Hassenplug/GBC/05johnrollercoaster.jpg
This red module: http://www.brickshelf.com/gallery/Hassenplug/GBC/10stevechainlift.jpg
uses a pair of axle joiners: http://www.peeron.com/inv/parts/6536 with some #3
axles. Brian came up with this, and it works very well.
|
|
| |
In lugnet.robotics, Jordan Bradford wrote:
| |
In lugnet.robotics, Steve Lane wrote:
| |
In lugnet.robotics, Steve Hassenplug wrote:
| |
I’m not exactly sure how many “teeth” = 1 stud, but I know it’s not a whole
number.
|
It’s exactly 2.5. 10 teeth on a gear rack, divided by 4.
|
I’m using two upside-down 1x16 TECHNIC beams to straddle 24-tooth gears on
each end (see my great ASCII art below, top-down view, not to scale). I might
not even need tension in the chain at all; the tread links slide on the flat
bottom part of the beams, and that seems to work fine. I haven’t yet built a
support structure to test the chain for real.
|
I have just placed wheels regularly spaced along my chain to support it.
| |
My “buckets” are simple and work pretty well, even at steep angles. Every
fourth tread link has a 1x4 plate on it, and on each plate are two of those
2x2 right-angle plates making a squarish area for the ball to rest in. Again,
some beautiful ASCII art:
Step 1:
_______
|_______| <- that's a 1x4 plate
Step 2:
_ _
| |_ _| |
|___|___| <- those are right-angle plates
What other bucket designs do people have?
|
Mine are similar, but use a 1x3 plate with a 1x1 plate with tooth on each end,
at a slight angle, and another 1x3 plate on top. I was finding that even with an
accurate feeder, they were occasionally bouncing over the side when I used 1x2
plates on each end.
ROSCO
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> In an attempt to provide Technic & Mindstorms builders the same cooperative
> building opportunity that's available to Moonbase, Castle, and Town/Train
> builders at Brickfest, we present to you: The Great Ball Contraption.
>
> When it's assembled at Brickfest '05 (DC), The Great Ball Contraption will be
> made up of many modules by builders from all over the country, any beyond.
>
> This device will be a combination of Rube Goldberg and the Bucket Brigade,
> passing soccer balls from one module to the next, where they will be pushed,
> pulled, lifted, flipped, shot, rolled, dropped, etc... before being passed
> again.
>
> To learn more, check out the web site:
> http://www.teamhassenplug.org/GBC/
ho hum. another day, another Great Ball Contraption.
In our latest gathering, Tom invited us to his house. Turns out, we have more
ball contraptions than Tom has table space in his basement.
So, we moved the tables, and set-up on the floor. Of course the next problem
was that I couldn't fit the whole contraption in one picture.
So, here's two:
http://www.brickshelf.com/gallery/Hassenplug/GBC/GBC3/p1290087.jpg
http://www.brickshelf.com/gallery/Hassenplug/GBC/GBC3/p1290088.jpg
I have some video, but it appears brickshelf is blocking all video.
It's very interesting to note that all the modules conform to the spec. One of
the modules used to turn the stream has a movable input bin. The other has an
input bin set far enough out that a module can be placed behind it.
The "hot new module" for this gathering was John's Spybot controlled paddle
wheel. The wheel was driven from the Spybot, through a differential. If the
wheel got stuck, the differential would turn, releasing the touch sensor on the
Spybot. The Spybot would run the motor backward for 1 second, then continue
forward.
Steve
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
<SNIP>
> In our latest gathering, Tom invited us to his house. Turns out, we have more
> ball contraptions than Tom has table space in his basement.
>
> So, we moved the tables, and set-up on the floor. Of course the next problem
> was that I couldn't fit the whole contraption in one picture.
>
> So, here's two:
> http://www.brickshelf.com/gallery/Hassenplug/GBC/GBC3/p1290087.jpg
> http://www.brickshelf.com/gallery/Hassenplug/GBC/GBC3/p1290088.jpg
SWEET!
>
> I have some video, but it appears brickshelf is blocking all video.
That's a bummer..
> It's very interesting to note that all the modules conform to the spec. One of
> the modules used to turn the stream has a movable input bin. The other has an
> input bin set far enough out that a module can be placed behind it.
>
> The "hot new module" for this gathering was John's Spybot controlled paddle
> wheel. The wheel was driven from the Spybot, through a differential. If the
> wheel got stuck, the differential would turn, releasing the touch sensor on the
> Spybot. The Spybot would run the motor backward for 1 second, then continue
> forward.
Very Nice..
>
> Steve
Hey Steve, how can I get in on one of these gatherings.. I have a mildly
spectacular module I'm working on right now.. I'd love to bring it once I get it
working right...
|
|
| |
> In lugnet.robotics, Steve Hassenplug wrote:
> > http://www.brickshelf.com/gallery/Hassenplug/GBC/GBC3/p1290087.jpg
> > http://www.brickshelf.com/gallery/Hassenplug/GBC/GBC3/p1290088.jpg
>
> Hey Steve, how can I get in on one of these gatherings.. I have a mildly
> spectacular module I'm working on right now.. I'd love to bring it once I get it
> working right...
Joe (and anyone else interested)
This is currently a project of the Lafayette LEGO Robotics Club in Lafayette,
Indiana. You're welcome to attend our meetings, which are held the 1st & 3rd Sunday
of the month, from 2-4 at the West Lafayette library (that's this Sunday).
You're very welcome to join us, even if you don't have anything to show (or anything
working). E-mail me for directions.
Steve
|
|
| |
Steve Hassenplug writes:
> ho hum. another day, another Great Ball Contraption.
Cool. I'd love to start a GBC activity here in Potsdam, but .... we
need a reliable source of bulk balls. It's nice of you to mail them
out to people, but we really need Lego to sell bulk balls. How do we
convince them to do it? Maybe we should create a fake Lego product,
the 2970 (to pick a number from the air), the Bulk Soccer Ball kit.
Then everybody calls S@H the same day and tries to order it.
--
--My blog is at angry-economist.russnelson.com | The laws of physics cannot
Crynwr sells support for free software | PGPok | be legislated. Neither can
521 Pleasant Valley Rd. | +1 315-323-1241 cell | the laws of countries.
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP |
|
|
| |
In lugnet.robotics, Russell Nelson <nelson@crynwr.com> wrote:
> I'd love to start a GBC activity here in Potsdam,
> but .... we need a reliable source of bulk balls.
Before Steve gave me some balls (oh, the straight lines...), I acquired
enough to run a few modules of my own from various Bricklink purchases. You
could do a GBC by simply mandating that everybody who wants to add to a GBC
brings there own supply of balls, but I think this project could tap out
Bricklink. But I agree, it would be nice if at least a few other folks could
acquire a large lot of soccer balls in other geographic regions.
> we really need Lego to sell bulk balls.
There is, I've heard tell, some PaB (not in the States, but UK IMS) that had
soccer balls for bulk sale. I know you can get a lot of soccer balls in a PaB
cup (a small cup here in the States holds about 180 - I don't have enough (yet!)
to tell how many a large PaB cup holds, but it looks to be around 300).
--
Brian Davis
|
|
| |
> In lugnet.robotics, Russell Nelson <nelson@crynwr.com> wrote:
>
> > I'd love to start a GBC activity here in Potsdam,
> > but .... we need a reliable source of bulk balls.
>
> Before Steve gave me some balls (oh, the straight lines...), I acquired
> enough to run a few modules of my own from various Bricklink purchases. You
> could do a GBC by simply mandating that everybody who wants to add to a GBC
> brings there own supply of balls, but I think this project could tap out
> Bricklink. But I agree, it would be nice if at least a few other folks could
> acquire a large lot of soccer balls in other geographic regions.
Well, I do have a very large suppily, and despite sending out hundreds of soccer
balls, I've just scratched the surface.
I have a whole stack of requests, just waiting to be boxed and shipped. I just need
to get to the post office during work hours... (sorry)
Steve
|
|
| |
I just mailed out a bunch of balls to people that requested them.
If I didn't send you an e-mail stating that I sent you balls, then I lost your
request. Sorry. Please ask again.
Steve
|
|
| |
This is great. Someone mentioned a few things about how to connect modules. We
used the new racer track. TexLUG - SA did this for a children's museum a little
over a year ago. They put it on display for about two months in the front
window. (It was still running when we came back 2 months later) I have a video
on brickshelf of the ball lift mechanism. Yours looks to be of a much better
construction that mine. I'll have to hunt around for the pictures and videos of
the rest of the mechanism. The trick is setting your ins and outs. We set them
at the middle of the base plate (32x32) one brick above the plate. You could
have up to 4 output and 4 input points by that logic. But they have to take in a
racers track and empty into a racers track. This would allow you to do curves or
connect various parts all over the contraption. The other item of discussion is
height. We set ours to units of 10 bricks high. We used monorail sanctions to
set certain modules up higher than others. Then with the connections done with a
racer track and the brick dimensions detailed above we had no connection issues.
Email me if you want more details...
In the mean time enjoy the lift video.
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=83919
Chris
|
|
|
