Autonomous Period
 

Did anyone get that bad feeling in the pit of your stomach when the demo robots FIRST had weren't working in autonomous mode? The autonomous period scares me...

10 Seconds of Human time + 15 seconds of robots moving in circles = 25 seconds of dead air.

I really hope this isn't the case.

Good Luck,
Andy Grady

yeah i got that feeling.

If FIRST's robots don't move than whose will?

i don't think it will be that bad... at least i hope not! this will definitely make the programming a lot more... interesting.

I think most teams will make it happen, if I learned one thing from last years game it's that teams will acomplish amazing things even those seemingly impossible. But I sure wouldn't wan't to be the guy charged with programing the auto-mode.

It's only my first year, but I've done a lot of programming before...I don't think that seeking a target with reflective tape on it or following a line is that difficult to program. The latter I have done before with the Lego RCX robotics kit and it was surprisingly easy. The fact that NONE of their robots seemed to work leads me to believe that something was wrong with their entire control system, maybe?

Sample program
 

The autobalancing routine that was posted by the TechnoKats (?) is an example of a dead reckoning program. Shouldn't be too tough to program a forward, turn, forward, turn, forward that would plow over the ramp.

Remember, like all the mechanical engineers say- "let them fix it in software!!"

I suspect the autonomous period is to distract from the naysayers who always use the 'it isn't a robot because it is remote controlled' type lines. 15 seconds isn't that much time, I think it will be very interesting to see what people come up with.

So during autonomus period, will the robots be basically like huge Lego RCX's??? ... I mean, will you be able to program in go right, straight for 2 seconds, left, back, etc. ?

whole system
 

They tried operating the robots after the autonomy period and could still not get them to work, as well I saw the drivers station lights blinking on the off a couple of times. My guess is that they werent getting power to the drivers stations, and/or they transmitters weren't seding signals to the robots. I dont think it had anyting to do with the programming.

-Rc

I instantly had visions of robots crashing into each other.

Personally, I would have several programs loaded, and communicate with my alliance partner as to who's doing what befire hand, so there aren't and (wince) crashes.

Auto Switching!?!
 

how exactly is the bot switched from autonomous mode to regular? do we have to put in an autonomous subroutine or if statement to make it function on its own? I took a look at the new program but the number of tokenizing errors made it difficult to understand some of it. Any help would be appreciated.

In the code there is already an alias defined to see if you are in autonomous mode called "auton_mode" . It is bit 6 of the PBmode variable.

There is an example of how to code for this in the Programming Reference Guide, which can be found in the documents section at Innovation First's web site The example is written as
If auton_mode = 1 then do_autonomous_stuff
'Normal drive code
goto end_of_autonomous

do_autonomous_stuff:
'Autonomous mode code
end_of_autonomous:

The Programming Reference Guide is well done. It will be a big help to new PBasic programmers.
As one of the coaches of the control team I am really looking forward to developing the autonomous mode code. Of course I say this now, talk to me in six weeks.

/me wonders if anyone will try to do the whole event with out radio control. :D

I think that I might build a switch into our controls... "Autonomous Mode <> Remote Control"

We'd run in auto until something sticky came up.

One correction, only the 15 seconds are apart of the actual 2 minutes of the game. The other 10 seconds for the human players are seperate from the game time.

I liked the direct drive robot in the demo;) All that crashing was funny.

I don't think anyone will go it on all AI for the game but who knows.

I don't like the idea of having the bots run around for 15 seconds without anything to keep them from ramming eachother. I think FIRST decided to make scoring for fans easier, but actually forming a strategy for it harder than anything.

That's why the disable button was created. If you're concerned about what your robot's gonna do, hit the button. You can re-enable it when the human-controlled match starts.

If anything, just program your robot to go forward (or backward) at the start of the match. Then hit the button when you're at the spot where you want to start.

Well just remember, there is no where in the rules where it says your robot must do something in the autonomous period. So anyone that is afriad for their bots sake, or for injury from a poorly coded automater... can just sit tight for 15 seconds.

everyone is complaining. i think this is great! i finally have something to do as one of the main programmers. sure, it'll be hard, but hey, i plan to have at least 2, maybe more mini programs. if you guys don't want to do anything for the first 15 seconds, fine by me. more time for my robot to work with :).

scary
 

well, it can and will be done. we had a feeling that this would happen, so we practiced with it a bit. it will alll work eventually.

I believe I read in the manual otherwise...

15 seconds of autonomy, and then 1 minute 45 seconds of Human controlled robots...

