proserven / team-100-wildhats Goto Github PK

We're going to control the position of the pivoting climber arm using 
pneumatics. We need to be able to move it into position after the start of the 
match and retract it later.

Work with the mechanics and electronics subteam to work out the steps of a 
finite state machine for robot climbing.

TextBoxes and Formatted text fields both seem to display just 3 digits after 
the decimal point. Our PID constants could use more digits.

Maybe this can be changed using NumberFormat:
http://docs.oracle.com/javase/1.4.2/docs/api/java/text/NumberFormat.html
NumberFormat nf = NumberFormat.getInstance();
nf.setMaximumFractionDigits(5);

Does SmartDashboard call this somewhere?  It appears to use swing heavily. Does 
swing have a default?

We've seen several crashes in SmartDashboard, such as when 2 camera images are 
displayed. Building the  SmartDashboard would enable us to debug and perhaps 
fix the problems.

SmartDashboard and NetworkTables can be found on firstforge.org. We can 
download them via TortoiseSVN and build them with Netbeans. You need a 
firstforge account to do that.

We should figure out how to use LiveWindow, with and without RobotBuilder.

Some instructions are here:
http://wpilib.screenstepslive.com/s/3120/m/7932/l/84110-displaying-livewindow-va
lues

Write up a clearer set of instructions here, including when/where/why you'd use 
it (e.g., test mode):
https://sites.google.com/site/team100wildhats/subteams/software/working-with-sma
rtdashboard

We'd like to nicely arrange metrics on the SmartDashboard, group data by 
subsystem, automatically select the right display widget (e.g., lineplot), etc. 
If we can't do this effectively with the existing widgets or with LiveWindow, 
we could build our own widgets as extensions.  Take a look at the PID widget as 
an example.

Download most recent wireless bridge configuration utility. Configure and test 
new wireless bridge in the KOP.

We have too many digital I/Os from sensors: 3 full encoders, 2 half encoders, 
and the compressor pressure switch consume 9 already. We'll additionally need 
several limit switches, metal senors, etc. So, we need to set up an Arduino to 
read the additional inputs, as we experimented with last year.

1. Read about PID:
https://sites.google.com/site/team100wildhats/subteams/software/software-project
s/robot-control

2. Compute the process gain by measuring the speed at different output levels. 
You should be able to adapt this program to do it:
http://code.google.com/p/team-100-wildhats/source/browse/#hg%2FIsis%2FFeedForwar
d

3. Tune PID parameters. You should be able to adapt this program to do it:
http://code.google.com/p/team-100-wildhats/source/browse/#hg%2FIsis%2FPIDCruiseC
ontrolv3

Compute and sanity-check the distance ratio.

Start with a P value so small that nothing happens. .001 might not be small 
enough -- try smaller, if necessary. The process gain should give you an idea 
of the ballpark

Design a SmartDashboard layout and check in the saved config.

Someone needs to look at the rules to see what position our robot could start 
from in autonomous and figure out how to move it into shooting position.

Characterize, how close does it need to be to accurately sense.

Sam developed some code to time the periodic loop intervals here:
http://code.google.com/p/team-100-wildhats/source/browse/Sam/RobotLoopTiming/Loo
pTiming/src/edu/wpi/first/wpilibj/templates/Counter.java

There's also a Timer class in wpilib that gets the time, from the FPGA, IIUC.

We should add code to Robot2013 that puts the loop execution interval to the 
SmartDashboard.

backport.util.concurrent, which supposedly will work with Java 1.4, can be 
downloaded here:
http://sourceforge.net/projects/backport-jsr166/?source=dlp

It comes with a jar and with source.

Sam wrote an example here:
http://code.google.com/p/team-100-wildhats/source/browse/Sam/ThreadPoolRobot/src
/edu/wpi/first/wpilibj/templates/RobotTemplate.java

We need to figure out how to either link with the jar, or rebuild from source. 
We could try to create a project file similar to the one for wpilibj:
http://wpilib.screenstepslive.com/s/3120/m/7885/l/79739

