kauailabs / kauaibotsfirst2010 Goto Github PK

Tune the Ankle PID controller to ensure it reaches the specified value quickly 
and accurately.

Now that we have the DVDs with WindRiver on it, we need to get them installed 
onto all 
development computers (esp. BotBall3 and the black Dell laptop).

I reviewed the command/subsystem framework, here's the basic approach for 
writing the Tilter code.



1) Make the default command for the Tilter Subsystem the 
SetShooterTiltAngleDegrees command.



2) In the SetShooterTiltAngleDegrees command:



 This should require the tilter subsystem

 When it executes, get the "shooter joystick" object from the OI, using OI::getshooter_joystick() method.

Then, it invokes the GetSlider() to get the value

Then, it somehow translates that to an angle (you'll need to figure out the 
min/max angles of the tilter, and figure out the equation to map the slider 
value to that range).

Then, it invokes a subsystem command to set the angle of the tilter



3) in the Tilter subsystem the setpoint should be set to the distance that 
corresponds to the angle the tilter should be set to.



The tilter's proximity sensor will read out the value (in millimeters) the 
tiler is at; this needs to be converted to an angle (by understanding the 
geometry of the tilter).



The PID controller's job is to get the angle calculated by the proxmity sensor 
to match the setpoint.



Finally, once the setpoint is OnTarget(), then the output motor can be turned 
off to preserve the battery.



4) I will be working on the sensor code while you're working on this.



 I don't think this command is ever finished, unless it is Interrupted. If it is interrupted, it should turn off the motor.

[deleted issue]

The Manual Aim command allows the shooter to take over rotational control (but 
NOT forward/back and strafe control) of the driver system.  When the Manual Aim 
command is active, the twist value from the shooter joystick will be used to 
rotate the drive robot.  During the Manual Aim command, the driver joystick 
will still be able to manipulate the forward/back and strafe axes of the drive 
system..

In a manner similar to ArmHigh, write the code for ArmUp, Low, Mid.

The graphs created w/Wolfram Alpha were great!  I think it would be good if we 
had graphs (printed out, for our "design notebook") of the joystick response 
curves for the X, Y and Rotational Joystick Axis.

Whenever the code changes, these response curves should be update.

The out should be a graph that we can include in our design documentation.

Update Jaguar CAN firmware on all Jaguars to the most recent version.

Configure the CAN addresses on each of the Jaguars.

Configure the 2CAN to work with the Jaguars.

Test.

The competition robot ships out on 2/18/2013.

Before then, software must be used to valid the correct low-level functioning 
of all actuators and sensors on the robot.

The plugin needs to draw a representation of the 3 targets,
and also highlight the currently selected target,
as well as allow the user to change the currently selected target.

In addition, the plugin should indicate whether the targeting system currently 
believes the robot is targeted successfully on any of the targets.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

The Ready command will ensure that the leg is in the back position, and some 
amount of tension is currently applied.

Thus, the Ready command will control the Leg subsystem, and the Tensioner 
subsystem.

In order to support the ability to display the ready command to the 
driver/shooter, the "ready" dashboard status value should be conditioned 
appropriately.

the Robot Preferences are values that can be edited from the Smart Dashboard.

Each preference is defined by a unique string.

The task is to configure the Robot Preferences in the dashboard to include all 
preference values in the robot.

I reviewed the command/subsystem framework, here's the basic approach for 
writing the Climber code.



1) I think we need a new command called "lower all hooks" which becomes the 
default command for this Subsystem, so add this command to the competition 
robot software.



2) This command can be interrupted by any of the other commands (raise/lower 
front/rear hooks).



3) In the default command



  Require the Climber subsystem

   In the execute method, let the winch motors run for (some time period we don't know yet) to ensure they are completely down, then turn the motors off.



4) In the other commands



  Require the Climber subsystem

  The commands get executed repeatedly (they are scheduled whenever the corresponding button is pressed).

  So, they should turn on/off the associated winch motor.

The existing drive mule code passes in joystick values to the mecanum drive 
class.

The mecanum drive class has an input joystick adjust member function to "scale" 
the joystick value to provide ideal redsponse for drivers.

But the mecanum drive class should be controllable by various means (kinetix, 
etc.) that don't use joysticks.  All knowledge of joysticks should be moved to 
the drive mule class instead.  This will make the mecanum drive class more 
reusable in the future.