Anyone know if there will be a stop between the human controlled and autonomy, or will it just turn on the human controlled with no stopping transition?

there isn't supposed to be a stop between, just after 15 seconds, the human control should be active.

yea, and thoes 15 secs. are comming off of our 2:00 time for the match...:ahh:

I'm glad that the other 10 isn't...

The matches will be won and lost by the first 15 seconds, it's easy to see.

Well, 1:45 is a very long time for someone who got ahead in the 15 seconds to run into major problems or be terribly dumb. But if planned well, yes, the 15 seconds will be a major decision maker. Hence the need to plan and code :).

Yes, but look at it this way, those 15 seconds are going to determine who gets the wall...

Now, unless your robot has a crazy massive chucking rate, or some crazy way to plow 5+ at a time, then it is quite critical.

Exactly. Perhaps they'll steal your human-built stack, too. And since you took the wall, their stack still stands... it would also be in your interest, i think, not to shut your opponent out. Remember, own score+2(opponent's). And if it's not a shut out, there's always a chance a good bin stealer could gain points. And remember, the hill is 50 possible points. The automation is important, but nothing is guaranteed until the power is off :)

(Or maybe someone will have a few coasting bots or unstable stacks, so a few seconds after the power is off...)

For the record, I was at the Seattle kick off and I think most teams were excited by the idea of actually having a robot on the field for 15 seconds, not just a big RC car.
Of course we are home to the SRS (also well represented in the teams) (SRS -> Seattle Robotics Society)

I think the game will be won in that first 15 seconds. Linefollowing can be done on a Lego Brick. IR sensing also (remember the Lego Segway??)

I just hope we have Manual control code space left after we try and have 12 different auto programs (OK maybe just 8)

This is gonna be a great year. But so far it isn't obvious what the exact plan is gonna be...

Have fun, its started!!

has anyone noticed how choppy those lego line readers are? Ive watched them, and I saw about three inch jumps from either side of the line. I dont know if this is an issue with our sensors as I know nothing about them. Did anyone think of placing multiple bins along the lip on the ramp. When robots started going towards the ramp in autonomous mode, more likely than not they would hit these, and they could get caught on the lip, making it impossibleto move by. If nothing else, I'd imagine this would really confuse the bot.


Cory

The lego line readers are only choppy depending on how you program them. It will be a challenge for line followers in this game as well to make sure that their robot is efficient and smooth with their movement. For you code junkies, think about how you might use the code to make a quick and smooth turn onto the ramp. I bet you'd want to use some sort of degredation of motor speed rather than just shutting them off for instants which is what the lego bots do if they aren't programmed correctly.

And for the record - this whole autonomous thing is the greatest. I think it's going to add a lot of depth, strategy, excitement and of course luck. Not only that, but it makes the whole thing just a little more magical and awe inspiring for those young spectators we're trying to draw in.

everyone seems to be fearing this period of autonomous operation. I see this as a challenge. First has asked us to make our robots a little smarter than ever before, and i think that even with the problems at kick off, some teams will find ways to use this short period of unmanned operation to their advantage. A team doesnt have to have a perfect robot, tons of money, or fancy designs to complete this part of the game. All they need is some vision, and a little imagination, and i think that they could take this a long way. Good luck to all the teams out there who are accepting the challenge and are going to attempt to make their robot do more than run around crashing into things blindly during the first 15 seconds of play.

ok. Here's an idea:

If you read 7.2 in 'The Game' it says that if your HP is not off the field withen 10 sec. then your bot won't be powered up during the autonomous section. Then, it they still arn't off the field in that 15 sec. your bot won't be powered.

SO... now... your human player decides to take a little longer than the 10 sec. :) - What he really does is stand right in front of your tower preventing any alliance from hitting it because it would have to hit him and that wouldn't be allow because of safety. (duhh...) Yes, your robot can't be used during the autonomous peroid, but if the other alliance can knock down the wall, then you've got no problem. Then at about 12 seconds, you run off the field and hit the sensor to let your bot function during the rest of the match. Personally, I think it's a great loophole. Can anyone tell me if they found a rule that wouldn't allow it? (aside from commen cense :))

the game doesn't start (or robot part) until all 4 pressure pads are activated ;). kinda hard to activate it from the field, eh?

Hmmm...

Ok... I guess i could see that. I guess i miss-read the rules. It was sort-of hard for me to think that they would not have thought of that, but i was wishing.

So... I guess that your HP could take an hour, just the robot wouldn't work. :) - Also, the line about the 15 secs. confused me.

