Here's something interesting...
 

Veeerrrryyy interesting...if this carries over to the full size RC at all, it appears we now have the ability to send a 3 digit(1 byte?) number to the OI display, as well as that the system has the ability to go into "autonomous mode," which locks out all driver inputs....hinting at the game, perhaps? Or maybe completely unrelated...

Definately interesting.

Since the botht the eduRobot and the full-size RC use the same OI, I'd guess that the functionality of user-mode display will still be there. The autonomous part is what really interests me though....

gah! the programmers will have something to do this year! yay! :D

now, just to figure out how to make the robot 'dance' on it's own...

Well isn't this essentially what we asked for in that big "Suggestions for the 2003 game" thread a while back? <insert link to appropriate thread here had I have been able to immidiately find the correct one>

I for one am looking forward to it.

Just a question but do you mean you guys couldn't have programmed a completely autonomous robot until now using the ifi system???

we could have. infact, the programming aspect will be nothing different this year than last year (i'm assuming autnomy will be mandated), except now me and dan will need to add an "Autonomous Code" section, which is flipped on or off by a digital input. If I wanted, I could have done that this year, but i never had time, so i never bothered. it may pay to start trying some stuff though... :)

No, we could have done it before, and it will be no easier to do it now. The importance of this revalation is that now we might HAVE TO program a completely autonomous robot (at least for a portion of the match).

Stephen

It was possible before, it just wasn't mandated.

There are a lot of variables needed to be known in programming an autonomous robot. One of the more helpful variables is time. The robot contoller has no reliable method of telling time, or difference of time, except that data is sent at minimum every 25ms. Sometimes it may take longer depending on the size and complexity of the code. Basically this means that 25ms or more passes between looping the execution.

Another variable is position. The need for this can vary based on the game. With the parts available from last years game, you could tell the position of the robot in relation to something else with the IR sensors. You could also tell the changing vertical angle of the robot with the gyro (up a ramp or down a ramp). You could also buy $100 parts and make some useful tools such as: a tachometer, a directional compass, acceleration detector, photoelectric distance measuring (up to 1.5m), magnetic material detection, and proximity sensing (including ultrasonic).

However, the parts tended to be rather expensive enough that often times only one of these devices could be built with the materials given. Especially with the tachometer, which would require a separate microprocessor since the included stamp processor is rather imprecise.



If they do mandate automation this year, more gadgetry, or at least a timer, will be needed to do it precisely. Unless they are only concerned with position in relation to other objects.

Sure, the retroreflective tape is nice... but it's not very realistic. I mean, how often does a survivor under 2 tons of rubble have retroreflective tape strapped to their back??? How many rocks on Mars have retroreflective tape on them???

Re: Autonomy...

Just imagine the havoc of several 130 lb robots with unstable autonomouse controllers careening around a 44'x22' playing field. Yee-Hah!

On a side note, I only discovered recently that the RC is active while in disable mode. It occurs that an autonomous program that just sends the robot forward when the motors are enabled could gain 1-2 seconds before a driver could react. Until last year, I don't think every second counted.

One autonomous task that might be interesting that could be accomplished in a reasonable time would be to follow a line. This is one place where the retroreflective tape and optical sensors could actual work in a competition setting.

Andrew
Team 356

Maybe thats why they were introduced last year, to get everybody thinking about good ways to use them, test their theories, etc. So instead of being a major player last year, teams would help test for FIRST so they could better design this years game.

Or not... :cool: i dunno.

yes, i noticed this too. our robot had a ramping section of code, so the motors wouldn't violently jump around from full forward to full reverse in two tenths of a second (we're a bit cautious :)). that meant the robot took maybe a second or so to react sometimes, although i've grown to like the delay, as i feel i can usually drive a little better with it. i did notice though, if i started the match with the joysticks pushed full forward, the robot would fly away at full speed as soon as the match began. very useful information to know :).

Team 211 (Kodak & Marshall High School) made their robot dance back in 2001. They showed it off at the Rochester Scrimage. It was rather neat to see even if it was completely pointless.

Matt

It seems to me that FIRST has been moving tword an autonomous competition for a little while. Every year they have been giving us more and more sensors, even if very few people have used them. Maybe this year they are going to force us to use them.

As far as I can tell from perusing the EduRobot material, the only way to turn on autonomous mode is to physically set the dip switches on the RC to team number 000. Unless it can also be commanded by the competition port, I don't see how autonomous mode can be required for part of the game.

Maybe the game will allow some teams to choose to fill an autonomous robot role. I.e. there may be some scoring opportunities which are only available to autonomous robots.

Was the retroflective tape sensors that sensor with the red sheilding on it??

The optical sensors we got had a yellow body and ... yeah I believe they had a red lens.

We took a long look at using them to lock on a goal at power up so that we could autonomously drive to the goal and lock on. Like Andrew posted, we thought we might gain a sec. or so advantage. When we checked the sensor specs against the distance from our starting position to the center-line of the field, however, the sensitivity of the sensors rolled off big-time about 4ft shy of the reflective tape. So, we'd have to start in manual, get a lock on multiple sensors and triangulate. Since we got ~12fps in high gear, we figured we'd be there by the time we got a good lock! In the end, since we were pretty fast, we relied on pure speed and a beefy front grabber, and just rammed the goal at full speed. We did end up using the optics, though, as part of a tread speed measuring circuit.

Our solution to this was to just start with the joysticks full forward. Easier, more reliable, and it didn't lock us into running headfirst if we didn't want to.

Personally I think a fully autonomous competition would be horrible (Im biased cause Im a driver) I've seen autonomous robotics competitions before. They are a difficult engineering challenge (even with tons of expensive sensors), but they are boring to watch. The part of FIRST that gets people so exicited at competition is the sport aspect. Take away the humans and its just a bunch of bots out on the feild. the human element means every match is different and unique. The robot (and people themselves) can quickly adapt to unexpected situations. THe most exciting matches are ones where everything doesnt go as planned. Who's gonna chant and cheer for an autonomous bot? The real potential would be for FIRST to give us what we need to give robots cabalities to supplement the driver.

Teleoperated robotics is what that's called. Force feedback controls would be a nice idea abeit rather complicated. It all depends on the situation for you to choose an autonomous or remotely operated robot.

That seems reasonable. You still have to live with a potentially negligible time delay between when your robot becomes live and when it gets the first joystick command. These may occur simultaneously, but, you never know.

You mean you don't want to watch a robot stuck in a corner, repeatedly executing the same failed maneuver, banging on the playing field border over and over and over and ...? Now that's entertainment!

Andrew, Team 356

Actually, the robot is receiving the joystick commands anytime the link is active, whether or not the robot is disabled. The PBASIC program is seeing the commands and everything. The reason the robot doesn't move is because there's a microprocessor in between the BASIC Stamp and the actual PWM outputs to the motor. Among other things, this processor ignores the commands from the BASIC Stamp when the robot is disabled. When the robot is enabled, the output processor allows the motors to run off of the BASIC Stamp's commands. This is the reason that people who have "ramp up" code don't see the "ramp up" effect if they start with the joysticks fully throttled: the BASIC Stamp has already gone through it's throttling up phase and already thinks the robot is running at full speed!

It is possible, however -- if desired -- to sense whether the robot is enabled (the comp_mode variable), and the robot could wait to start its accelleration ramp until it is enabled.