Subject:
|
Re: Crate Contraption Standard
|
Newsgroups:
|
lugnet.org.us.smart
|
Date:
|
Wed, 13 Oct 2004 22:22:50 GMT
|
Viewed:
|
3832 times
|
| |
|
|
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
|
|
Message has 1 Reply:
 | | Re: Crate Contraption Standard
|
| 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 (...) (20 years ago, 15-Oct-04, to lugnet.org.us.smart)
|
Message is in Reply To:
| | Crate Contraption Standard
|
| 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 (...) (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
|
|
|
|
