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