Robo Vision 3D – Software by fzs18703


									Robo Vision 3D – Software
Contributed by Anne Bergeron & Steve Shade
In the previous technical article, the electrical system was discussed. The electrical
system has two objectives. The first is to connect most of the robot's mechanical systems
to an energy source (even pneumatic sources require an electrical pump to create
pressure). The second is to bridge the mechanical systems to the software that
determines the operation of the robot. This week we will talk about the robot's software.
The C Language - The Innovation FIRST Robot controller is a user programmable
device that controls the robot. This article is not designed to present the basics of the C
programming language. No C code is presented in the text. Your team will want to have
someone who is comfortable with the basics of the language (defining variables and math
operations). More complex topics like arrays, pointers and structures are not required for
FIRST applications but may be useful if carefully used. Some good resources that
provide an introduction to C are:
FIRST has this information in the Team Resources Section
This site more closely following text book format:
Some more advanced topics can be found in Hibner & Shaul "Advanced C
Programming" presented at the 2005 FIRST Robotics Conference Workshops. The
document can be found at:

Program Design -As with any other system, the programming should be thoroughly
designed on paper before implementing (typing the code). The software design has two
objectives: the first is to force the programmer to think through the entire problem; the
second is to allow the programmer to communicate his/her idea to the rest of the team
who may not understand the details of programming. The programmer has no chance of
creating working code without understanding the mechanical and electrical systems that
he/she is attempting to operate.
We will use an example to illustrate the program design. Let's assume that we have a
robot that utilizes a lift. When using a lift, we don't want to hyper-extend the lift on the
field. One design requirement is to have the lift automatically stop before it extends too
far; even if the driver commands the lift to go higher. The following table would show
the design for this system's requirement:

Component: Lift
Purpose:     Stop the lift form Hyper-extending.
Method:       Use the y axis from a joystick in P4 to extend the lift. When the lift is at
maximum height, a limit switch will turn off signaling that the lift should be held in
Limit Input: RC_digital_in_6
User Input: p4_y
Output:      PWM6
Pseudo Code: Code                               Comments
                if (rc_sw_digin_6 == 1) {            If the limit switch is "on" then set
                     pwm06 = p4_y                   the motor output to value of P4_y
                else              {                Else the limit switch is "off"
                     pwm06 = 127                   so set the motor to off

No matter what form, tables, written prose, block diagrams or any combination, is used,
the outcome of the documentation is pseudo code. The pseudo code above can easily be
transformed into usable C code. Since most systems are more complex than the example
above the documentation is substantially more complex, but the end result will provide a
more structured approach to a difficult set of problems.
Creating a document that describes the operation of each system will help in tracking
robot changes and allow for code checking by other team members with little
programming experience. This documentation along side of well-planned electrical
documentation can easily save hours of debugging work because both the team members
wiring and programming the robot will all be using the same input, outputs and notation.
Code Checking Policy -Another suggestion is to create a code checking policy. One
suggestion is to have one mentor and one student review any changes to the code before
the new code is downloaded to the Robot Controller. This will allow a fresh set of eyes
to examine the programming before changes are implemented. This will also require that
all code be well commented so that someone who did not create the code can very
quickly understand what is supposed to happen.
Autonomous -The autonomous component of the game was added in 2003 as a way to
involve more software in the game challenge. The autonomous segment has made many
teams coding problems only get worse. Autonomous is a great learning ground for
students and mentors. However, this challenge can easily consume many resources and
much time that can often be spent on more pressing matters. The human controls and
simple feedback should be the most important aspect to the programmers. If these
components do not work, the robot will not properly function for two minutes out of a
two minute and fifteen second round. That's 89% of a single match! Autonomous code
should be worked on from the start, but when it comes to generating useable code, the
human operation segment should take priority.
A good source for autonomous programming is Larkin's "Writing Killer Autonomous
Programs" Presentation given at the 2005 FIRST Robotics Conference Workshops. The
document can be found at:
Other Tips
      Use the provided variable names whenever possible. This will allow other people to
help debug problems at competitions. Most teams utilize the Innovation FIRST
      Unless absolutely necessary (there is no other possible way to find a solution) do not
           Cryptic Variable Names
All of these items add complexity to your code. Loops will also use significant
computational time and in some cases can be infinite if not defined properly. Also, if
problems arise, then someone who can help will likely suggest starting form scratch
rather than attempting to fix complex code. You also never know when your
programmer will not be around and someone from another team will have to help.
Again, if you have any questions about this or any other FIRST topic, please don't
hesitate to email us at

To top