Subject:
|
Re: Pictures of SMART's robot display at Crossroads
|
Newsgroups:
|
lugnet.org.us.smart
|
Date:
|
Thu, 27 Apr 2006 17:55:22 GMT
|
Viewed:
|
4219 times
|
| |
|
|
In lugnet.org.us.smart, Brian Davis wrote:
> In lugnet.org.us.smart, David Schilling wrote:
>
> > There was so much going on that it was hard to take it all in!
>
> Thanks for writing this up and posting the pictures, and the video! Really
> wonderful stuff. I love how many different ideas people can implement - the
> screws are nice, but I think my personal favorites (after a *quick* browse - so
> much there!) are the train loaders and unloaders. I've always wanted a nice
> *big* step feeder, and hanging the steps below the driving shafts does a nice
> job of that. And the unloader "conveyor" with axles seems to work really well,
> at least in the video. You guys used a lot of "drive chains" that are *not*
> based on the normal LEGO chain link, which is neat, although seems
> parts-intensive.
Well, the LEGO chain link is pretty weak and flimsy stuff! Great for a static
model of a motor cycle, not so great if you want to apply a lot of force. So
I've been trying to come up with different ways to make stronger chains. The
biggest problem with the axle and half-beam chain is driving it. You can use
rubber wheels (which I do most of the time), but I'd really like to figure out a
way to use some sort of a gear so that you could drive it more accurately.
And yes, they are very parts intensive! The chain on the train-filling station
used up just about every black 1x4 half-beam I have. Fortunately I bought bags
and bags of axles of every conceivable length from Pitsco years ago!
> > Trains zipping back and forth...
>
> I sympathize with the problems exactly controling the trains and positioning
> them - we had this problem a lot at BF last year as well, although I think both
> Steve & I used different solutions from your (in mine and I think Steve's, the
> train car always overshot, and then moved back into position - it took a little
> longer than your method seems to have). How exactly did you control the train
> (any code fragments you want to share)?
I use two tasks. One watches the sensor, when it gets released (as the front of
the train drives by) it starts the 'BrakeTrain' task, and then waits until the
sensor gets pressed again. At that point it stops the BrakeTrain task, and turns
the motor off (just to be sure).
The BrakeTrain task itself is a matter of fine-tuning. I spent hours trying
different things, to get it 'just right'. (Then I lost my program, and had to
recreate it from memory, but that's another story!) And quite frankly, it still
wasn't perfect. The best thing is to try to build your modules with some slop
allowed. Don't build your module to require the train to stop within a single
stud. I did to start with, but learned that it's not a good thing! Two or three
studs is probably much more realistic. Anyway, I got it to work probably 98% of
the time. Still, that's horrible failure rate when the train zips back and forth
two or three times per minute!
The main thing about the BrakeTrain task is that it needs to kill virtually all
the momentum before the train gets to the 'end'. So I pulse the train
'backwards' at first. Get rid of 80% of the momentum that way. Then pulse it
'forwards', with enough "Off" cycles to kill the remaining 20% by the time you
get to the end. The problem is that things aren't quite repeatable. So sometimes
you end up killing the momentum too soon. Then your train gets stuck. So I'm
ashamed to say I used timing in the loop to start increasing the power at a
certain point, and then increase it even more later. The way I do this is by
changing the on/off times. At first I have 1 on/3 off, then after 3 seconds, I
switch to 1 on/0 off, and finally to 2 on/0 off after 6 seconds. The numbers are
the lengths of my Wait() statement. '0 off' still waits, in fact, I think a
Wait(0) waits just as long as a Wait(1) does.
task BrakeTrain()
{
int t;
Off( TRAIN_TRACK );
SetPower( TRAIN_TRACK, 4 );
for( t = 0; t < 6; t++ ) // tweak this value as needed
{
OnRev( TRAIN_TRACK );
Wait( 2 );
Off( TRAIN_TRACK );
Wait( 1 );
}
SetPower( TRAIN_TRACK, 3 );
t = FastTimer(0);
while( true )
{
OnFwd( TRAIN_TRACK );
if( FastTimer(0) - t < 600 ) // slowed down too much, add a little power
Wait( 1 );
else
Wait( 2 );
Off( TRAIN_TRACK );
if( FastTimer(0) - t < 300 ) // slow down hard for the first while
Wait( 3 );
else
Wait( 0 );
}
}
I'm not really sure why I did it that way (the complexity in the last loop)
rather than use three consecutive loops, which would give finer control. Since
I'm never exactly sure where the BrakeTrain task will be stopped (it sort of
gets the rug pulled out from under its feet whenever the main task sees that the
train has finally arrived), it almost doesn't matter what it does, so long as it
ends up having the train go very slowly by the time it's reached the end of the
touch sensor arm. The last loop in the above code could have been written this
way instead:
t = FastTimer(0);
while( FastTimer(0) - t < 300 )
{
OnFwd( TRAIN_TRACK );
Wait( 1 );
Off( TRAIN_TRACK );
Wait( 3 );
}
while( FastTimer(0) - t < 600 )
{
OnFwd( TRAIN_TRACK );
Wait( 1 );
Off( TRAIN_TRACK );
Wait( 0 );
}
while( true )
{
OnFwd( TRAIN_TRACK );
Wait( 2 );
Off( TRAIN_TRACK );
Wait( 0 );
}
There is one other interesting bit of code, and that's the code to start the
train up again - to send it back to the other station. If you stop *right* at
the moment the touch sensor gets pressed again, (the goal, by the way! see
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1754840), when you want to send
the train back again, there's a huge amount of force required the first moment -
more than even running the train at full force can produce. So the program runs
the train a very brief moment away from the touch sensor and the other station,
before going going towards it. So even in my setup, there's a back-and-forth
movement.
> Also, why did you decide to use two RCX's for the train? I would think you
> could use just one (OUT_A driving the train itself, with OUT_B & OUT_C available
> to run the loading or unloading mechanism, and you only need two sensors for
> train position (which could be ganged together I'd suspect). This way, you
> wouldn't have the problem with track isolation, for instance.
Originally that was how I was going to do it. Two things prevented me. First, I
didn't know how long a line of GBC modules we'd get. Doing this would require
that you have at least one wire long enough for the sensor at the far end.
Running this wire the entire length would definitely get in the way, and
possibly not even work.
But then I realized there was another problem: Since there are two stations, I
would have to signal the other station that "your train has arrived". That meant
a second wire running along the tracks. Okay, so I could put telephone poles
along the track, and it would look real cute. But it would certainly cause
headaches. If there was a way to send a signal through the tracks, that would be
a cool way to do it. (I don't have DCC). But the biggest problem was the lack of
inputs and outputs.
So the only workable solution was to have each train station control the train
while it's there. Hence the need to isolate the track sections.
By the way, the train-filling station used three outputs and three sensors:
#define CHAIN_LIFT OUT_A // the chain to lift balls to the hoppers
#define TRAIN_FILL OUT_B // the step-lift to fill the train
#define TRAIN_TRACK OUT_C // power the track
#define HOPPER_COUNT SENSOR_1 // counting balls going to the dump truck
#define DOOR_CLOSE SENSOR_2 // for the door along the chain lift
#define TRAIN_ARRIVAL SENSOR_3 // the train sensor
Using a set of gears I run the chain-lift motor forwards to turn the chain, and
backwards to cycle the door open and closed.
The train-dumping module also had three outputs, but only two sensors:
#define TRAIN_TRACK OUT_A // power the track
#define CHAIN_LIFT OUT_B // to lift the balls
#define OPENER_ARM OUT_C // to open the train's side
#define ARM_LIMIT SENSOR_1 // sense the arm's lower limit
#define TRAIN_ARRIVAL SENSOR_3 // the train sensor
> > and of course balls bouncing and rolling everywhere!
>
> It's *amazing* how those little balls can get *everywhere*, isn't it? On a
> related question, which GBC modules gave you the least problems? Which were the
> most problematic, and why? I loved the waterwheel module, particularly the lift.
There were a few modules that didn't seem to have many (or any) problems. That
I'm aware of, the two modules that just swung an arm to lift balls along a
curved piece worked all day without problems at all:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1748813
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1748826 (the tan module in the
center of the picture)
The chain lift only stalled once when a ball rolled UNDER the chain (something
that could easily have been prevented by putting a fence around it)
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1748816
The "wave" worked quite reliably:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1748823
as did the ball counter:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1748836
There were probably a number of others that did quite well.
On the other hand, while the small Archimedes screw seemed pretty good, the
large Archimedes screw seemed to jam quite frequently. It just needed to be run
backwards for a few degrees to unjam it, though. So an RCX and rotation sensor
to detect stalls probably could have had this one run pretty reliably as well.
(And a slightly better attachment point for the motor driving the screw --
occasionally the 2x2 round brick transferring the force from the motor to the
screw would come undone.)
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1748802
Perhaps worst was the spinning bat module:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1748809
It relied on the balls coming in fairly evenly, and would just 'bat' them on to
the next module with a bar that spun pretty quickly. Sometimes it would bat them
two or three modules down the line! That was fun to watch! But just as
frequently it would jam as a ball got stuck under the bat. The biggest problem
was probably that roof slopes were used instead of a curved piece. That meant
the bat had to be pretty fast, and hence the problems. LEGO should make more
nicely curved pieces. Just for us!
> > Right in the center of our display was an NXT robot
> > built by Gus Jansson.
>
> So do you think you can remove a bunch of the tape lines from the Contraption
> in the future, doing more dead reckoning and only using tape marks at the end
> stations to do final positioning? The NXT module looks like a very nice
> "crab-like" robot. Did the public notice it as "different" at all? I've noticed
> at least some public interest at places like tghe Orlando LEGO store, and was
> wondering how much it might have percolated into the public knowledge base out
> by you guys.
Many people noticed that it was different (and if they didn't, we were sure to
point it out!), and I had a lot of questions about the NXT. I talked to a number
of people who had the RCX but didn't seem interested in the NXT until they saw
it here. Once they saw it in action, and I pointed out how nice some of its
features (especially the motors) were, they said they'd get one when it came
out.
As for removing lines: they are still probably the best way of having a robot
travel long distances accurately. It would be fun to try to remove more lines,
but probably not what we do 'in the near future'.
> > And the following students of Lakeside school also participated:
> > Jennifer G.
> > Lennart J.
> > Tess R.
> > David I.
> > Rahul B.
> > Gabriel P.
> > Charles P.
> > They're ball contraptions were absolutely amazing!
>
> And personally one of the coolest things I think - *anybody*, of any age, can
> really contribute! I think it's fantastic you guys sewt up an event that was
> able to incorperate so many school-age folks.
>
> > and deserves a round of applause!
>
> Well you guys are getting it from me - fantastic job, and a great write-up!
> Thanks!.
Everyone did a great job! It was great to have the participation of so many
people!
--
David Schilling
|
|
Message is in Reply To:
 | | Re: Pictures of SMART's robot display at Crossroads
|
| (...) Thanks for writing this up and posting the pictures, and the video! Really wonderful stuff. I love how many different ideas people can implement - the screws are nice, but I think my personal favorites (after a *quick* browse - so much there!) (...) (18 years ago, 26-Apr-06, to lugnet.org.us.smart)
|
4 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
