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