-Darn. :cool:

If the HP stays on the field too long and is still not off by 15 secs then your bot will not be activated at all for that match

A big problem in stealing stacks. I don't think any robot will be able to really do it that well considering the fact you have to go over the ramp.

Unless you lift it over the bar :p

Yeah I'm sure someone will think of a way to do that.

Boxes, Ramps and all that fun stuff
 

Jack, I have the solution to your problems, program your robot to sit still during its fifteen seconds, but I think anybody trying to evade this part of the competition is making a huge mistake. Fifteen seconds could win or lose the match for you. Anyways, think of it like this. Your robot w/driver is just the largest most expensive RC car you will ever own in this life. these fifteen seconds, the robot is funtioning closer to a robot.

Robot- a machine that can funtion on its own without continual outside guidance

Well I personally don't like this definition because even some robots get some human guidance. ie. The martian probes

the instant i heard there were going to be autonomous play i thought of the same thing of having multiple options and using one of them after stragety discussion... however i dont think my thought of having switches on the control box will work if we wont have radio contact so the switches will have to be on the bot itself.

No, but you can have switches on the RC. Many lego-league teams do this to have one program do multiple things depending on whether the sensor is pressed or not.

Here's how it works:
Depending on how many variations you need, you have some number of limit switches. One switch for two programs, two for four, and three for eight, etc.
Depending on what program you want to run, you place little blocks in front of the appropriate switches, so that they are always stuck in either the on or off position.
Alternatively, you could just have a small jumper block wired to the RC inputs to do the same thing.

modular autonomy
 

Here's an idea to throw into the pot. I know my team will be using it (I'm the lead programmer - they WILL do it :) ).

Modular autonomy: in other words, lots and lots of autonomy code becomes a program shortly before a match. Our team will be spending a deal of these 6 weeks making tons of subroutines that, when combined with some connecting code, will create a custom program before every match.

Some ideas of modules:

counter (seconds)
directions (forward, backward, left, right, angles?, curves?, other
shapes?)
find boxes
follow line
detect obstacles
?
?
?

Let me know what you think.

Adam! you're not the ruler of the universe! not even of 159! that's me! and i'll crush you with my pneumatic bin-launching thingamabob!

no, seriously, i'm excited about the autonomous period becuase...well, cuz it's cool and a great challenge.

i don't know what it is with my team and modularity...one of the engineers proposed modular wheel/transmission assemblies... :)

lauren

i mean the worst thing that could happen is if you don't do anything during the autonomous period and start out the 1:45 on their side of the field

I'm not sure exactly how the optical sensors work since my team didn't make use of them last year, and I haven't got to it yet, but I seem to recall that at last year's kickoff they were dragging around one of the goals perpendicular to a little robot's (equipped with retroreflective sensor) field of vision, and the robot would turn so that it was always facing the goal. I'm not sure yet how this directly applies to this year's game, but how did they program the bot so that it differentiated between leftward and rightward movement...I assume that there's just some sort of decrease in the sensor output as the distance from tape to sensor decreases, but how do you determine which way to have the motors turn to follow the tape other than by trial and error?:confused:

Geez, Adam and Lauren, I never realized there's so much confusion about who's the cat in team 159.
:)

I really like Adam's subroutines division selection because that offer flexibility in strat. However, I just don't to see the program get all sluggish and valuable RAM get hogged up by those subroutines.

Also, does anyone know if we can simulate the 15secs autonomous mode by fixing a adaptor for the IO competition port? Because from the IO documentation, it seems to me that two modes can be accessed through the competition port. Disabled and Autonomous. How would you set the channel or twig the setting to make it go autonomous like the way it would in the actual competition. Maybe it's not supposed to be used this way but I am just wondering.

set it to team 0000

would setting it to 0000 enable the autonomous mode or disable the robot? And, is it possible to program the OI so that it breaks out of autonomous mode after 15 secs and switch to RC mode? Thank you.

The best thing you can do is just assign a button to activate the auto code and just dont touch any controls

0000 makes it auto

Yep, thanks, just don't mess with the competition port at all.

Wow
 

Not seeing the robots at the kickoff work scared me. But what worries me more is that myself and the 3 others on our control team are all new to the club. What a year to join eh? But this year's game is still very cool.

I agree that switches will allow you to choose programs, but you could also use a pot. and get at least 12 posibilities for code. Just draw little marks where the knob needs to point for each code segment

that way you are not tieing up 3 or 4 binary ports, just one analog.

