To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 23257
     
   
Subject: 
Re: The Great Ball Contraption
Newsgroups: 
lugnet.robotics
Date: 
Fri, 7 Jan 2005 18:52:19 GMT
Original-From: 
Brass Tilde <brasstilde@(AvoidSpam)insightbb.com>
Viewed: 
5692 times
  

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.

   
         
   
Subject: 
Re: The Great Ball Contraption
Newsgroups: 
lugnet.robotics
Date: 
Fri, 7 Jan 2005 20:11:28 GMT
Original-From: 
tmassey@obscorp.!stopspammers!com
Viewed: 
6012 times
  

"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

   
         
   
Subject: 
Re: The Great Ball Contraption
Newsgroups: 
lugnet.robotics
Date: 
Fri, 7 Jan 2005 21:11:02 GMT
Viewed: 
6267 times
  

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

   
         
   
Subject: 
Re: The Great Ball Contraption
Newsgroups: 
lugnet.robotics
Date: 
Fri, 7 Jan 2005 23:55:14 GMT
Original-From: 
tmassey@obscorp.STOPSPAMMERScom
Viewed: 
6727 times
  

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

   
         
   
Subject: 
Re: The Great Ball Contraption
Newsgroups: 
lugnet.robotics
Date: 
Sat, 8 Jan 2005 00:09:54 GMT
Viewed: 
7025 times
  

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

   
         
   
Subject: 
Re: The Great Ball Contraption
Newsgroups: 
lugnet.robotics
Date: 
Sun, 9 Jan 2005 21:15:55 GMT
Original-From: 
Russell Nelson <NELSON@CRYNWRstopspam.COM>
Viewed: 
7400 times
  

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.

   
         
   
Subject: 
Re: The Great Ball Contraption
Newsgroups: 
lugnet.robotics
Date: 
Mon, 10 Jan 2005 02:58:36 GMT
Viewed: 
7542 times
  

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

   
         
   
Subject: 
Re: The Great Ball Contraption
Newsgroups: 
lugnet.robotics
Date: 
Mon, 10 Jan 2005 05:44:31 GMT
Original-From: 
Russell Nelson <NELSON@CRYNWRstopspammers.COM>
Viewed: 
7701 times
  

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.

 

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR