New coaches: testing autonomous code—even for the 15-second auton period—takes time; I hope that this post will assist you and your team in planning and running your autonomous testing efforts.

In previous games, there was usually a way to score 1 or 2 points in autonomous without much programming involved.

  • In Skyrise, one could simply drive away from the starting square, leaving the preload on the colored tile, and score 1 point. Many, many times, even having this simple code—scoring 1 point—was enough to win the autonomous bonus.
  • In Nothing But Net, one could preload 4 balls into the robot and shoot them into the net without ever leaving the starting square.
  • In Starstruck, even a pushbot could score 1 point by shoving their preload underneath the fence.

However, this year’s In The Zone game offers a particularly challenging autonomous period, as there’s no simplistic way to score anything; you must at the very least put a cone on a mobile goal or stationary tower. If your team finishes building the robot 2 meetings before the tournament, they will not have enough time to write or test any code, and are better off using their remaining time for drive practice.

A successful autonomous program requires time and planning.

To get ready for your auton testing, invest in a $20 competition switch. It will offer the most efficient way to test the program over and over and over.

Testing Autonomous Is Time-Consuming

Clock clipartIn games like Skyrise, a simple autonomous could be programmed and run with minimal time and testing. However, even in games like Starstruck, getting one star over or under the fence took many rounds of testing to work out the kinks in the robot’s movement.

Teams should understand that, for anything but the most simplistic movements, testing auton requires many, many iterations with numerous small adjustments to get things just right.

  • As team members gain in experience and programming ability, this process will move more quickly and smoothly, but it can still take many hours to get a 15-second autonomous routine functioning consistently. And even more time for a high-scoring set of movements.
  • The VEX cortex, motors, and sensors are not NASA Mars Rover-quality items; they have reasonably large limitations and variability, and only testing repeatedly will elucidate what those shortcomings are, and how one can overcome them.

A single task is usually easy to write a starting program for. For In The Zone, this could be: “We’ll drive down the side of the field and put our preload on that mobile goal,” or “We’ll put our preload on the stationary tower.”

  • Once your team has that code complete and compiled, it’s time to test, at which point it will probably become clear that life is not so simple.
  • For the 2 tasks in these examples, the hard part will be driving straight the 6-8 feet down to the mobile goal, or lining up perfectly to the stationary tower and driving forward just the right distance.
  • Or in either task, making sure that the robot has a good grip on the cone and doesn’t drop it may be something that the team had not yet considered—and that may require additional work.

Testing Autonomous Is a Good Use of Time

Check mark

A consistent and successful autonomous program can win matches. That auton bonus can make or break the final score.

  • Winning autonomous puts your team higher up in the rankings; remember, after your win/loss/tie record, the number of times your alliance has won the autonomous bonus is the next level of sorting the wheat from the chaff.
  • Therefore, it’s in the entire team’s best interest to support the programmers in whatever way is needed, and to make sure that activities like building, fixing, and driving don’t squeeze out the programmers’ needs.

Start thinking about autonomous scoring as soon as the game is announced.

  • Having a plan for autonomous from the get-go will save time in the building process. Sensors like shaft encoders and potentiometers need space in the robot structure, and adding them at the start of building will save a lot of time later.
  • Thinking about autonomous at the start of the season will also help in the project management process, making clear early on that time needs to be reserved for testing after the robot is built, before the first tournament. Knowing whether there’s a simple way to score points (like Skyrise), or no simple way to score points (like In The Zone) affects how many meetings need to be devoted to testing.
  • Programmers can also plan out a strategy of increasing complexity: first, we’ll do XYZ which can get us 2 points. ABC is really hard, so we can add that later to score another 5 points.

(Suggested by members of the VEX World Coaches Association Facebook group; join if you’re a coach or mentor reading this.)
Programmers can get started on autonomous right away, programming “block-wise.”

  • Create “movement blocks” with generic movements (such as a 90º point-turn using encoders or a gyroscope) that are ready to test as soon as the robot chassis is available.
  • Learn and start coding more-sophisticated concepts (like PID controllers) as soon as students are available or sufficiently experienced.
  • Write autonomous code that governs chassis movements only, so that when it is constructed, students can test ASAP and move forward with functionality for other robot components.
  • Movement blocks can be written (and saved!) so that they are applicable/re-usable in future programs or games.

Version Control Is Crucial

After a program has numerous movements, variables, sensors, etc., you will end up with many versions in short order—one version with XYZ; another version where we try to do movement BlahBlah with these other 5 steps instead; another version where we do YaddaYadda slightly differently, etc.