BTW if you look at the field drawing, the white lines are 2 feet apart at the ramp. If both robots are using the white line to get to the ramp AND both use sensors in the middle of thier bot to do it....well use your imagination if they get there at anywhere near the same time

autonomous mode, switching programs, etc.
 

A few comments for what's been said:

By modular, I mean that all of the subroutines are NOT on the robot, and pre-match we pick and choose the subroutines and create a normal, but taylored to the specific match; so, there's no concern about memory.

Testing autonomous mode/switching programs:
I was thinking to just do it timed (get rid of the code that deals with switching from autonomous mode in the default code, if that's allowed) - that way we can easily test it before the competitions, set up EXACTLY the way it will be when we get there. I've got to look into the legistics of this, but I think it will work. Anyway, to get out of autonomous mode, I hope to keep track of time, and after 15 seconds, use the RUN command to switch programs (we can definately fit 2 programs on there without worries). The benifit of that being this being that we can test at home, and we can use 2 different programs, and therefor not have to worry about variable space with the 2 combined.

I like "modular" because it allows for customizability, but, worse come to worse, we can use one program that we make before competitions (from the subroutines) - a default, if you will, in case we can't get a new program compiled.

Lauren - you smashed my programming authority, but what do you thing about modularity in the programming sense (btw, I think everything hardware should be modular too).

I'm with you adam. There is definately no auto period that will be perfect for every match, so there is a need to have a few, and hopefully one will be a good match for what your alliance partner can do with their auto period. And lauren can't stop us bwahahahahahahaha!

I haven't read the rules but it was implied at the kickoff that you could have multiple modes, but they had to fit in the program space all at the same time. I don't believe they want you "reprogramming" you robot between matches, but it wouldn't be the first time I was wrong.

Adam, you're all for a modular robot aren'tcha. :P (Hey, in this match, let's take off our welding torch and replace it with our helicopter blades! oh, and Adam, get that code ready).

It would take more debugging (the pain!), but the usefulness far outweighs the added stress of finding that one error in lines and lines of code

I think that the addition of the auto mode is a good thing. I just wish that we had some of those radar position transducers.

Out of curiosity, does anyone know if its feasable to store your auto program in one slot, and then have it switch to a program in another slot at the end of the 15 second interval?

Yes. You can use something like

if auto_mode=1 then doAuto
RUN 1
doAuto:

-or-
using the new PBASIC syntax:
if auto_mode=0 then RUN 1

Andy:

I'm a controls engineer that programs almost entirely autonomous programs. If you have any questions on how to do something. Dropme an email and I'll post you through it. If you have played with LEGO Mindstorms, those programs are entirely autonomous.

Good Idea
 

[Here's how it works:
Depending on how many variations you need, you have some number of limit switches. One switch for two programs, two for four, and three for eight, etc.
Depending on what program you want to run, you place little blocks in front of the appropriate switches, so that they are always stuck in either the on or off position.
Alternatively, you could just have a small jumper block wired to the RC inputs to do the same thing. [/b][/quote] :)


Thank You - This is an excellent idea!

one of our head programmers is insane and i fear that he may try to make it all AI. i fear the outcome- may the big mna in the sky be wathcin over us.

john
team 1019
:ahh:

Enabling Autonomous Mode
 

Not sure if this has been answered somewhere else, but I've seen the question a few times now: How do you enable autonomous mode? Answers have included settin the team number to 0000, simply set your outputs to neutral, or just don't touch your controls.

As you get your robot running and really want to test out how it will perform in competition, being able to simulate the competition conditions will often reveal hidden problems that you did not anticipate. On the Innovation FIRST web site there is a single page document that shows you how to use the competition port to do three thinigs:

1.) Enable autonomous mode
2.) Enable alternate channel access
3.) Enable/diasble robot controller output (i.e. start/stop a match)

I've provided the URL below. I would encourage teams to make this adapter, and use the enable/disable switch as a safety when you are testing your robot or even just demonstrating it around guests. It is a good idea to always have a "safety officer" with this switch, ready to shut off the robot at any time with the push of a button. The motors and pneumatics you may be using can cause serious injury - keep safety in mond ALL the time.

This adapter is easy to make and you do not need to be fearful of "messing" with the compeittion port. Just BE CAREFUL because incorrect wiring CAN destroy your controller. Have your wiring and all the connector pins checked and double checked before you install it. Use shrink wrap around the solder connections to insulate the connections and prevent accedental short circuits.

Making and using this adapter will not only allow you to simulate actual competition situations, but will also help you operate and test your robot more safely.

Competition Port Instructions

