2006 Autonomous Disappointment

[pez1959]

Now, I have a question.

We're a rookie team this year and we probably won't use the camera as our programmers are very green and a launching mechanism is beyond the scope of our mechanical team. What are other options for the autonomous period? I have heard suggestions about a spiraling drive pattern, just to bump into other bots to screw them up. Would that be effective? or would the bumpings be inconsequential?

Thanks

[devicenull]

Originally Posted by pez1959

Now, I have a question.

We're a rookie team this year and we probably won't use the camera as our programmers are very green and a launching mechanism is beyond the scope of our mechanical team. What are other options for the autonomous period? I have heard suggestions about a spiraling drive pattern, just to bump into other bots to screw them up. Would that be effective? or would the bumpings be inconsequential?

Thanks

As far as the camera goes, it's quite possible they could get it working.. out of the box the code will search for and lock onto a target

If you drive around randomly in auto. with the intent of running into other robots, I would worry about damage to your robot or someone elses. (Although we had our robot run full speed across the field last year, and right into the other wall) But I don't think driving around like that would do much..

[pez1959]

Well I know that there are specific rules about ramming, but as far as the robot goes, I think we are pretty sure that we are going to ignore the top goals and just go for the sides. However, we aren't looking at a "garbage-can-dump-bot" like in the game animation, so the auton period seems useless to us.

Basically we decided to learn the CMU cam during the off season and get familiar with it to prepare for next year's competition.

[KenWittlief]

Originally Posted by pez1959

Now, I have a question.

We're a rookie team this year and we probably won't use the camera ...
Thanks

the problem with just driving around is you may drive into your own alliance partner, who is trying to score ten balls in the center goal.

If nothing else, try for a dead reckoning approach to blocking your opponents goal, ie: drive forward two seconds, turn left for 1/2 second, drive forward for 2 seconds - see where your robot ends up, then tweak the timing to get the robot more or less where you want it on the field. then have it just sit there

or you could take the same approach and try to score one or two balls in the side goals. Even one point can be the difference between winning auton mode, if your alliance partners can score points as well

who knows, you might have matches in which none of your opponents can score any points in auton. Then one point would be all you need!

[MichaelGoldfarb]

Originally Posted by TimCraig

And everyone would have the opportunity to score some points during autonomous. There would be a wider range of scores during autonomous. And it would me that teams OTHER than the top teams could hope to score meaningfully.

Every team needs to start from somewhere, if it's the bottom rankings than you have to work your way up. We were all rookies at some point and the only way to get better is to take on the challenging.

[Joe Hershberger]

Originally Posted by KenWittlief

If nothing else, try for a dead reckoning approach to blocking your opponents goal, ie: drive forward two seconds, turn left for 1/2 second, drive forward for 2 seconds - see where your robot ends up, then tweak the timing to get the robot more or less where you want it on the field. then have it just sit there

Just to clarify, dead reckoning is not the practice of turning on a motor for a given time. That is just a pre-timed sequence.

Dead reckoning is using sensors on your robot to figure out its speed and direction and integrating to maintain an approximate location and heading. This is a widely misused term in FIRST... I'm not sure why.

See wikipedia.

Cheers!
-Joe

[Matt Krass]

Originally Posted by Joe Hershberger

Just to clarify, dead reckoning is not the practice of turning on a motor for a given time. That is just a pre-timed sequence.

Dead reckoning is using sensors on your robot to figure out its speed and direction and integrating to maintain an approximate location and heading. This is a widely misused term in FIRST... I'm not sure why.

See wikipedia.

Cheers!
-Joe

I was under the impression dead reckoning was running without feedback, such as sensors, and just blindly driving, whether based on timers or loop counts or just setting your motors to a wide turn and leaving it.

"dead reckoning
n 1: an estimate based on little or no information [syn: guess,
guesswork, guessing, shot]
2: navigation without the aid of celestial observations"

http://dict.die.net/dead%20reckoning/ google turned this up, not sure of the validity, so I'm not really sure. Anybody have any other sources?

[Ryan M.]

Originally Posted by Matt Krass

Anybody have any other sources?

Many of the LEGO Mindstorms books I have read refer to rotation sensors/encoders as a form of dead reckoning. The way I would define it would be anything which is based off of assumptions on how you started. (IE, you have to be in a certain spot and track yourself the entire time.) Basically, "I reckin' I'm right about thar."

[Matt Krass]

Alright then, I suppose that is the correct definition, but I still think dead reckoning can include running "blind" (Without sensors) its still assumption based.

[KenWittlief]

dead reckoning: any mode of navigation in which you are likely to end up dead :^)

the real defining difference is navigation with no outside references. Looking at your speedometer and driving for 30mph for 5 minutes, or running a boat engine as fast as it can go for 10 minutes, then turning left, going for 5 minutes...

if you use a compass, or GPS, or sensors that detect outside waypoints (lighthouses for example, or light beacons....) then you are not dead reckoning.

Even the use of a compass is in between, because it can tell you direction, but not distance - so with a compass you only know which way your are pointing, not where you are (and not really which way you are moving, because a compass in water cannot indicate the effects of current, wind and tides).

Im not sure that having feedback sensors on your wheels, or using a timer (counting clock pulses) makes a difference. Your wheels can slip, the tires can wear, another robot could be pushing you backwards while your wheels are spinning forwards, so I dont see how a wheel sensor is any more accurate or reliable than going by applied motor power and timer clicks?

[pclements]

Originally Posted by TimCraig

I'm sort of disappointed that the autonomous phase was cut to only 10 seconds this year. Finally, we get a processor that's reasonably capable, we've had a couple of years to develop some experience with the PIC processors, and instead of increasing the time so we can really show off, we get our time cut. Programming the autonomous phase is one of the more difficult and time consuming parts of robot development, I think cutting back the time seems to denegrate its importance. I was hoping for at least 20 seconds if not 30.

Well, Look on the bright side, you can program the robot and have it go streight, with any luck it might even be able to soot in the hoop, ah heck, what am i thinking, thats bull only giving us 10 seconds, and my freind says hi, an you can use the autonomous mode next year .