|
|
| |
Usually, in May we run our Indy 5.00 event, but this year we're going to push
the date back a few weeks, and run it AFTER the "real" Indy 500.
This year, Indy 5.00 is going to be one of the Mindstorms Challenges at
Brickworld (http://www.brickworld.us)
The final rules will be posted soon, but I believe they will be basicly the same
as in past years...
http://cobweb.ecn.purdue.edu/~andy/LAFLRC/Indy5.00_Rules.pdf
I'm working on a new source for mats, so people may be able to purchase pratice
mats.
But now, start designing...
Steve
|
|
| |
Last weekend, we took a few robots over to the Central Illinois Robotic Club's
annual Bot Brawl. We had a bunch of fun and some pretty good results.
But, as usual, they are trying to figure out how to change the rules so this
doesn't happen again...
http://www.youtube.com/watch?v=sbYyPHBVr7Y
:)
Steve
ps, the kid in the yellow shirt is my son, who just lost to his grandmother.
When asked what he thought, he said he was proud of her.
|
|
| |
In lugnet.org.us.laflrc, Steve Hassenplug wrote:
> We had a small gathering to test out stuff for our upcoming remote control Rock
> Crawling event at Brickworld.
>
> This should be fun at Brickworld (http://www.brickworld.us)
>
> Steve
Hi
My son wanted an "real RC car" so I took the RC buggy body and made a few
changes to have a final result. It is a 4x4 truck driven with 2 RC motors, and I
adapted the RC steering mechanism for the front drive.
It's very large, and quite slow (reduced 45-1), but very strong. Unfortunately,
There is no tilt point or suspension, and it has a tendency to spin if one wheel
if lifted in the air.
The good side is its manoeuvrability (right word???) both for steering and the
distance from the comand. (I can be far away and still have a response)
On the first try, I had the differential in last reduction, but the inside gear
broke... so I had to put the diff one step earlier:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=2333020
Anyhow, the whole experience has been a LOT of fun.
There is a few pics on this folder after mod:
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=235560
I did 2 more funny constructions, but no pics available yet.
LMKWYT, JM
|
|
| |
At 12:04 PM 2/7/07, Peter Ehrlich wrote:
> Heres a thought. Just have the slope going in the other
> direction. That way when it lifts, the balls keep rolling the same
> direction. (Faster and efficient!) If the raising is too bumpy,
> just find a way to place a third or fourth overhead rail keeping the balls in,
One down side here, is that the "ball-lift" must be shut-off when the
bridge is raised, and the controller for the ball lift is on the
"bridge" (other) side of the opening. But, along those lines, if
there is a bin to catch lose balls, the bridge could just lift up,
and disconnect the ramp at both ends. Then, when the bridge is on
it's way up, balls just roll back across the ramp to where they
started, and into a holding area...
Steve
|
|
| |
In lugnet.robotics, Brian Davis wrote:
> Not sure what you mean here. I was just picturing a permenant gently-sloping
> rail along the entire upper superstructure of the span, fixed in place (it would
> look something like a loooong shallow diagonal spar or cable span). With the
> bridge down, the slope is right to carry the balls across. As the bridge tilts
> up it obviously wouldn't work (wrong angle; any balls that are on it would roll
> the wrong way), but that's why you'd need the RCX to stop the lift mechanism a
> little before the actual tilting of the bridge span. I admit I was picturing the
> ball stream as being "lifted" on the end that has the pivot, and the "low" end
> to the far side (left, in most of your pictures), but it should work in either
> case.
Heres a thought. Just have the slope going in the other direction. That way when it lifts, the balls keep rolling the same direction. (Faster and efficient!) If the raising is too bumpy, just find a way to place a third or fourth overhead rail keeping the balls in,
Unloading the balls at the other end take some engineering. You could have the
rail mounted near the rotation point, (and possibly lower the rotation point and
put on a heavier weight). Or you could use about a foot of flex tubing to make
it all work far away from the bridge's rotation point. See what I'm saying?
Nice work by the way :-)
--Peter
|
|
| |
In lugnet.robotics, John Brost wrote:
> I think just cutting off the lift and waiting for them
> to drain out is best. The only thing I am worried about
> is how long it would take for the sloping ball stream to
> empty out before I could lift the bridge.
Not long at all. With the 3'+ slopping double-beam track I had at BF '06, I
think it only took less than five seconds for them to clear the end... and that
was for a *very* shallow slope. Given the time it takes to lift and lower the
bridge, adding a few seconds delay shouldn't cause any real problem.
> I don't want to take down the whole GBC because my bridge
> is slowing things down.
I wouldn't worry about it. First, the original train spec was to support
multiple stations with two trains at more than 1 bps... I'm not sure we've ever
had a full GBC running consistantly at 1 bps, and since at BF '06 we removed
some of the stations, that actually speeded things up. The trains could have
taken much bigger hits in efficiency and still kept up with the balls (in fact a
few times we ran for a while with just one train, so we had a saftey factor of
at least two part of the time. Additionaly, how often are we going to be lifting
the bridge? If it really slows things down, we can just go back to ducking under
it... and it will still be an amazingly cool addition to the GBC. Heck, if it
carries the ball stream then it's "really" just a GBCm that violates the
backplane rule :-).
> How long would you be willing to stand and wait for
> the bridge to go up so you could walk through?
We're talking about the GBC here: what on Earth does the practicality have to do
with it? This thing is just remarkably cool looking - it goes in.
--
Brian Davis
|
|
| |
In lugnet.robotics, Brian Davis wrote:
> Not sure what you mean here. I was just picturing a permenant gently-sloping
> rail along the entire upper superstructure of the span, fixed in place (it would
> look something like a loooong shallow diagonal spar or cable span). With the
> bridge down, the slope is right to carry the balls across. As the bridge tilts
> up it obviously wouldn't work (wrong angle; any balls that are on it would roll
> the wrong way), but that's why you'd need the RCX to stop the lift mechanism a
> little before the actual tilting of the bridge span. I admit I was picturing the
> ball stream as being "lifted" on the end that has the pivot, and the "low" end
> to the far side (left, in most of your pictures), but it should work in either
> case.
I am 100% thinking along the same line. At first I thought of simply stopping
the ball lift and immediately raising the bridge, letting balls along the slope
drain backward into a hopper, but after watching the bridge raise and lower, I
doubt any of them would roll smoothly back into the hopper. I think just
cutting off the lift and waiting for them to drain out is best. The only thing
I am worried about is how long it would take for the sloping ball stream to
empty out before I could lift the bridge. The balls will have to travel about
3' to cross the whole span. I suppose I could use a little more than a "gentle"
slope, but at any rate, I think speed is going to be key to keep the train going
and keep the whole GBC running smoothly. I don't want to take down the whole
GBC because my bridge is slowing things down. After all, I need to keep up a
1bps rate to stay within spec ;)
Guess I'll just have to try it and see.
How long would you be willing to stand and wait for the bridge to go up so you
could walk through?
John
|
|
| |
On the other hand, why would the bridge need to carry balls at all? Just put the
bridge on the section of track that separates the reliable modules from the
unreliable modules' loop.
But I suppose if the bridge does nothing at all with balls (not directly,
anyway), then it's not technically a ball contraption. :)
|
|
| |
In lugnet.robotics, John Brost wrote:
> At the bottom it is 10-wide, but the top horizontal
> rails are only 8-wide.
Ah, OK. No problem then, I was just worrying for a moment that you'd have to
further modify the whole thing.
> > mass of the counterweight?
>
> 794 grams... made out of 1/2 used AA batteries of course.
Cool. I have an additional 7.73 kg of AA's if we need them :-)
> The thing that has been stopping me [from feeding the ball
> stream itself] is what to do when the bridge is lifted.
Not sure what you mean here. I was just picturing a permenant gently-sloping
rail along the entire upper superstructure of the span, fixed in place (it would
look something like a loooong shallow diagonal spar or cable span). With the
bridge down, the slope is right to carry the balls across. As the bridge tilts
up it obviously wouldn't work (wrong angle; any balls that are on it would roll
the wrong way), but that's why you'd need the RCX to stop the lift mechanism a
little before the actual tilting of the bridge span. I admit I was picturing the
ball stream as being "lifted" on the end that has the pivot, and the "low" end
to the far side (left, in most of your pictures), but it should work in either
case.
--
Brian Davis
|
|
| |
In lugnet.robotics, John Brost wrote:
> That was sort of my thought. The thing that has been stopping me is what to do
> when the bridge is lifted.
You'd need a hopper to store balls that arrive while the bridge is raised. You
could probably rig a gate/door onto it that is open when the bridge is down and
closed when the bridge is up. Or the entire hopper could tilt backwards with the
bridge deck so no balls can exit it until the bridge goes back down. That's
probably even easier.
|
|
|
