| |
Hey, SMART guys...
I must say I really love your Crate Contraption. In fact, I like it so much,
I'd like to steal the idea. Sort of. Let me explain...
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.
We talked about different ideas, and have finally come to the conclusion that
the Crate Contraption would be the perfect thing.
The general idea is to define a standard that will allow anyone to make a
modular contraption where balls are passed from one machine to the next, down a
long line, until they reach the end (and are manually returned to the beginning)
Or, the machine can be built into a giant loop, where the last one will feed
into the first. (assuming they all work) :)
Each module will have a crate on the left that will be filled by it's neighbor,
and a crate on the right, that it will fill for it's other neighbor. Each
"machine" won't actually have to move a crate. Some may just funnel balls onto
a conveyor.
We're trying to pound out the details, but I was wondering if anyone had any
suggestion/comments about how your current Crate Contraption has been working.
Once we get this all figured out, I'll get something posted, hopefully, to allow
anyone to build interchangable modules.
Thanks
Steve
|
|
| |
In lugnet.org.us.smart, Steve Hassenplug wrote:
> Hey, SMART guys...
>
> I must say I really love your Crate Contraption. In fact, I like it so much,
> I'd like to steal the idea. Sort of. Let me explain...
>
> 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.
>
> We talked about different ideas, and have finally come to the conclusion that
> the Crate Contraption would be the perfect thing.
>
> The general idea is to define a standard that will allow anyone to make a
> modular contraption where balls are passed from one machine to the next, down a
> long line, until they reach the end (and are manually returned to the beginning)
>
> Or, the machine can be built into a giant loop, where the last one will feed
> into the first. (assuming they all work) :)
>
> Each module will have a crate on the left that will be filled by it's neighbor,
> and a crate on the right, that it will fill for it's other neighbor. Each
> "machine" won't actually have to move a crate. Some may just funnel balls onto
> a conveyor.
>
> We're trying to pound out the details, but I was wondering if anyone had any
> suggestion/comments about how your current Crate Contraption has been working.
>
> Once we get this all figured out, I'll get something posted, hopefully, to allow
> anyone to build interchangable modules.
>
> Thanks
> Steve
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., crate mover)
RR tracks (e.g., train moving crates)
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).
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,
and really it needs to overlap other modules to work (other robots servicing the
crates it moves).
What we've ended up doing is basically just piecing together a contraption using
tape lines between modules, obviously with some pre-planning of what would feed
what (drawing ball flow & crate flow diagrams, and mapping out how that would
all fit together).
If you can come up with a system that works, we'd be super intersted!
|
|
| |
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
|
|
| |
Are the SMARTies going to be showing anything off at NWBrickCon?
In lugnet.org.us.smart, Steve Hassenplug wrote:
> In lugnet.org.us.smart, Mark Kenworthy wrote:
> > 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.
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 located X apart and a combiner has 2 inputs also X apart...)
then you can have two lines of standard movement modules of arbitrary (but
equal) length connecting the sorter and combiner.
> 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.
For V1 yes, but don't paint yourself into a corner for V2...
> 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?
Too fast I think.
|
|
| |
I have been pondering on the subject of a modular "thing" for next year's
BrickFest Mindstorms room.
I have been working on an idea similar to the moonbase idea where a module can
have four ports. West and North are ins, East and South are outs. My idea was
that the interface be gravity driven. There would be gradient across the module
boundaries so balls could flow from module to module.
What modules do with the balls is up to them. If we use two sizes or colors,
then modules can hord, sort, divert etc etc.
The thing I like is that it is very easy to make entirely mechanical sections
which can be built to be corners or straights. They just have a simple elevator
type ball pump, so loops or corners can be added to join peoples creations
together.
If you think the crate scheme is more appropriate, I will cease and desist. I am
concerned that the crate thing may be too complex for all but a few. I woild
like to attract less complex modules if I can.
LMKWYT.
JB
|
|
| |
In lugnet.org.us.smart, John Barnes wrote:
> I have been pondering on the subject of a modular "thing" for next year's
> BrickFest Mindstorms room.
>
> I have been working on an idea similar to the moonbase idea where a module can
> have four ports. West and North are ins, East and South are outs. My idea was
> that the interface be gravity driven. There would be gradient across the module
> boundaries so balls could flow from module to module.
This is really along the same lines as what I was thinking, except, I'd start
with two ports (1 in, 1 out) on opposite sides of the module. Each module would
have 1 input "crate" in a specified location, and would be responsable for
moving balls to the input crate in the next module, using any means (as you
suggested)
The "input crate" could be a funnel that leads balls to a conveyor belt, that
lifts balls up, and drops them into the next module's input crate.
It sounds like that's pretty close to what you're suggesting.
>
> What modules do with the balls is up to them. If we use two sizes or colors,
> then modules can hord, sort, divert etc etc.
The LEGO soccer/basket balls seem to work well, from what I've seen...
> If you think the crate scheme is more appropriate, I will cease and desist. I am
> concerned that the crate thing may be too complex for all but a few. I woild
> like to attract less complex modules if I can.
My general thought is to have more than one type of interface. The simplest
(Type 1) would just have modules passing balls. A more advanced standard (Type
2?) would allow modules to exchange crates.
Steve
|
|
| |
In lugnet.org.us.smart, Steve Hassenplug wrote:
>
> This is really along the same lines as what I was thinking, except, I'd start
> with two ports (1 in, 1 out) on opposite sides of the module. Each module would
> have 1 input "crate" in a specified location, and would be responsable for
> moving balls to the input crate in the next module, using any means (as you
> suggested)
I guess I am confused then. A crate is a thing that balls go in. A crate
contraption would need to be able to handle crates, yes? Else it would be a ball
contraption?
The thing is, I think the problems of actaully building a mechanism which can
reliably pick up and move crates around is so complicated compared to causing
balls to roll around that few if any people will participate.
JB
|
|
| |
In lugnet.org.us.smart, John Barnes wrote:
> In lugnet.org.us.smart, Steve Hassenplug wrote:
>
> >
> > This is really along the same lines as what I was thinking, except, I'd start
> > with two ports (1 in, 1 out) on opposite sides of the module. Each module would
> > have 1 input "crate" in a specified location, and would be responsable for
> > moving balls to the input crate in the next module, using any means (as you
> > suggested)
>
>
> I guess I am confused then. A crate is a thing that balls go in. A crate
> contraption would need to be able to handle crates, yes? Else it would be a ball
> contraption?
>
> The thing is, I think the problems of actaully building a mechanism which can
> reliably pick up and move crates around is so complicated compared to causing
> balls to roll around that few if any people will participate.
Yes, I think more people will participate in a "ball contraption" than a "crate
contraption".
It's my intent to create a ball contraption standard. People can use crates to
move balls within there own module, if they choose. When balls are passed, they
are put into an area that matches the crates (so crates can be used) And, it
would be good to expand the standard (in the future) to allow the exchange of
crates. But right now, the idea is just to exchange balls.
So I guess calling it a ball contraption may be better. In fact, I kind of like
calling it "The Great Ball Contraption." It kind of gives it a clasic feel...
Steve
|
|
| |
In lugnet.org.us.smart, Steve Hassenplug wrote:
> It's my intent to create a ball contraption standard. People can use crates to
> move balls within there own module, if they choose. When balls are passed, they
> are put into an area that matches the crates (so crates can be used) And, it
> would be good to expand the standard (in the future) to allow the exchange of
> crates. But right now, the idea is just to exchange balls.
>
> So I guess calling it a ball contraption may be better. In fact, I kind of like
> calling it "The Great Ball Contraption." It kind of gives it a clasic feel...
I had in mind something a bit like the moonbase concept except where they have
level passage-ways between modules, a GBC module would have either one or two
two ins which include a slight down slope to encourgage balls to enter and
either one or two outs which also slope down to encourage balls to exit. The key
spec is the height of the transfer edge above the baseplate and the width. I
would propose a width which might allow the largest Lego ball, which is that
large dark grey one - I think it comes in one of the Orient sets. Then smaller
balls could cascade across the interfaces too, and be channelled or corralled as
appropriate. Actually, the sort of thing which I think would make this kind of
thing fun would be to accept any ball size and maybe do different things with
different sizes. It is very straight forward to sieve them.
JB
|
|
| |
Steve clearly wants to keep this simple for the first go-around. But others,
including myself, dream of more flexibility. I like Larry's idea of referring to
versions. So rather than having to reject some features as too difficult, we can
ear mark them for a future version.
I've been trying to work out in my head how a module that interfaces to
ball-handlers on both sides could effectively move crates. I mean, how will it
know when it is safe to remove or place a crate when its neighbors always expect
a crate to be there?
The only answer I've come up with it the crate-shoving method employed by SMARTs
forklifts. This method should be sufficient, but if it's the only usable one,
crate-handling in the initial version may lack some variety.
I've started a draft of Version 1 here: http://www.lugnet.com/~1048/GBC
LMKWYT
-Brian A.
|
|
| |
Brian B. Alano wrote:
> Steve clearly wants to keep this simple for the first
> go-around. But others, including myself, dream of more
> flexibility.
As long as the "Type 1" standard doesn't tightly constrain future expansion,
I think both are achievable.
> I mean, how will it know when it is safe to remove or
> place a crate when its neighbors always expect
> a crate to be there?
>
> The only answer I've come up with it the crate-shoving
> method employed by SMARTs forklifts.
It seems a good one, but certainly not the only one. For instance, have a
empty crates not filled directly, but instead via a sloping ramp with a flip-up
edge. When I want to remove a (presumably) filled crates, as the forklift lifts
the crate it flips up the edge, so any incoming balls are "held up" until I
place an empty crate in the holder, lowering the ramp edge and spilling the
temporarily held balls into the new crate.
Or a row of empty crates on a sloping ramp, filling the one at the end. When
the newly-filled crate is lifted off the end of the end, the next empty crate
slides down the ramp into position. This does leave the "filling position" very
briefly empty, so a mechanical system similar to the above could be used to
impound incoming balls any time the "filling position" is empty.
> if it's the only usable one, crate-handling in the
> initial version may lack some variety.
If I can come up with two new ways of doing it, think about the variety that
will pop up when lot of AFOL are let loose on the problem. We just need a
beginning standard that allows the cumulative brainpower loose on the issue.
--
Brian Davis
|
|
| |
In lugnet.org.us.smart, Brian Davis wrote:
> Brian B. Alano wrote:
> >
> > The only answer I've come up with it the crate-shoving
> > method employed by SMARTs forklifts.
>
> > if it's the only usable one, crate-handling in the
> > initial version may lack some variety.
>
> If I can come up with two new ways of doing it, think about the variety that
> will pop up when lot of AFOL are let loose on the problem.
I'm sure many AFoLs will feed on each other's ideas.
My thought was to make a "holding" bin/crate with a trap door at the bottom,
that is opened when a removable crate is put underneath it, or, something else
that's only "active" when the crate is in place...
I'm sure there will be plenty of ideas.
Steve
|
|
| |
In lugnet.org.us.smart, Steve Hassenplug wrote:
> > > The only answer I've come up with it the crate-shoving
> > > method employed by SMARTs forklifts.
> >
> > I can come up with two new ways of doing it...
>
> My thought was to make a "holding" bin/crate with a
> trap door at the bottom, that is opened when a removable
> crate is put underneath it,
Which brings up a point about the standard. For a "simple" input, my methods
(flip-up-able feeder ramp to temporarily hold incoming balls, or gravity-fed
empty crates into newly vacated input zone) need very little height beyond the
standard "crate height" - in other words, the output of a module would need to
be about 10 brick heights over the base, to allow for the crate underneath. Your
idea of a feed hopper above a crate might need slightly more vertical room above
a stadard crate height. But making such devices easier (by making the input zone
taller, and thus requiring the output to be higher as well) means more "wasted
space" under the module (or more to the point, a lot of supporting structure).
Any idea where a good balence is? I've been assuming the output has to be at
least 10 brick heights above the base, as I think that's conservative (it allows
room for a crate and a brick or so more vertical play), but who else has built
something like this? Any suggestions?
--
Brian "...and I thought I *had* enough LEGO" Davis
|
|
| |
Here's a couple more questions for the SMART guys.
First, how many balls are "normally" loaded into a crate? I'm guessing between
20 and 30.
How would things be effected if the crates were a little shorter? It appears
the crates could be one or two bricks shorter, and still handle 20-30 balls.
Any comments?
If you were to start completely over, would you use the same crates, or would
you change anything?
Steve
|
|
| |
In lugnet.org.us.smart, Steve Hassenplug wrote:
> Hey, SMART guys...
>
> I must say I really love your Crate Contraption. In fact, I like it so much,
> I'd like to steal the idea. Sort of. Let me explain...
>
> 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.
>
> We talked about different ideas, and have finally come to the conclusion that
> the Crate Contraption would be the perfect thing.
>
> The general idea is to define a standard that will allow anyone to make a
> modular contraption where balls are passed from one machine to the next, down a
> long line, until they reach the end (and are manually returned to the beginning)
>
> Or, the machine can be built into a giant loop, where the last one will feed
> into the first. (assuming they all work) :)
>
> Each module will have a crate on the left that will be filled by it's neighbor,
> and a crate on the right, that it will fill for it's other neighbor. Each
> "machine" won't actually have to move a crate. Some may just funnel balls onto
> a conveyor.
>
> We're trying to pound out the details, but I was wondering if anyone had any
> suggestion/comments about how your current Crate Contraption has been working.
>
> Once we get this all figured out, I'll get something posted, hopefully, to allow
> anyone to build interchangable modules.
>
> Thanks
> Steve
I've been quite busy recently, and so haven't had a chance to participate in
this discussion until now. Pardon the long post, but it'll answer many of the
questions and give details about SMART's own quest for a module standard.
As Mark said, we've talked about some sort of module standard for our crate
contraptions a number of times already. We haven't been able to come up with
anything that will allow it to be as flexible as we'd like. Much of the
'organic' quality of our current displays would be lost if robots were
restricted to operating on only a small section of the display.
To be as interesting as possible, you want mobile robots to travel some
distance. That ruled out most of the ideas we came up with for a standard module
interface.
Additionally, we've found out that for 'interesting motion', if a robot wants to
manipulate a crate it usually needs a lot more room to move around than you'd
think. Sure you could have a robot drive back and forth over the exact same line
to pick up a crate and set it down, but that doesn't look natural. To make it
look 'right', you need to have the robot drive forwards most of the time, and
therefore it needs to do turns, either some sort of U-Turn, or a three-point
turn, or a spin-in-place turn. The first two take a considerable amount of
space, since you need to make sure it won't bump into anything while turning.
The last (spin-in-place) works best. But if you're trying to achieve a 'real
world' look, most vehicles don't do that. Either the mechanics or the
programming will likely end up being a bit tricky.
So our 'best' module design (right up to the point we threw it out!) had 3x7
boards (available cheaply from Home Depot) as the module size, and included
several paths that robots could take across a module: a train line, a tape line,
and a 'crate-line'. The train line allowed your module to have a train station
if it desired, or just let train cars move by if it didn't. The tape-line was
just space to allow one or possibly more robots to move longer distances.
Finally the 'crate-line' was a crate-drop-off and crate-pick-up zone for passing
crates from one module to the next. This allowed multiple paths for crates as
well as multiple inputs and outputs if desired, or just a simple module that
would pass a crate along. If you didn't want the extra paths, you just provided
room for them.
Some of the reasons we threw the plan out were as follows:
The RCX is too limited with only three sensors and three outputs. Consider that
to detect the existence of a crate, pick it up and dump it already takes a
minimum of one sensor and motor. That leaves just two motor outputs. Traveling,
if that's what you choose to do, requires these two outputs. (At least if you
want to do it reliably. I've seen interesting demos of single-motor line
trackers, but that's probably not something that you want on a crate
contraption.)
So if you want to do anything interesting in a module, you have to make it a 2
RCX setup. This limits the number of people that will build a module, and also
means that you need to have the RCXs communicate somehow.
One of the lessons we learned back when we started this was that you want to
minimize the IR message passing as much as possible. It is way too unreliable to
have more than a pair of robots do this in a setup. Messages invariably get
lost, and then you have some part of your contraption out of sync. The more
robots passing messages, the higher the chance of problems. Sending extra
messages to make sure a message got through just exasperates the problem.
One way that we got around the message-passing problem in our crate contraptions
was to use two light sensors facing each other in a light-tight box. By
switching the sensor from active to passive, you turn off the LED, which the
other RCX can detect. That allows for a single bit of information to be passed.
But it requires that your two RCXs are fixed, not mobile. We used this method
for train stations, for instance. An RCX controlling the train car would detect
when it came, and line it up with the station, then signal the 'worker' RCX that
a crate was ready. That RCX would then fill or empty the crate as desired. When
it was done, it would signal the station RCX, which would then move the train
along again.
A second major factor that made us decide against a modular approach was that
there isn't a reliable way to determine what a crate contains. If you have a
single line of crates coming from upstream, you want to know is the crate empty,
full of mixed, or full of sorted balls? Then depending on the type of crate you
receive, you make a choice as to whether to just pass it along, or do something
with it. We discussed many possibilities as to how to do this reliably. There
didn't seem to be a good way. The best we came up with was to have each side of
the crate a different colour, and the four colours would then mean "empty",
"mixed", "soccer", or "basketball". Doing this would then require every robot to
make sure that the crate was correctly oriented when passing it along. That
added even more complexity to any robot design.
The more complex a module would be, the less likely that people would build
them. Our original crate contraption was a collaboration between four people.
One other contraption also had four or five people participate. All the rest
have had less than that. Our desire for a modular approach was to increase the
number of participants. It didn't look like we'd be able to accomplish that.
Besides the complexity that kept coming up, there were major issues of
reliability.
The entire setup would only ever be as good as its weakest link -- the least
reliable module or component is always causing the entire thing to not work. So
you need to make sure that each module or component is VERY reliable. If your
component can do it's thing for twenty minutes without assistance or
intervention, you are starting to get near the point where the component might
be considered viable in a multi-robot contraption. Multiply by how many
components you have, and you'll see that with only four robots, this would mean
fixing or adjusting one every few minutes. And that means *constant* attention
paid to the contraption as a whole.
A robot wandering off it's line means that you have a couple of seconds to catch
it before it falls off the table. You want to be talking to people watching the
contraption, pointing out how it works, etc., not running aerobics for eight
hours!
So that's the main reasons we shelved a modular concept ourselves. This isn't to
say that a much simpler objective wouldn't produce a working modular system. But
you'll quickly run into similar problems when you try to make it more
interesting.
A few things about handling balls: we've discovered that there is almost no
simple hopper system that you can build out of Lego that doesn't somehow jam.
It's impressive how quick the soccer balls can come up with a way to not go
where you want them to. Almost makes you want to start believing in
resistentialism! And if you have more than a couple of balls that you want to
move along a path, you'll discover the same thing. Even single balls will
consistently stop moving anywhere along a path that has a turn in it.
The only system that seems to work somewhat reliably is to have some sort of
active feeding going on. You need to be stirring or shuffling or shaking or
scooping the balls to prevent a jam, and even then it's more of a 'mostly
prevent' than a sure thing.
Lifting balls is no picnic either. It will likely take you weeks to come up with
a decent mechanism to lift balls reliably for long periods of time.
Personally I like John Barnes' idea about a 2-D "Ball contraption". If you're
looking for a modular concept, there's where I'd start. Forget crates of balls,
or large numbers of balls, or even multiple sizes of balls. Just move single
balls from one module to another. Then the module size could be a single
baseplate. Besides the two inputs and two outputs, I'd define a standard
location on where to get power, so that a number of these modules could share a
single wall-wart.
But if you want to do a 'crate' contraption, I recommend that you do what we've
done: plan ahead of time what robots people will build, make sure that you have
backup plans for how to handle any (or several) components that don't turn out
to work, and meet together several times, at least two weeks before a show to
integrate everything, work out kinks, and get things reliable.
--
David Schilling
|
|
| |
In lugnet.org.us.smart, Steve Hassenplug wrote:
> Here's a couple more questions for the SMART guys.
>
> First, how many balls are "normally" loaded into a crate? I'm guessing between
> 20 and 30.
>
> How would things be effected if the crates were a little shorter? It appears
> the crates could be one or two bricks shorter, and still handle 20-30 balls.
> Any comments?
>
> If you were to start completely over, would you use the same crates, or would
> you change anything?
>
> Steve
Usually we aim for around 30 balls per crate. That gives enough leeway that if a
robot is out of commission for a few minutes (changing batteries, say) that a
'filling' robot still can run without being stopped. More than around 60 balls
and the crate overflows.
If the crates were shorter then you'd have less margin for error. You'd likely
have to stop any filling robots upstream if a robot goes out of commission
downstream. And any robot that drops balls in from more than just above the
crate edge will start having balls bounce out. Originally we were aiming for
around 50 balls per crate, but the problems made us reduce that number so that
things would work more reliably.
We talked about different mechanisms of lifting crates at one time, which would
have entailed a redesign, but the most reliable way was to grab the top edge of
the crate while also holding it underneath, something which our crates already
did pretty well.
If you design a 'ball contraption', though, I would stay away from crates as a
holding mechanism, and then the height restrictions wouldn't be an issue.
However, to let gravity do it's work, you'll still need to lift balls somewhere
along the line. And that means a mechanism that can get under them. So you're
probably going to want all the balls to be rolling at least two bricks higher
than the baseplate, otherwise you don't have room to lift them. And since that's
your lowest point, you probably want at least five or six bricks higher as a
good minimum starting point. So you're back up to the height of a crate anyway.
One idea for a ball contraption might be to have the output from the previous
module be three or four bricks up. The first thing your module does then, is to
raise the balls to whatever height it needs to do its thing. There's no reason
to raise them any higher than you need then. If you want the balls to roll
through a set of multiple loops, you raise them 40 bricks. If you just want to
shuttle them along, sorting them, say, you can probably get away with lifting
them only two or three bricks higher, and let gravity do the rest of the work
moving the balls around your module.
Back to crates, I think the only reason we would redesign the crates would be if
there were a better set of sensors and/or a better RCX available that would let
us do something with them that we currently couldn't. For instance, determining
what the crate contains.
--
David Schilling
|
|
| |
David,
Thanks for the input.
I think the goal for the Great Ball Contraption will be different from your
Crate Contraption for a couple reasons.
For example, I don't expect this to run constantly. I'm hoping we'll be able to
make it work for "Feeding Time" in the Mindstorms room, which may only last for
an hour. And, during that time, I hope all the builders will be watching their
own modules.
The current format (not yet posted) should allow us to set-up the whole
contraption, with very little pre-planning. I'm hoping we'll only need to know
the width of the module in advance, and not know much about what it does, or how
it does it.
Finally, I'm hoping for quantity. Even if it's at the expence of quality. If a
feeder jams once in a while, there should be someone right there to poke the
balls loose. If a line-follower, doesn't, there should be someone to catch it,
as it leaves the table.
But, if we can build a Great Ball Contraption at Brickfest that's made up of 20
different modules built by AFoLs from all over the country (world?), that would
be cool... :)
That's what we're hoping for.
Steve
|
|
| |
In lugnet.org.us.smart, David Schilling wrote:
> Back to crates, I think the only reason we would redesign the crates would be if
> there were a better set of sensors and/or a better RCX available...
If I haven't said this already, let me first express how impressed and
fascinated I am with your Contraptions.
Three questions about the SMART crate.
1. The one at http://www.brickshelf.com/cgi-bin/gallery.cgi?i=455309 is 7 1/3
bricks high. The ones at the Road Show
(http://www.brickshelf.com/cgi-bin/gallery.cgi?i=529188) appear to be 7 bricks
high, and the Technic beams are 1 plate lower from the top. Which crate do you
prefer and why?
2. Why do you use two layers of plates to form the bottom of the crate? Why not
just one?
3. Have you experimented with sloping the inside of the crate to help control
bouncing? For example:
http://www.brickshelf.com/gallery/ALittleSlow/Robotics/GBC/crate1.jpg
It seems like it might make the crates easier to dump, too.
Some thoughts about the interface height:
Suppose I would like my input interface to be a train motor with a crate mounted
on it, like the one in the Road Show link above. With a crate size like this
one: http://www.brickshelf.com/cgi-bin/gallery.cgi?i=455309 the top of the crate
would be at minimum 10 2/3 bricks high. This allows 3 1/3 bricks of clearance
between the boat plates on the feet of the crate and the baseplate. This also is
enough to accomodate a gear train, limited pneumatics, or a conveyor belt.
That's enough options to keep me busy for a while. However, I wonder if it's
enough height for an elevator lift, which will be an essential mechanism. Maybe
5 bricks of clearance would be better for that. I defer to the experience of the
SMART guys here.
In terms of the support structure required, your module will always have to lift
balls from the bottom of your input crate to the top of your neighbor's input
crate. There's no getting around that. Adding another three to five bricks of
height doesn't seem that bad.
So I would propose a minimum input height from the top of the crate to the
baseplate of 10 bricks, and a maximum of 13 bricks. I would propose a minimum
output clearance of 13 1/3 bricks and a maximum of 16 bricks. This makes the
maximum distance a ball would fall from the output to the bottom of the input
crate um, 16 - 10 + 5 1/3 = 11 1/3 bricks. Thoughts?
|
|
| |
In lugnet.org.us.smart, Brian B. Alano wrote:
> In lugnet.org.us.smart, David Schilling wrote:
> > Back to crates, I think the only reason we would redesign the crates would be if
> > there were a better set of sensors and/or a better RCX available...
>
> If I haven't said this already, let me first express how impressed and
> fascinated I am with your Contraptions.
Thanks! It has been extremely fun and rewarding to build these. They certainly
attract a lot of attention from crowds.
> Three questions about the SMART crate.
>
> 1. The one at http://www.brickshelf.com/cgi-bin/gallery.cgi?i=455309 is 7 1/3
> bricks high. The ones at the Road Show
> (http://www.brickshelf.com/cgi-bin/gallery.cgi?i=529188) appear to be 7 bricks
> high, and the Technic beams are 1 plate lower from the top. Which crate do you
> prefer and why?
The current crate that we use is this one:
http://www.brickshelf.com/gallery/David/SMART/Samples/current10x10crate.gif The
other one that you see was an old prototype when we first started discussing
amongst ourselves what the standards should be. I probably should have deleted
the picture long ago.
The reason we use the height that we have (5 2/3 bricks high without the feet)
has to do with Lego geometry: this height allows easier and firmer grasping -
look at the forklift, for instance. That's an integer number of studs between
the bottom and top.
http://www.brickshelf.com/gallery/David/SMART/Samples/crateheight.gif
illustrates how useful this particular height is.
> 2. Why do you use two layers of plates to form the bottom of the crate? Why not
> just one?
The reason for two rows of plates on the bottom is that Lego doesn't make a
10x10 plate! If they did, we'd use that. But most of our crates have 2x10
plates, and occasionally 4x10 or 6x10 plates. Just about however you do it, with
a single row of plates, you end up with an unsupported plate at the bottom of
the crate. After dozens of cycles of having balls dropped onto an unsupported
plate, it shouldn't come as a surprise when the crate is lifted, the plate falls
off, and you have a table full of rolling balls!!
We started with a single row of plates at the top because if you are tipping
back a crate, a single brick will often snap off. To make the height 'right', we
went to our current system of two rows of plates on the top, and a third plate
under the technic beam. We have a row of technic beams where they are because
early on it seemed like a likely way to pick up a crate -- some sort of grasper
that inserted pins into the holes. This hasn't been used in any of our
contraptions yet, mainly because it means that you have to have a very specific
alignment of where the crate is set down, plus a very carefully aligned robot
that can grasp it right. It's possible, but like I said, we've not done that
yet.
> 3. Have you experimented with sloping the inside of the crate to help control
> bouncing? For example:
> http://www.brickshelf.com/gallery/ALittleSlow/Robotics/GBC/crate1.jpg
> It seems like it might make the crates easier to dump, too.
Actually balls roll out of the crates quite nicely. If you tip the crate even
just a tiny bit past 90-degrees, there won't be any balls left in it after a
second or two. So there was no need for us to complicate it with slopes.
> Some thoughts about the interface height:
> Suppose I would like my input interface to be a train motor with a crate mounted
> on it, like the one in the Road Show link above. With a crate size like this
> one: http://www.brickshelf.com/cgi-bin/gallery.cgi?i=455309 the top of the crate
> would be at minimum 10 2/3 bricks high. This allows 3 1/3 bricks of clearance
> between the boat plates on the feet of the crate and the baseplate. This also is
> enough to accomodate a gear train, limited pneumatics, or a conveyor belt.
> That's enough options to keep me busy for a while. However, I wonder if it's
> enough height for an elevator lift, which will be an essential mechanism. Maybe
> 5 bricks of clearance would be better for that. I defer to the experience of the
> SMART guys here.
As long as you can grasp under the crate, you can lift it to where ever you
might need to. There's one Lego piece that doesn't exist which for the crate
contraption we would all love to have -- something that was a rounded beam,
perhaps seven or nine 'holes' long, tapered along at one end a bit (say three
hole's worth), and rounded on the corners at that end too. This would allow for
a much more forgiving mechanism to reach under the crate. I don't think we'll
ever see that piece, though! :-) So we've been inventive with different
mechanisms to reach under and hold the crate, using all sorts of parts.
> In terms of the support structure required, your module will always have to lift
> balls from the bottom of your input crate to the top of your neighbor's input
> crate. There's no getting around that. Adding another three to five bricks of
> height doesn't seem that bad.
>
> So I would propose a minimum input height from the top of the crate to the
> baseplate of 10 bricks, and a maximum of 13 bricks. I would propose a minimum
> output clearance of 13 1/3 bricks and a maximum of 16 bricks. This makes the
> maximum distance a ball would fall from the output to the bottom of the input
> crate um, 16 - 10 + 5 1/3 = 11 1/3 bricks. Thoughts?
I guess if you want to design a module standard, the best thing to do is to
build a couple of modules yourself to see how they work, and what things you
wish were different. Even better, get two or three friends to help out, as
they'll all think of different things than you would. The first crate
contraption we did had lots of things change as we discovered different
problems, including interaction problems between robots and crates. That's why
our crate standard changed after only one or two weeks of testing robots
together.
Good luck!
--
David Schilling
|
|
| |
In lugnet.org.us.smart, David Schilling wrote:
> There's one Lego piece that doesn't exist which for the crate
> contraption we would all love to have -- something that was a rounded beam,
> perhaps seven or nine 'holes' long, tapered along at one end a bit (say three
> hole's worth), and rounded on the corners at that end too. This would allow for
> a much more forgiving mechanism to reach under the crate. I don't think we'll
> ever see that piece, though! :-)
Similar to this piece? http://www.peeron.com/inv/parts/2823
> Good luck!
Thanks!
|
|
| |
In lugnet.org.us.smart, Brian B. Alano wrote:
> In lugnet.org.us.smart, David Schilling wrote:
> > There's one Lego piece that doesn't exist which for the crate
> > contraption we would all love to have -- something that was a rounded beam,
> > perhaps seven or nine 'holes' long, tapered along at one end a bit (say three
> > hole's worth), and rounded on the corners at that end too. This would allow for
> > a much more forgiving mechanism to reach under the crate. I don't think we'll
> > ever see that piece, though! :-)
> Similar to this piece? http://www.peeron.com/inv/parts/2823
That's close. I tried using it on one robot, I can't quite remember why I gave
up on it. Two things I can see at this time, though, are that it only has one
technic hole. It'd be much more useful with two or three that you could connect
to. And second that it's not quite as thick as a rounded beam on the 'lifting'
part.
It looks very nice, though. Thanks for reminding me to look at it again.
--
David Schilling
|
|
| |
A friend passed this thread onto me and thought you might be interested in some
work I've done with marbles:
A marble pump (Pump folder)
A marble machine i.e. continuous pump with falling devices
A marble factory (supertrain2004 folder)
http://www.brickshelf.com/cgi-bin/gallery.cgi?m=LegoRoy
I'll be usin some of your idea's in my next project of an expanded factory using
some control with an RCX.
Roy
|
|
| |
In lugnet.org.us.smart, David Schilling wrote:
> The current crate that we use is this one:
> http://www.brickshelf.com/gallery/David/SMART/Samples/current10x10crate.gif
Why 2x2 square bricks for feet, instead of 2x2 round bricks? Having played
(only as little!) with the crate on a self-aligning stand (2x2 slopes to help
center the feet), the slopes don't seem to need the square edges of the 2x2
feet, and a 2x2 round brick would help with near-misses of the forklift tines.
Well, at least that's what I'm thinking (having not (a) built a working lift
yet, and (b) having my line tracker wiggle too much... but why let a little
thing like a total lack of experience stop me :-)...)
> The reason we use the height that we have (5 2/3 bricks high
> without the feet) has to do with Lego geometry: this height
> allows easier and firmer grasping
Good point, thanks. The real problem is doing all this with one motor (the
lift part).
--
Brian Davis
|
|
|