During testing on Thursday 03/08, we noticed the balls would slip down the 
tower as the robot moved.  James thought separating the ball release (shooter) 
from the chute might help.  He is also thinking of making the washer around the 
hopper mechanism larger to hold the balls up at the top of the tower after 
they've been collected (instead of at the bottom of the tower).

When the ZeroYaw command is invoked, the nav6 IMU will be command to reset the 
current yaw value to zero degrees.

The RotateToTarget command will automatically rotate the robot to zero degrees. 
 To accomplish this, the RotateToTarget command will direct the Drive subsystem 
to rotate to zero degrees.

Drive -> all four wheels drive by Joystick Y.
Steer -> all four wheels driven by Joystick Twist.

Need to add a new command ("SimpleDriveCommand")

Need to add a new method to control motors to the SwerveDriveSystem subsystem 
code.

Need to add "SimpleDriveCommand" as the subsytem's default command.

The Aim command will rotate the robot so that there is a straight line from the 
robot to the target.  Thus, the Aim command must direct the Drive subsystem to 
rotate to a specified angle.  The angle to be rotated should be "zero degrees", 
assuming the IMU is properly zeroed.

Validate correct behavior of the magazine (both shooting, as well as the 
display of number of frisbees at the driver station).

Validate correct behavior of the Camera Gimbal.

Validate correct behavior of the climber.

Tune PID coefficients for the Tilter's PID Controller

The test Mode dashboard is displayed when "Test mode" is entered in the driver 
station.

This provides low-level control of all objects (actuators) on the robot and 
low-level display of read sensor values.

By default, all controls are placed on one top of each other; these controls 
need to be placed so that they can all be accessed during checkout of the robot.

1) writing code that'll run in Linux on the Pandaboard (which we are wiring 
into the robot, and will be ethernet-routed to the CRio); this code will 
configure the camera, acquire images from the camera (over ethernet), 
decompress the images, detect targets, and calculate azimuth each target and 
elevation to each target.

2) writing code to communicate detection info to the CRio over ethernet

3) unit testing the Pandaboard-hosted code

A number of issues have been encountered during the testing of the initial 
autonomous code with respect to repeatability and timing:

1) The shooting mechanism is slow and does not have repeatable timing:
   - When moving, the balls slip in the bands in the tower due to robot vibration.
   - The entire sequence of lift and shoot takes 5-10 seconds for the first ball, and perhaps even more for the second.

Layout all controls on the Smart Dashboard.

Save layout, to ensure it is automatically loaded each time the SmartDashboard 
starts.

Periodically review the layout, in case new values have been added, and/or 
existing values have been renamed or deleted.

Full four-wheel test of the swerve drive system to ensure it works correctly 
and efficiently.

Full system-level test

Goal is to get a single drive/steering wheel pair to respond quickly and 
accurately to commands from a joystick.

I reviewed the command/subsystem framework, here's the basic approach for 
writing the Camera code.



1) Make the default command for the Camera Subsystem the RunCameraGimbal 
command.  This is a new command that needs to be created



2) In the RunCameraGimbal command:



 This should require the camera subsystem

 When it executes, get the "shooter joystick" object from the OI, using OI::getshooter_joystick() method.

Then, it invokes the GetTwist() and GetY() functions.  Twist corresponds to the 
azimuth servo, Y corresponds to the elevation servo.

 Then, it invokes a subsystem command to set the servo values correspondingly.



3) In the subsystem, there should be set azimuth and set elevation methods 
which control the servos.



I don't think this command is ever finished, unless it is Interrupted. If it is 
interrupted, it should reset the azimuth and elevation servos to "0" (home).



Note that this command may get interrupted whenever some automatic targeting 
happens (like in autonomous, or perhaps in teleop depending upon the code that 
Brian writes).

Validate correct behavior of the shooter.

Once all software is completed, review the drive station logs under several 
different circumstances to ensure:

- adequate power for the match exists
- CPU utilization is not too high
- response to drive station commands does not get large enough to cause 
perceptible delays

Bridge balancing can be aided by a cooperative balancing algorithm which 
utilizes the pitch (and roll) gyroscopes and accelerometers.  

When the pitch or roll angular velocity exceeds a threshold, the algorithm 
begins and it will drive the reverse direction with a velocity proportional to 
the detected angle.  

