Autonomous programming...

I finally figured out how to program autonomous movements today for our team. Now we are a first year team without much knowledge. Is autonomous only helpful if you have correct sensors and switches? For example all we know how to do is program so that it goes straight. Also, it seems that once that 20 second sequence is over, I have to wait like 30 seconds before driver control switches on. How do you change that? I do not have the hardware or vex switch to switch between autonomous and driver operation. Any help would be nice.

Thank you,

Can you post your code? That would help others debug it for you.

Wrap the remember to wrap the code tags (the # symbol for the post editor) around your code.

I’ll have a look.

If you want an offensive autonomous it certainly helps to use some sensors, but can be done without them. At our first competition this season one of my teams could score 4 objects in the center 30" goal without the use of any sensors. It is also very easy to create a defensive autonomous without any sensors. If you are starting in the Interaction Zone it can be very effective simply to move your robot into the path of the opposing Interaction Zone robot, preventing them from reach the 30" goal.


Jay: I understand the defensive strategy. What about offensive w/o sensors. I can now get my motors to move… I am using the tread version to suck up balls and barrels. But when I hit the button it goes, treads turn, but arm doesn’t raise. I guess I must have miss programmed. Can you preload before autonomous starts so that way you can pre load, let it go straight, then dump them in?

you can preload 1 barrel and 1 ball. my team we dont use sensors but buttons on the back. the buttons let us pick witch autonomous we want

As team_cheese mention you can preload 1 ball and 1 barrel before autonomous begins.

Are you using RobotC or EasyC?
Can you describe your robot in a little more detail?


Easy C
Search North Lamar or Panthers to see pics of our bot. I don’t have any to upload from here.
Thank you

You can preload 1ball + 1 barrel before competition switch starts the autonomous phase.
Your auto routine can wait 1 second for your to do match load at T0+0.1sec,
or it can wait for you to do match load, and then press a push-button.
This years auton game is designed to be like FLL:
setup, push a button, robot runs out and does something, and comes back, wait
setup2, push a button, robot runs out and does something else.

It would would be helpful if you post your code. I am very good with easy c, so i could help debug it for you

Im currently the programmer for my team and this is only our second year having one. Last year we got 3rd in programming at nationals without any switches sensors or anything at all. However this year we have gotten 16 in programming with just a bumber switch so they are helpful but not essential. We learned from youtube videos which are very helpful but id be willing to help with any questions you may have.

Make sure you are using a Competition Template for your code, (one that has sections for Initialize, Autonomous, and Operator Control) or it won’t work properly at a competition.

You can program a robot to do Autonomous with no sensors, and that’s perfectly fine and acceptable.

Most Autonomous Routines consist of two main parts: Setting Motor Speeds and Waiting. The first one is an important concept. Once you tell a motor to go at a certain speed, it will stay that way until you tell it something else. When the Cortex (that’s the robot brain) goes through this code, it executes extremely fast, speeding from one statement to the next with hardly any pause; that’s why we use Wait statements to tell it to sloooow down before it moves on to the next thing.

For instance, if you wanted your robot to turn for 5 seconds, (assuming your drive motors are in ports 2 and 3) you might have:

SetMotor ( 2 , 127 ) ;
SetMotor ( 3 , -127 ) ;
Wait ( 5000 ) ;
SetMotor ( 2 , 0) ;
SetMotor ( 3 , 0) ;

First, the code tells the Cortex to turn on the drive motors. The Cortex executes the first SetMotor command (starting motor 2 one way), instantly moves to the second SetMotor command (starting motor 3 the other way), and finally stops at the Wait command.

Second, the Wait command says “Don’t go on to the next statement until 5000 miliseconds (5 seconds) are up!” So the Cortex sits there faithfully for five seconds while the motors are still spinning.

And finally, the Cortex zips through the last two commands which stop the motors virtually simultaneously. Since this is the end of your code, it just waits there for you to turn your robot off and try it again!

That’s basically all Autonomous is, except with a lot more motor and wait commands. Also, the commands can sometimes be put into a function for easy reuse:

void Turn ()
   SetMotor ( 2 , 127) ;
   SetMotor ( 3 , -127 ) ;

Now, instead of having to put in all those SetMotor commands in your Autonomous Code, you can just put in one Turn();
Learn more here: EasyC Tutorial - VEX Robotics -Programming User Functions - YouTube

As for the competition switch, you can find a simulator in the Terminal Window on the last tab. As long as the orange USB-Serial Cable is plugged into the joystick, and the joystick is paired with the Cortex, you can use that to control what mode it is in.

More helpful resources can be found here: (old, but still has good basic info)

Well I have it programed! I realized what I was programming wrong. The 1000 ms= 1 sec really helped. I can now have my robot go straight, stop, raise its arm, and spit out a barrel and ball into the 20 in goal with one button and no sensors! The only trouble I have is the going straight. For some reason it wants to hook left big time! I don’t know if it is the weight distribution or what. That is the only bad part. Still have a way until competition so I hope to fix it by then!

That first code: how does that mean to turn? Doesn’t that mean go straight? I am using two motor tank…

Right: for a standard 2-motor drive robot where the motors are inside facing out, you’ll have to set one to be negative to go straight.
Simmons 2.0 is probably just typing pseudo-code from memory, not pasting from real working code.

If you already have set-motors figured out for (straight, stop, lift, discharge), then all you need to add is (reverse) and maybe (turn) to have a basic autonomous.
Its also a good idea if you can do the above sequences in response to pushing a robot-sensor-button.

Then you can have either multiple steps with one button, or each button does a new step. Gateway Autonomous is like FLL; Robot goes out and does something, then it can come back to home square and be touched by hand and reoriented, then go out and do something else.
Have your students think about what you want it to do for interaction zone,
vs Isolation zone, since you might be alliance partner with a better robot that likes either zone.

So you can keep touching a new button for different things? I thought one button and that was it… Interesting… So like a defensive button and offensive maybe?

Yep, sorry! I’m used to ROBOTC which lets you reverse some of the motors in software (which I do, so that 127 means forward on the robot)

I would take your motors off your drive train, run all of the motors forwards and backwards to make sure they all work, and then stick a gear or sprocket on each wheel (where the motor would connect) and see if they all turn easily by hand.

You can use as many buttons as you have… well, buttons! (and inputs) :slight_smile:
We use the buttons on the LCD display to jump to different parts of the code, but you could also use limit switches or bumper switches. Then you might have some code that looks like:

// Insert Preliminary Autonomous Code Here

while ( true )
      Button1 = 1 ;
      Button2 = 1 ;
      while ( Button1 == 1 && Button2 == 1 )
            Button1 = GetDigitalInput ( 1 ) ;
            Button2 = GetDigitalInput ( 2 ) ;
      if ( Button1 == 0 )
            // Autonomous Code 1 (E.G. Score an element in the high goal) 
      else if ( Button2 == 0 )
            // Autonomous Code 2 (Drive straight and block another robot) 

You’ll need to double click ‘Variables’ in Autonomous and set two variables.(Type: int, Name: Button1, and Type: int, Name: Button2)

That code would let your robot do something first, then let you press one of two buttons (limit or bumper switches), which would then make your robot do one of two things, and then loop back and let you choose a button again.

Our robot curves a bit during our autonomous run as well. We simply aim it at the start of the match so that the curved path takes it right to the goal.

At least you know to Compensate for it… :wink:

This can be caused by Drag in the Motor or in the Power Distribution Mechanism as well as some Motors just run faster than others.

In the past, I have evaluated the speed of my motors and Matched the similar speed Motors together…

Also, this is where those Encoders come in Handy… You use them for a Feedback Mechanism to know which motor may need to be Slowed Down ( or Sped Up, if not running at 100% ), to Compensate for the Drift…

Good thoughts Mark O! I have tried to match motors by sticking an axle and an encoder with a big flywheel on each motor (one at a time), and noting how many ticks they can spin in 5 seconds (also testing backwards speed). This worked for speed testing with little load, but do you have any other suggestions of how to evaluate and match motors together?

Another easy way you can use to figure out why a robot is drifting:
Just turn the robot on it’s side and watch the wheels. Run the drive motors and make sure that one drive train side (i.e the left side) isn’t spinning faster than the other (i.e. the right side)

If you have 393 motors on your drive train, make sure that they are all internally geared the same (high speed or high strength)

If you have 2-wire 269 motors on your drive train, we’ve noticed that some turn faster one way than they do the other way. (so make sure you have them mounted so that the fast way is consistent between both sides)

(This is diverging from eloveless original topic and capabililties…)
An interesting idea for motor characterization:

  • motor on string drum with encoder

  • string lifts a linear weight, such as a chain, that gets progressively heavier

  • CPU runs the motor forward until stall, then backwards through unwind and rewind cycles, while saving encoder count vs time

  • Save the incremental values and process in spreadsheet, etc

  • Convert encoder count to weight x drum radius to get instantaneous torque

  • If you want to get fancy, also model the upward inertia of the chain.
    ** Make it quick and easy to use, and easy to swap motors,
    then bring it to worlds and offer free motor testing with a 1 page printed report.

  • Add an I2c or serial interface Current meter to enable motor efficiency calc also