Sub Teams - 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.
- 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.
DESIGN OF OPERATOR CONTROL STATION
Discuss with other subteams what control functions (range of motion, degree of control, and desired mode of control) will be required for each mechanical system. Discuss with competition team the preferred way to map joystick / pushbuttons and to design the auxiliary control box. Design and order all parts for the auxiliary control box. Discuss to assure adequacy of I/O ports for desired control functions. Begin assembly of prototype operator interface.
The control station is how your competition team controls the robot. The FIRST kit provides everything you need to implement most control functions. The joysticks with multiple triggers and buttons can be programmed to handle various functions.
One decision you need to make is if you plan to have single or dual joystick control. Using a single joystick to control your robot is probably what you are used to. Most video games use single joystick operator interface. If you decide on the dual joystick scheme, the control inputs are similar to driving a tank, or a zero-turning radius lawn mower. Most teams seem to find the single joystick set-up easier to use.
The rules have always allowed for two operators to control the robot. If you decide to split the control responsibilities, you need to give some thought to the ergonomics of your control station layout. In the heat of a match you do not want your operator combo banging into each other as they try to score points. You will need to provide each operator with his/her own dedicated controls on one portable panel. One operator could have a joystick for driving and the other a bank of switches for controlling the warp drive.
When you design your operator control station, keep in mind that it must be able to quickly and easily be setup and removed. FIRST gives you very little time between matches and provides a skinny shelf behind the Plexiglas™ of the alliance station for your control station to sit on.
It is preferable to mount everything on a board or metal plate so the control station travels as a unit. Don’t forget to leave access so you can plug in the interface cables that are part of the playing field.
ROBOT COMPUTER PROGRAMMING
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 First Tech Challenge 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!