Subject:
|
Re: Crate Contraption Standard
|
Newsgroups:
|
lugnet.org.us.smart
|
Date:
|
Thu, 7 Oct 2004 19:16:42 GMT
|
Viewed:
|
3313 times
|
| |
|
|
In lugnet.org.us.smart, Mark Kenworthy wrote:
> In lugnet.org.us.smart, Steve Hassenplug wrote:
> >
> > After Brickfest, I've spoken with a couple people about creating something for
> > the Mindstorms room that falls in line with the Space and Castle standards, that
> > allow anyone to build "module" that is able to connect together with the other
> > modules.
>
>
> Steve - We've discussed this a few times too. What keeps blocking us is trying
> to define an interface that is flexible enough.
I suspect it will be somewhere between very difficult and impossible to define
and interface that is truly flexable enough to do everything you (we) will be
interested in doing.
However, the goal is to define an interface, so anyone can build a module that
can easily be added to the layout. Not all parts of the layout need to conform
to the standard, but as long as there are a couple "connection points" a string
of standard modules could be added.
For that matter, the entire layout could be made from "standard modules".
>
> Different interface types:
>
> Balls
> Crates (e.g., drop & pick up)
> Lines (e.g., crate mover)
> RR tracks (e.g., train moving crates)
My current suggestion is "balls". I think limiting the standard to balls or
crates, should allow you to do everything.
If you want to make a train track to move crates, my module will hand off the
balls (or crates), and it will be up to you to load and unload them from the
train.
Also, any line-following crate mover will generally require a specific line
layout (barcode). On the other hand, it would be pretty cool to see 3 different
types of movers driving down the same line... but that's beyond the scope of
this simple standard.
First, I want to define a "Type 1" interface. With this interface, only balls
are passed from one module to the next.
The modules connected together would look something like this:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=813226
Here, the width is not critical, unless the module must be removed or replaced.
The depth is also not critical, as long as it fits on the area (table). The
main rule is that the "Input Crate" (where the left neighbor will dump balls)
must be on the left side, and a specific distance from the back of the module.
At this point, I'm suggesting putting a bin which is the standard crate size
(10x10) so the back of the crate is 22 studs from the back of the module. That
means the front of the crate is 32 studs from the back of the module.
The right neighbor will have his Input Crate located in the same location.
> We also tend to use a ball sorter and combiner in our bigger contraptions, which
> adds to the complication, as those modules have 2 incoming or outgoing crates
> (ball chutes, lines, or tracks), and 1 complementary outgoing or incoming crates
> (ball chutes, lines, or tracks).
Things like this would fit in fine, if you require each sorter to include a
combiner. Then, there is still only 1 input, and 1 output.
I know this takes away from the coolness of the whole thing, because you won't
see sorted balls for very long, but I hope people can see the advantages of
having such a standard.
>
> Also, picking a standard size for a module is tough. For example, right now I'm
> working on an overhead crane (like a big construction crane) that has a 27"
> reach. That would require a module roughly 4' on a side to contain the crane,
It should be possible to use any size module, as long as the in and out crates
line up. My current thought is to make one long line with all the standard
modules. At the end of the line, put something like a train, or line following
robot, that takes crates back to the beginning. With either of these, it should
be easy to adjust the size, to match the length of the standard modules.
>
> What we've ended up doing is basically just piecing together a contraption using
> tape lines between modules,
I'm hoping this will minimize or eliminate the need to sit down and draw out the
entire layout. The only thing someone would need to know in advance is the
width of each module, and that's only required if the "end" is going to be tied
back into the "beginning".
Beyond the standard input/output location, I think the only thing that will be
required is a minimum throughput. Like: Each module must process balls at a
rate of 1/sec, or about 2 crates/minute.
How's that sound?
Steve
|
|
Message has 1 Reply:
 | | Re: Crate Contraption Standard
|
| Are the SMARTies going to be showing anything off at NWBrickCon? (...) Alternatively, if you restrict the depth of a module somewhat, you COULD devise a standard way for a sorter to branch, and a combiner to merge (sorter has two outputs that are (...) (20 years ago, 7-Oct-04, to lugnet.org.us.smart)
|
Message is in Reply To:
| | Re: Crate Contraption Standard
|
| (...) Steve - We've discussed this a few times too. What keeps blocking us is trying to define an interface that is flexible enough. Here are some of the issues we saw: Different interface types: Balls Crates (e.g., drop & pick up) Lines (e.g., (...) (20 years ago, 7-Oct-04, to lugnet.org.us.smart)
|
23 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
|
|
|
|