During this time, the traffic cop light will come on to indicate to the driver 
that they should not attempt to drive the robot.

When the accelerometer and gyro indicate that the current angle (and angular 
velocity) are low, the mode will disable itself.  At that point the traffic cop 
light goes off, and the driver will know that they can resume control of 
driving the robot.

1)  Assemble the chassis, motors.
2) Prepare all wiring (but do not connect the wiring)
3) Kit all the parts, in prep for the students to begin assembling the computer.

During autonomous testing, we noticed that the robot is drifting during Mecanum 
(left-right motion).

1) When driving straight right, the robot's right rear moves farther than the 
right front, so robot is at an angle.
When driving straight left, the robot's right rear moves farther than the right 
front, so robot is at an angle.

2) When transitioning from "drive straight back" to "drive right", the robot 
appears to jerk a bit, causing an initial rotation to be introduced.

These two behaviors compounded are causing significant drift in the autonomous 
software.

Analysis:

1) Review of the feedback from the encoders and the motors amps:

- All encoders (and thus the wheels) are moving at the same speed.
- The front motors are being driven at a higher amperage than the rear.

This suggests the front wheels are slipping, likely due to uneven weight 
distribution.

2) We have no analysis yet of the cause of the "jerk" at the transition from 
driving backwards to driving right.  Attempts to add a "wait" were no 
successful, but this appears to have been a coding error.

I reviewed the command/subsystem framework, here's the basic approach for 
writing the Magazine code.



1) Make the default command for the Magazine Subsystem the FireFrisbee command.



2) In the FireFrisbee command:


 This should require the magazine subsystem

 When it executes, get the "shooter joystick" object from the OI, using OI::getshooter_joystick() method.

Then, it invokes the ? fuction to get the trigger button value

Then, it sees if there are any frisbees in the magazine (invoking the 
subsystem's method to get the count of the frisbees).

If there are, then it:

- ensures the frisbee "load" solenoid is energized, and the "fire" solenoid is 
not

- wait a little while (to make sure the frisbee falls into place)

- releases the "load" solenoid, and energizes the "fire" solenoid



3) in the Magazine subsystem it has a proximity sensor.  The distance read by 
this sensor indicates whether there are 0, 1, 2, 3 or 4 frisbees in the 
magazine.



And it has methods to "load" and "fire", and to read out the current state 
(there are four states:  load energized, load deenergized, fire energized, fire 
deenergized)



Please note:  Tom said there's one case (at startup) where we need to have both 
"load" and "fire" energized.  So keep things flexible enough to handle this.



The tilter's proximity sensor will read out the value (in millimeters) the 
tiler is at; this needs to be converted to an angle (by understanding the 
geometry of the tilter).



4) The dashboard needs an indicator of how many frisbees are in the magazine.



5) I will be working on the sensor code while you're working on this.



I don't think this command is ever finished, unless it is Interrupted. If it is 
interrupted, it should probably de-energize the loader and shooter

The top velocity(in RPMs) in each of the X, Y and Rotational dimensions needs 
to be tuned for the final robot configuration.

In addition, the joystick drive response curves also require tuning.

Here's the purpose of the software:

We want to know:

- Torque (in oz-in) required to get the robot moving
- Max RPMs we can expect at given robot mass/gear_ratio
- What Gear Ratio we should use to reach Peak Pushing Power at given robot mass
- What Gear Ratio we should use to reach Peak Efficiency (Speed) at given robot 
mass

Here's how to calculate this stuff:


Force_of_friction = static_coefficient_of_friction * robot_mass * gravity [in 
units of Newtons, which is same as Kg meters/second^2]

Torque = Force_of_friction * Radius_of_wheel [in units of Newton meters]

static_coefficient_of_friction = .7 (forward direction) OR .6 (sideways) [from 
andymark.com gearbox spec sheet]

robot_mass = [variable, up to 160lbs w/bumper and battery] - user should input 
this, it will change based on design]

To convert pounds to kilograms:  x pounds * 0.45359 Kg

gravity = 9.81 meters/second^2 - this should be a constant

Radius_of_wheel is 4" (from andy mark spec sheet of the mecanum wheel) - this 
should be a constant

To convert inches to meters:

1 in = 0.0254m

The result is the "torque_require_to_get_the_robot_moving" - in units of Newton 
meters.

