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