[CRUSH-code] Fw: **FIRST EMAIL**/2006 FIRST Robotics Competition Software Overview

Christopher H Hanson Christopher_H_Hanson at raytheon.com
Wed Jan 25 11:15:35 MST 2006


Joann,

When I left yesterday, we had the following working:

Robot can be driven with a single joystick (all motors and speed
controllers working).

Camera can track light (move turret to center on target), and display
values of pan, tilt, blob size, and confidence.


All of this took surprisingly little custom code.  It was just integrating
it into the robot that was difficult.


We are currently working in MPLAB.  Bill has tried to move this to Eclipse,
but he is having some problems with the frc driver settings.  Once he gets
this figured out, we will start using it.

The only code modifications that I have made have been very minor ones to
the "user_routines.c" file.

In the function "Process_Data_From_Master_up" where all of the built in
camera code is, we uncommented the function call "Default_Routine()".

In "Default_Routine" we set the pwm outputs to the speed controllers to the
following:

      pwm04 = Limit_Mix(2000 + p1_y + p1_x - 127);
      pwm05 = Limit_Mix(2000 + p1_y - p1_x + 127);

p1_y is the y axis movement of joystick one
p1_x is the x axis movement of joystick one
pwm04 is the output to the Left speed controllers, and pwm05 is the Right.

What we need to do next is write code to make the robot "move toward the
light".

We may want to take this in baby steps.  I suggest that we start by having
a dead-man-switch on one of the joysticks that tell the frc to follow the
camera, then compare the angle of the pan to forward (127). If the values
are different, increase/decrease the p1_x value to move it toward the pan
value.  We will also need to set a tracking forward speed value for p1_y.

Because of the response lag between the camera tracking and moving, we may
want to have a maximum value of change for each cycle to avoid having the
robot overshoot the target, and have to correct.

We can also use the size of the blob and the tilt angle to determine when
we are close enough to the target.

After we get this working, we can mount the camera sideways, and see how
our code works.

After that works, we can incorporate this into Bill's autonomous eeprom
code that will allow us to select it as an option.

Once the frame and shooter are mounted, we can then work on the firing of
balls when target is acquired.


Any suggestions?

Chris Hanson
360-9007



More information about the CRUSH-code mailing list