I realized at our tournament yesterday that we need to add a few more steps to our autonomous program: kill timers.

The pseudo-code of our In The Zone autonomous at present is like so (with forward & backward robot driving governed by ultrasonic sensor values):

  1. push cone forward
  2. back up a little and flip out claw from folding position
  3. drive forward, grab cone, raise lift
  4. drive forward
  5. lower lift and place cone on stationary tower
  6. open claw, back away

Item #5 above will be our first inclusion of a kill timer. What do I mean by that? Well, step 5 uses a potentiometer (POT) on the lift to figure out how far to go up & down. It’s in a standard sensor-based while-loop:

while POT > xxx
   run lift motors down
   teeny-tiny wait (20 milliseconds)
   get new POT value

We’ve seen in our lab a few times, and at least once in competition, that when we lower the cone onto the tower, sometimes the cone is a little off-kilter and gets jammed onto the tower (instead of nesting cleanly, straight up and down). When it’s off-kilter, the lift cannot move downward any farther to complete the instructions of step #5. So what happens? The cortex tries to *keep* running the lift motors down anyway, for the rest of the 15-second autonomous, risking a stall if it goes on for any length of time.

So What Does a Kill Timer Do?

A kill timer allows the code to break out of a while loop if it’s been running for longer than a set amount of time, preventing gear-grinding, stalling, or tipping over.

We used them last year on our Starstruck autonomous code to stop raising our forklift to dump stuff over the fence if it had been running for more than a reasonable length of time. It saved us from breaking gear teeth, and also from tipping over backward (both of which happened to us before we added this code).

Kill timers are generally used in conjunction with sensor-based movement. If the sensor readings get reset, or the robot is blocked by another robot or field element, or spun around by another robot hitting it, then the program may try to run the motors WAY past the point of component safety or robot stability.

Built-In Timers: easyC & RobotC

Both easyC and RobotC have built-in timers that you can make use of in your program; easyC has 6 and RobotC has 4.

  • In easyC, you have to set the timer to 0, make it start, and then make it stop (all of these steps are in the “Timers” block of the “Program Flow” section of commands). Timer values are all in milliseconds. Check out the easyC Help section for details.
  • In RobotC, once you clear a timer—ClearTimer(T1), if using timer #1—that automatically starts it running; to check that timer’s value, reference time1[T1], which will return milliseconds. (Note that the Clear command uses parentheses around “T1” and the time1 command uses square brackets.) Here’s a RobotC reference sheet on timers.

Kill Timer Pseudo-Code

Going back to our pseudo-code from up top, we will change step #5 of our autonomous routine to something like:

clear/start timer
while (POT > xxx) and (timer < 2 seconds)
   run lift down
   teeny-tiny wait (20 milliseconds)
   get new POT value
   get new timer value

This code will instruct the robot to run the lift downward until the potentiometer gets to xxx level, but if it’s been running for 2 seconds or more, break out of the loop and move to the next step.

Every Situation Is Different

You’ll have to decide, based on your robot’s movements, what the program should do if the set time is exceeded. There are some times where it’s OK to move on to the next step of the program (like with our forklift-dumping from last year). Other times it’s best to just stop all movements for the rest of the 15 seconds autonomous period. If your programming skills are more advanced, you can consider more-sophisticated actions that might salvage the situation.

If your team uses sensor-based movement in autonomous, take a look at your team’s code and think about what would happen if your sensor values got reset in the middle of the movement, or if the robot were prevented from completing a given movement. If something bad would result, include some form of kill timer in your program. A few lines of code can keep the robot from tipping over or stalling, and save a lot of heartache at a tournament.

Share this post: