[Travis Hoffman]

Originally Posted by sumadin

That sounds like a good idea Travis. However, some things to consider:

Teams use different framework codes - IFI's, Kevin Watson's, WPILib, EasyC. Each would need a different autonomous mode.

48, for one, uses MPLAB. I would not know how to perform this service for those teams who used anything else. But.....that's why we have all of yuns out there - to provide working, simple auto modes ahead of time in all formats.

Teams use different pwm outputs for their drive motors, making it not truly a drop-in.

//Please replace pwm with actual values

#define leftmotor1 pwm01
#define leftmotor2 pwm02
#define rightmotor1 pwm03
#define rightmotor2 pwm04

leftmotor1 = 180;
leftmotor2 = 180;

...

Teams use different gear ratios for the motors, so without encoders (or something similar, that regardless makes the whole routine a lot less drop-in-able) it would be hard to travel the same distances. While crossing the first line should be doable regardless, trying to add the turn would take more work.

Those who haven't programmed autonomous by the time of the regionals are most likely not going to care too much about anything other than simple timed auto routines. "Drop-in" the easy stuff with a pre-arranged routine, and you'll have more flexibility to add more functionality at the event.

Here's my initial contribution. This is the basic structure from one of our simpler auto modes from last year. If a team has successfully implemented encoders, they can replace the "timercounter" variable with the encoder variable. Please note I have never once taken a formal C programming course, so if I don't indicate something in the most "elegant" or "concise" manner, so be it. Often, the more complex and concise notations of the experienced aren't suitable for quickly teaching those who know jack squat about programming. Suggestions for improvements welcome.

 
unsigned int timercounter;
unsigned int timercounter2;
unsigned char pathtracker;
 
#define leftmotor1 pwm01 
#define leftmotor2 pwm02
#define rightmotor1 pwm03
#define rightmotor2 pwm04

//Do a straight ahead timed move and stop - turn left at end of move
 
//Adjust values as necessary
 
#define NEUTRAL 127
 
#define STRAIGHTSPEEDLEFT   215  
#define STRAIGHTSPEEDRIGHT  200 //left side not as efficient 
#define TURNSPEEDLEFT       54
#define TURNSPEEDRIGHT      200
#define STRAIGHTTIME        140  // ~ 35 counts per second
#define TURNTIME            185
#define DELAYTIME           0
 
//Step 1 - Straight Ahead to get in position
 
timercounter++;
 
if (pathtracker == 0)
{
timercounter2++;
 
if (timercounter2 < DELAYTIME)
{
 //zzzzzzzzzzzzzz....delay start of movement
}
else
{ 
  if (timercounter < STRAIGHTTIME)
  {
       leftmotor1 = STRAIGHTSPEEDLEFT;
       leftmotor2 = STRAIGHTSPEEDLEFT;
       rightmotor1 = STRAIGHTSPEEDRIGHT;
       rightmotor2 = STRAIGHTSPEEDRIGHT;
  }
  else
  {
       pathtracker = 1;  //jump to the next step
  }
}
} 
//Step 2 - TURN LEFT.
else if (pathtracker == 1)
{
if (timercounter < TURNTIME)
{
  leftmotor1 = TURNSPEEDLEFT;
  leftmotor2 = TURNSPEEDLEFT;
  rightmotor1 = TURNSPEEDRIGHT;
  rightmotor2 = TURNSPEEDRIGHT;
}
else
{
  pathtracker = 2;  //jump to the next step
}
 
}
else if (pathtracker == 2)
{
leftmotor  = NEUTRAL;  //Stop moving
rightmotor = NEUTRAL;
}
 
/*
You can add additional steps if desired to cross lane divider, turn again, drive past opponents'
finish line, etc.  And even if it might be boring and easy to program, don't forget about keeping the simple "line up in the left starting position and drive out a few feet" blocking defensive autonomous in your gee-whiz bag of tricks.  It may often prove to be a better strategy if you're facing a bevy of good autonomous bots - that is, if your bot is robust enough to survive the expected broadside contact from the opposing robots driving your way. 
*/

Note that the left turn above is zero radius, when in fact, you might want to try and set up a gradual 180 degree turn that will take the bot smoothly past the lane divider. However, if you're running short on time or practice space to dial that kind of turn in, 90 degree zero-rad turns with a short move forward in between would be easier to set up.

I'll leave it up to others to add additional functionality if you wanted to include support for the IR remote to help indicate when to turn; i.e. you could program a longer timed straight move than necessary and use one of the remote functions to trigger the above program to step into the pathtracker = 1 left turn code. Another button (or another press of the same button - function written on 3 x 5 card would be "Jump to Next Autonomous Step") could then instruct the bot to jump from the turn step into the backstretch straightaway step. The IR commands would not replace the timed transitions - they would merely override the preset jumps prematurely. The timed jumps would still be there and occur should the robot not receive the IR commands from the Robocoach.

Not so hard - keep adding to it and see what we come up with.