Subject:
|
Re: The Great Ball Contraption
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 7 Jan 2005 21:11:02 GMT
|
Viewed:
|
6592 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
|
|
Message has 1 Reply:
 | | Re: The Great Ball Contraption
|
| news-gateway@lugnet.com wrote on 01/07/2005 04:11:02 PM: (...) one (...) the (...) 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: (...) (20 years ago, 7-Jan-05, to lugnet.robotics)
|
Message is in Reply To:
| | Re: The Great Ball Contraption
|
| "Brass Tilde" <brasstilde@insightbb.com> wrote on 01/07/2005 01:52:19 PM: (...) edge, (...) participate. (...) a (...) correct (...) and (...) While what you're saying will work fine, the standard does say: Each module should have an "in" basket, (...) (20 years ago, 7-Jan-05, to lugnet.robotics)
|
94 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