GitHub logoIt doesn’t take long to have so many copies floating around that people can’t remember which is which (especially if there are several programmers involved). This is our first year using GitHub (free – my favorite price!), and we’re glad we did:

  • It’s specifically designed to be a version-history keeper. (Yes, one can retrieve previous versions via something like Dropbox, but Dropbox is not designed to give you information about what’s in those different versions.)
  • Commit your file to the repository at the end of every meeting.
  • Add a description of the things that you changed when you commit.
  • Desktop plugin allows one-click commits, right from the taskbar, and easy sync of local files with the remote repository.
  • Retrieve previous versions at will!
  • Create branches, or “forks” for doing variations, new tasks, & testing, with the ability to merge those forks back into the main “tree” if desired.
  • Forks allow multiple people to work simultaneously.
  • GitHub has easy-to-follow tutorials.

Programmers Need to Concentrate and Stay Focused

  • I’ve found it most helpful to test autonomous with only the programmer(s) in attendance, with possibly 1 other person to help reset the robot & game elements. Any more people than that, and you will end up with a bunch of people gabbing away, serving only to distract the people focused on testing.
    • If you can find something else specific for the non-programmers to do, away from the field or in a separate room, that’s good too. Examples include working on the Engineering Notebook, working on Online Challenges or the team’s website, taking photos, cleaning up the work area, packing for a tournament, or polishing up the team’s game strategy.
  • Team members in attendance should all be actively participating. Everyone having the self-discipline to stay focused will move the process along more quickly. If the testing process goes at a snail’s pace, the programming team may run out of their allotted time with the robot before they’re done with their work.
  • Each team member in attendance should have a designated job.
    • One person should have their hands on the computer, and make sure they add or update comments as they go along.
    • If you use wired (as opposed to wireless) downloading, the programmer needs to be in close proximity to the field; as soon as one run is complete, someone needs to get the robot over to the programmer, take out the VEXnet key, and plug in the orange cable. As soon as downloading is complete, they should put the VEXnet back and move the robot back to the starting position. They should do these things without being reminded every time.
    • Another person can be responsible for resetting scoring elements and getting the preload ready. They should start this process as soon as the previous run is complete and people are done with discussion of that run.
    • If you’re using wireless downloading, team members should start resetting the cones and robot as soon as discussion of the run is complete.
  • Everyone should be paying attention when the program is run.
    • It’s not *just* the programmer’s job to be watching and evaluating what the robot is doing.
    • We find it’s useful to take a mobile phone video of the robot’s run so that team members can replay the movement as many times as necessary for the group to decide what changes need to be made.
  • REC-provided engineering notebookMake notes in your Engineering Notebook, or take notes on a clipboard as you go along. Even within the span of a minute or two, people will forget the specific changes they wanted to make, or will mix up the time or sensor values for step A and step B.
  • Team members should keep their minds open for other solutions. If people are just focused on making *this* code work right, they may miss opportunities to solve problems in new ways.

The Testing

  • Only change one thing at a time. I can’t emphasize this enough. If the robot is not driving straight, and you make 2 changes to the code, or you make a mechanical fix and programming fix at the same time, you will not know which one of those changes is the one that actually fixed your problem.
  • Work step-wise. You don’t need to run the entire 15 seconds of code if it involves many steps.
    • Get the robot’s first movement or first few movements working correctly before moving on to later actions.
    • How the robot performs those first few movements will affect where it is positioned on the field, so it’s generally not a good use of time to fix later steps until the starting movements are just right.
  • Make sure that your robot’s movements will fit in the allotted 15 seconds.
  • In my lab, the program has to work at least 3 times in a row to be considered a success. Especially after a long work session, it’s easy for team members to think that everything is done after it’s worked right 1 or 2 times, or if it works most of the time, with a a glitch thrown in every few runs.
    • Here’s where taking notes in the Engineering Notebook will bring everyone back to reality. If you can look at your track record and see that it never even works 2 times in a row, then the work is not done, unfortunately.
    • In our lab, the 3x rule is the law of the land. And in my experience, 3 times in a row is actually a pretty high bar. But competition conditions are completely unforgiving, and a program that works intermittently could easily not work in *any* of your tournament matches.

Three check-marks

I hope that this rambling has helped coaches get their teams prepared for autonomous programming and testing, with an understanding of exactly how long it can take to have a working, consistent 15 seconds. (See my previous post on the Kill Timer for one programming concept your team may not have considered yet.)