Jeff

Sell me your Dongle!
 

Is it just me, or does it seem like it would make sense for IF to sell these already made up with a little PC board and a couple switches...

I hate soldering wires to those little solder cups, and then trying to stuff everything inside a backshell.

Now, of course, the lead time becomes an issue.

A few people on my team and myself have come to the conclusion that the game can be won or lost just as much in the first 15 seconds as in the last 15 seconds. i.e. someone uses autonomous mode to go to the center, pick up all the boxes and dump on their side. there's a hammond strategy if i ever heard one.

lol, yeah, anything can happen at any time. A good driver and a good auto script is a combination meant to kill ;)

and there at least two quick counter-tactics to use against any robot utilizing this approach.

# 1 - get to the top of the ramp faster than they do, and knock the containers to YOUR side of the ramp (i.e. make it a race!)

# 2 - at the start of the autonomous period, your robot goes under the bar and bumps them from behind, knocking them off the line and futzing with their line/path following capability.

No strategy is foolproof, and all of them can be countered if you are creative enough. The hard part will be choosing which one to use during any given game!

-dave

My idea goes like this:

Have the robot in it's start position where it's facing the pole, and have it go under (or over), and knock the opponent bot outta line.

Then you go into full reverse as far back as needed, and hit the ramp at high speed + knock down the stack onto your side

The Lego bots are jumpy because their sensors are so close together. If the sensors are placed a bit more apart, and it will be smoother. However, If they are placed too far apart, it could be a little TOO smooth.

Autonomity Period
 

I, in contrary belief to many of you, do NOT think that the game will be won or lost in the first 15 seconds. Considering line-following is easily disrupted, and dead-reckoning is evil, there is just a little too much of a chance something will NOT go as planned. Now, I'm more of an engineering student on Optimus Prime, but I have gone far enough into programming to know a bit about it. Different factors come into play when programming dead-reckoning, such as the charge of the battery, random obstacles, etc. When it comes to line-following, no matter how far apart your sensors are the turning will always be choppy, purely because of how the sensors work. Unlike last year's game, this game has no definate way of controlling it. Since we didn't go to Nats last year (the first year I was on the team) I didn't get to see anything outside our Regionals. Team 71 was able to control the game by grabbing all three goals, and that was it. Unfortunately, this year we can't just grab all the goals and walk into the scoring zone. There is always controlling the ramp, but there are several problems with that.
a) It leaves your alliance partner in a 2 on 1 scenario, which is never a good thing
b) You only score 25 points, with the other goal being to prevent the other team form getting up to 50 points, therefore limiting your own QP
c) Whether you are any use at all is dependant on the first 15 seconds where you have zero control over your 'bot, and therefore cannot react to dynamic situations

NTM several other problems. Of course, I know what I think the best way to go is, but I'm not sharing :D at least not now.

so you're saying that a robot CAN'T grab all the boxes and win?
hmm, very interesting. i wouldnt be suprised in 71 pulled something like that. never say u cant do something.

i srtongly disagree! (with something)
 

regardless of whether a game can or cannot be won in the autonomous mode, it only takes one robot, intentionally or otherwise, to knock into the middle and alter the tide for the remainder of the match. i personally believe that some games will be won by chance or luck, i.e. a robot that hasn't been following a line all of a sudden does, and then strategy will be messed up for that alliance. of course, there are ways of making sure that a robot can't even get onto the ramp, such as placing the human player bins right at the bottom. considering the lips both at the top and bottom of the ramp, i think that most robots would have a pretty difficult time getting all the way to the top to knock the stacks over (without damaging the human player bins severely :ahh: !!)
it is therefore my belief that the game can be won in the human player mode. given the above situation as well as the general lack of very accurate dead-reckoning systems (in general) and the general lack of speed in line-tracker systems, i think that some very effective human player strategies are out there. i haven't thought about it that much, but i'm sure that there are very reasonable methods of preventing all robot types from being effective in the autonomous mode. for example, if a robot was designed to knock down human stacks, you could put a bin right in front of it and it would push it straight into the wall. for a loss of one bin, this is a good strategy that could save you some points later. ) this, of course, all depends on accurate scouting, which will be a big problem in this game considering the possibility of multiple autonomous modes.) well, there's my three cents worth...

Almost all depends on your programmers. Our team has a programmer that can program ANYTHING(so he claims). He sure as heck better.

yeah but not any robot can counter any strategy. every robot has its own limits but if no one has the ability to exploit these limits, thats how the strategy can be close enough to foolproof.