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