But the Andy mark motor spec sheet is in units of oz-in, so you have to convert 
newton meters to oz-in.

1 oz-in = 1 Newton meter * 141.6

Further, there are four wheels on the robot, so you divide the 
torque_to_start_the_robot_moving by number_of_wheels.

Further, the gear ratio has to be taken into account:

Per the andymark spec sheet for the gearbox, the standard gear ratio is 12.75 : 
1 [this should be a constant]

So divide the torque_to_start_the_robot_per_wheel by curr_gear_ratio (12.75).

[this yields the torque_to_start_the_robot_per_geared_wheel - the minimum 
torque to get the robot moving]


*****

Next, we want to calculate the maximum rpms we can expect for a given torque.

The motor specs give us info on how many RPMs to expect at a given torque.

Per the CIM motor spec sheet response curve on the FIRST website (these should 
be constants in the software):

Free Speed:  (Max RPM of motor shaft BEFORE gear ratio is taken into account, 
if robot weighed 0 pounds) = 5310 RPM
Stall Torque:  The Max Torque (in oz-in) the motor can generate - to push it 
any farther would burn out the motor! = 344 Oz-in.  If you want a slow, but 
very strong "pusher" robot, this is what you'd want.
so at torque 0 oz-in (the minimum torque), the Max RPMs is 5310 RPM

At stall torque 344 oz-in (the maximum torque),the Max RPMs is 0.

There is a linear equation which can therefore relate the 
torque_to_start_the_robot_per_geared_wheel to a maximum RPM, as follows:


  Max RPM = 0 RPM + ((5310 RPM / 344 oz-in) * torque_to_start_the_robot_per_geared_wheel)

*****

From the motor specs, we also get this info:

Peak Pushing Power:  ~175 oz-in @2500 RPMs.  THis is the sweet spot for a 
strong robot.
Peak Efficiency:  ~35 oz-in @4700 RPMs.  This is the sweet spot for a very fast 
robot (but weak pushing power because of low mass/low torque).


To calculate what Gear Ratio we should use to reach peak pushing power at given 
robot mass:

   curr_gear_ratio / (peak_power_rpm / Max RPM)

Next, to calculate what Gear Ratio we should use to reach peak RPM at given 
robot mass:

   curr_gear_ratio / (peak_efficiency_rpm / RPM)

- Integrate Pandaboard into the robot, which will entail consuming the 
detection info, and issuing commands to set the shooter's elevation angle, and 
the drive system's rotational angle, taking into account the current 
azimumth/elevation of the camera, and known geometry of the camera's placement 
on the robot.

- Test this at a system level, tune, etc.

The 2012 C++ Mecanum Drive code should be ported to Java.

This should also include modifying the code to use the latest Java nav6 
Library.  Information on this library is available at:

https://code.google.com/p/nav6/wiki/Java

1) Make the default command for the Shooter Subsystem the SetShooterRPM command.



2) In the SetShooterRPM command:



    This should require the shooter subsystem

    When it executes, get the "shooter joystick" object from the OI, using OI::getshooter_joystick() method.

    Then, it invokes the GetZ() to get the value

    Then, it invokes a subsystem command to get the motor to the value from the joystick



    I don't think this command is ever finished, unless it is Interrupted.  If it is interrupted, it should turn off the motor.

When the robot is on the bridge driving straight ahead and there is an incline, 
even though no driving commands are being sent to the robot, gravity will cause 
the robot to move.

When driving on the bridge and playing the role of the "still" robot this 
behavior is not desireable.

E-Brake mode will monitor the wheel encoders and if they are not still, will 
automatically drive in the opposite direction with a velocity proportional to 
the encoder speed (and perhaps taking the current angle/angular velocity into 
account as well).

This mode will be enabled by the user via the drive joystick.

MOve the controls to the right places
Make sure all controls work properly

Tune the Drive subsystem PID controller values (which are used by the CAN 
Jaguar speed controllers) to ensure smooth and rapid drive system response.

Validate correct behavior of the tilter.

The Stick Drive command is the command typically used in Teleop mode.

This command will read the X, Y, and Twist values from the driver joystick, and 
command the Drive system to drive based upon these values.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Need a simple autonomous program that drives straight ahead and shoots.  The 
robot is lined up with its rear wheels parallel to the base of the key, and 
it's enter axis in line with the basket.