PID Magic

We need to design the climber elevator position control. We probably want to 
use position PID to smoothly move the elevator to set positions in the climber 
state machine.

take into account ease-of-access and functionality.

Figure out how to sense upside down frisbees

From Laura:
One leg of the power wire to a motor needs to be fed through the hole in the 
sensor.
The sensor needs to be supplied power (between 5.4 and 13.2V) and provides an 
analog output proportional to the current.
I believe that, similar to the gyro, it puts out a voltage level half of the 
supplied power level when there is no current and then increases or decreases 
depending on the polarity of the current flow.
Possible uses:
·         Since current is proportional to torque, these sensors may be useful 
for measurements on prototypes.

·         Use in tuning control loops to help determine maximum accelerations

·         Use as a “torque limit”. At the WRRF workshops, team 846 
described how they determined that they had a tube fully inserted in their 2011 
claw when the motor current increased. We might be able to see when the robot 
weight is no longer being supported by the climbing mechanism.

Jameco Part no. 1851915
CSLA2CD 
http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_1851915_-1
http://sensing.honeywell.com/index.php/ci_id/49794/la_id/1/document/1/re_id/0

We should have 5 of these somewhere.

Figure out how to interface with metal detectors (ask Mr. Nehring for info). Do 
device characterization, post to site.

^

We'll likely need to use state machines this year to control parts of the 
robot, such as the climber.

See the turnstile example here:
http://en.wikipedia.org/wiki/Finite-state_machine

The basic pattern is that the robot will need to do one thing for a while, 
until it figures out it needs to do something else, and then it will do that 
for a while.

We could use a different command for each state. If the states just proceed in 
a linear sequence, we may be able to use a command group to represent that.  If 
there are decisions (do A if one thing happens, do B if something else 
happens), then we may just need to explicitly start the new command from the 
previous one.

It's also possible to use enums, as described here:
http://www.javacodegeeks.com/2011/07/java-secret-using-enum-to-build-state.html

But one advantage of using separate commands is that it's easy to display which 
command is executing on the SmartDashboard.

We're going to use a maxbotics ultrasonic rangefinder to determine distance to 
the wall in autonomous, during calibration, and perhaps during teleop. 

We need to decide where to put it on the robot, such that it points at the wall 
rather than through a target, and such that it won't get a lot of interference, 
such as from the frame of our own robot.

We probably will drive with the tower vertical.

A team last year drew a picture of their robot on their dashboard last year and 
showed the positions of balls on the robot. They apparently won a control award 
for this.
http://www.chiefdelphi.com/forums/showthread.php?t=105052

We could generate an image from the cad for our robot and overlay status on the 
image.

The only award that software teams can win is the Rockwell Innovation in 
Control Award. Here is FIRST's description of the award:

Award celebrates an innovative control system or application of control 
components (electrical, mechanical or software) to provide unique machine 
functions.

Find out which teams have won the award in the past for software (at both the 
regional and championship level) and what they have won it for. Brainstorm 
ideas on what we could do to win as well.

We're going to need to set a bunch of tuning parameters, such as for the PID in 
the shooter. Daniel figured out how to store them using the Preferences class. 
His example is here:
http://code.google.com/p/team-100-wildhats/source/browse/#hg%2FDaniel%2FPreferen
ces%20Test

We should add preferences to Robot2013, so we can simply add new parameters as 
needed.

An alternative to TankDrive and ArcadeDrive has been proposed: one joystick for 
speed/direction (throttle) and one for turning (twist). We should implement 
this using an old robot so that the drive team can evaluate the approach.

We've put the I/O list on the site. We need to update robotbuilder to match. We 
also need to clean up the subsystems and commands to match our current 
understanding of the robot functions.

We're going to put a number of digital inputs on an arduino. We need to figure 
out how to represent that in robotbuilder.

Learning robot - drive, then remember joystick values to replay for auton.

Also might need PID for position and gyro. We'll need to integrate the PID with 
the recorded autonomous for it to be effective. (table lookup?)

Identify which modes we need and create a SendableChooser to select between 
them.

Display images on SmartDashboard
size/refresh rate  320/24
toggling between cameras on robot

We're looking into buying a spare camera for the robot. We need to decide 
whether we want to buy another one of the model we have (M1011, line now 
discontinued and therefore a little more expensive) or buy the replacement, the 
M1013. Investigate the differences between the two and check on Chief Delphi to 
see if anyone has had success interfacing with the M1013. 

Characterize

We want to build up our own library (e.g., team100lib) similar to wpilibj, with 
our PID code and other useful functions.  We'd really like to organize this as 
a reusable library rather than copy the files into every robot project. We 
should figure out how to build a "library" project and reference its classes 
from another, robot project.

To start, take a look at the instructions for how to build wpilibj as a project:
http://wpilib.screenstepslive.com/s/3120/m/7885/l/79739

New frc plugins were posted 1/18/2013. Need to update all netbeans installs to 
go to the wpi site to get updates automatically. Instructions are in the 
installation section of the Getting Started With Java online manual.

Find out what the computer needs

model: Flightstick Pro USB

The drive team would like a button on the joystick(s) that will initiate a 
slow, precise turn in place (we'll probably use the gyro for this). The turn 
will stop as soon as the button is pressed again.

The LabVIEW dashboard (aka FRC Dashboard) has some neat functions that the 
SmartDashboard doesn't have, such as a checklist of things to do during 
competition, graphics displaying the position of a joystick in a Cartesian 
plane, and graphs of power levels to motors. Research more in depth what new 
functionality the LabVIEW dashboard has that the SmartDashboard doesn't and 
update the page on the software site accordingly 
(https://sites.google.com/site/team100wildhats/subteams/software/working-with-la
bview-dashboard). Then try to implement those functions in SmartDashboard. The 
attached file is a good starting point.

We'll need to do 3/4 things with the shooter subsystem:
* Run slowly backwards to accept frisbees during feeding
* Shoot frisbees into high or medium goal during teleop
* Shoot frisbees into high goal during autonomous
* Spit frisbees into pyramid goal during endgame

Roger mentioned that even though they are trying their hardest to lower the 
center of gravity the robot will still have rocking issues. If we can find a 
way to stabilize our driving in the code with out losing speed this would give 
as a small advantage.

Exactly what it sounds like. Need to test on climber prototype.

Evaluate use of the MaxBotix EZ-2 distance sensor (stored in our new blue 
sensor box) for use in conjunction with the shooter.

Timing frequency of teleop/autonomous

Map operator controls and have them perform commands.

The climber/shooter angle is controlled by a motor with a large gear ratio. We 
start with it pointed straight up and need to move it down to a precise angle 
(60% from floor).

It may be useful to display tilt in 2 different axes to the smartdashboard, as 
the "compass"-like widgets, so we can tell whether the robot is slipping while 
climbing.

We need to decide on the placement of the shooter and climbing cameras, and 
discuss with the mechanical team.

Current idea is to put both on top of the tower, one pointing out in the 
direction of the shooter, and the other pointing down towards the hooks.

Paul has developed some drivetrain code:
http://code.google.com/p/team-100-wildhats/source/browse/#hg%2FPaul%2FUniversalD
riveTrain

We should add the parts we need to Robot2013.

The frisbees will be fed through the shooter, so we'll need to run the shooter 
slowly backwards to accept the frisbees.  

The frisbees will be fed into the shooter using a belt with hooks at opposite 
sides of the belt. Those hooks will need to be out of the way while feeding, 
and can be used to pull up the whole stack of frisbees into the shooter. The 
recommendation is that we run the belt slowly enough to allow a gap for the 
shooter to spin back up to speed.  

We should be able to just run the belt in one direction.

Verify that the problems with the FPGA implementation of the high-speed 4x 
encoder have been corrected with the new 2013 cRIO image.

Verify that the system can support 4 encoders.
Verify that the system can support 8 counters.
Verify the speed reporting on the encoders and counters.
Determine the number of encoder counts per revolution.