MOE Header
 

Sub Teams - Programming

PROGRAMMING

  • TIP - Programming tutorials on the FIRST website are very helpful for getting an overview of C programming and the basics of the robot controller system. On-line programming manuals and operator interface/robot controller manuals provide much more detail.
  • Have all programming team members get familiar with all code and tutorials available from FIRST, Innovation FIRST, and from other teams (www.Chiefdelphi.com). No need to reinvent the wheel yet.
  • Work closely with the electrical and mechanical teams to understand where the design is evolving and what your role in programming both human control and autonomous functions will be.
  • List what your key tasks are and when they will be due.
  • Create and maintain a ranked list of what your team/robot would like to do during the autonomous mode. This ranking may change as you better understand your capabilities and strategies, but it is good to have a list.

PROGRAMMING

  • AUTONOMOUS- Decide what you want your robot to do during autonomous mode and how you plan to do it. The easiest would be a routine that would use dead reckoning (i.e. tell the drive motors to run for a set amount of time). If you want to use feedback to guide your robot, select one or more sensors and order them if necessary.
  • PROGRAMMING - Continue to familiarize your programming team with the default code, noting where you should add your own code for the autonomous mode and for the human control mode in the "users" routines.

AUTONOMOUS / HUMAN CONTROL PROGRAMMING INTERFACE

The transition between the autonomous code and the remote control code happens asynchronously.  In other words, you will not know which loop-through of the autonomous code will be the last loop.  If the autonomous code leaves a mess behind for the remote control code, chances are good that your robot will behave erratically for the remainder of the match.  If you choose to tackle the autonomous part of the game, a logical division of effort is to have a remote control programmer and an autonomous programmer.

The autonomous and the remote control programmers must decide early one which variables will be shared between the two sections of the code.

These shared variables are usually what are referred to as state variables.  They contain information about the status of various components of the robot.  For example, did the autonomous code close a gripper?  If it did, the remote control code needs to know this when it takes control of the robot or it needs to have an initialization section where it sets every state variable to a known and correct value.

If you have decided to have more than one autonomous routine resident in the controller memory – usually a very good idea – you need to provide a mechanism for the competition team to select which routine will be run.

AUTONOMOUS MODE SWITCHES

Putting mode switches on the robot is the most straightforward way to do this, but it takes away the ability to make a last second change of strategy.  Mode switches on the robot can be read at all times by the robot controller.  Mode switches on the operator interface cannot be read by the controller during autonomous mode.  The radio link is disabled.  If you want your autonomous mode selection switches on the operator interface, you must write your control program so that it continually reads these switch settings before the match starts.  Once the match starts, the autonomous program will read the last value.

ROBOT COMPUTER PROGRAMMING

AUTONOMOUS

Your autonomous programmers can continue writing code for whatever routine(s) you wish to run.  A simple autonomous routine would be to drive the robot forward for a given length of time.  Since the program loop executes every 26.2 msec, computer code, which tells the wheel motors to run for 38 loops will cause the robot to move for approximately one second.

Start simple and make sure those routines work before getting more complicated.  If you plan to use sensors, you may want to set up some initial tests either with a separate test board or with a Vex robot.

Until the robot controller is needed for your full-size robot, it could be used on a separate test board with the edu robot motors and any sensors you want to test.  The 5 V battery can be used to supply the necessary power. Alternatively, sensors could be mounted and tested on the edu robot itself.

RC (REMOTE CONTROL)

The programmers for the RC mode should be familiar with the default code and should begin planning how they want to modify this code.  By mapping out the inputs (joystick(s) and buttons) with planned outputs (motors, relays, etc.), you can see how to separate your code into different functions which can be written and tested separately if desired.  For instance, you may want one function for driving the robot, another function for moving an arm, etc.   It is always good to begin programming as soon as you have enough information to do so, because debugging computer programs often takes longer than expected.

ROBOT COMPUTER PROGRAMMING

TIME FOR AUTONOMOUS PRACTICE

Determine when the autonomous team can have sole use of the robot for testing code.  If necessary, negotiate this beforehand so everyone knows who get the robot and when.

For a well-functioning autonomous routine, practice must occur with the actual, fully functioning robot on a representative portion of the playing field.

ROBOT CONTROLLER / OPERATOR INTERFACE

At this time the electrical and programming teams should have made input/output assignments for both the robot controller and the operator interface.   This is especially critical for the programming team so that they can begin modifying the programming code to control the motors, relays, servos that comprise the mechanical systems on the robot.  

A review of the wiring rules should also be done at this to assure that sufficient wire of the proper size is on hand and that the rules for special circuits and proper fusing are being followed. Construction of the custom interface box should also begin at this time (these are the special switches not on the joysticks that allow the robot drivers to control the unique functions of the robot during competition).

 

ROBOT COMPUTER PROGRAMMING

Ideally, your robot is built and you are fine tuning the performance of the mechanical, electrical, and control systems.  A more realistic state is that you have your robot assembled, the wiring and actuators in place, and are testing a first cut at a control routine.  You should be testing the control program interaction with each sub system.  Questions to be asking and things to be checking out early this week:

* Are you correctly reading your sensors and operator controls?

* Do the motors rotate the direction you expected?

* Are you energizing the correct relays,

* The transition from Autonomous Mode to Remote Control mode.

* The Autonomous Mode selection scheme.

After each subsystem checks out, you should have your final version of the integrated control code.  Spend the rest of the week exercising the integrated control code along with the associated mechanical and electrical systems.  If you have an autonomous capability in your robot, this exercise period is where you tune your autonomous routine(s).

DEBUGGING AUTONOMOUS CODE

When you are ready to test your autonomous routine on the full-size robot, initial tests should be done with the robot on a cart.  Safety is very important because of the size and weight of your robot and the potential dangers of a runaway robot.  Always wear eye protection and use other safety protection (such as gloves) when needed.   Know how to use your "dongle" before you start running any tests.  Most likely your primary concern will be the wheels moving appropriately.  So your cart should be designed so that the wheels can move while the robot is held stationary.  If you have included other robot movements, such as an arm moving during the autonomous mode, then this also should be tested in the safest way possible.  Once you are confident that the robot is doing what you want it to do, then you can test it on the ground.  However, always be prepared for it to move faster and go farther than you expect.

KEEP BACKUP COPIES OF YOUR PROGRAM

Your programming team has invested a great deal of time in the development of the robot’s autonomous and operator-controlled programs.  It’s kind of hard to lose a 120 pound robot, but it is very easy to lose a program.  We cannot emphasize this enough – keep multiple backup copies of every version of your autonomous and operator control programs.  You WILL need them at some point.  Perhaps not even this year, but you will need them.  Trust us – we learned the hard way!

Home |  Search |  Site Map |  What is MOE? |  Contact |  FIRST

MOE, FIRST Team 365, a First State Robotics team
Wilmington, Delaware

Chairman's Logo