Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Check lists and debuging lists needed-1 by ajizai


									Check lists and debuging lists needed

Team 3784 realized when we went to CowTown that there were a lot of little things that
impared our performance. We're making check lists for everything from packing and tools
needed to debugging and troubleshooting.

Where could we find samples of other teams' lists?

Ashley Painter
Team Captain
FRC Team 3784
2011 Highest Seeded Rookie
2011 Gracious Professionalism
2011 Kansas City Champions
Re: Check lists and debuging lists needed


Originally Posted by Ashley Painter
2011 Highest Seeded Rookie
2011 Gracious Professionalism
2011 Kansas City Champions
Nice set of street creds there

I'll comment on the pit list, we look at all the things that have wear and tear and build a
check list based on that. We then look at the "oh, so that's why the robot didn't move last
match" and put them on the list. The list is posted in the pits so it's a constant reminder
what to do.

The list is in order of time. For example if the wheels need treads, that takes lots of time, so
it's early in the list. Last on the list is things that may be a problem but quick to check. For
example, did the programming team load new code? Then is the ethernet cable to the Wifi
plugged back into the CRio?

Last thing on the list is a check of the list. Read the list out loud and wait for a crew
member to yell "Done". We've had times where that didn't happen and there were failures
in the match.

Learn the list, work the list, love the list.
Foster Chief Roboteer-Teams 80 - 15 middle school teams and Team 81 - 3 high school
teams VRC

     2011 - VEX World Championships - Excellence (80), Think (81) and Teamwork
     2011 - 15 VEX teams fielded with 9 teams World's Eligible and 7 teams attending the VEX World Championships
     2011 - FRC 1640 - Rockwell Control Award @ Fingerlakes, Champion @ Philadelphia
     2010 - Mentor of the Year - VEX Clean Sweep World Championship
        2011 - 8 VEX teams fielded with 2 teams attending the VEX World Championships
        2010 - FRC 1640 - Xerox Creativity Award @ Philadelphia Regional
        2009 - FRC 1640 - Rockwell Automation's Innovation in Control Award @ Chesapeake Regional - Champion @
          PARC XII

Downingtown Area Robotics Web site - come see what we can do for you.

Re: Check lists and debuging lists needed

It is also important for the drive team to have a check list for queing and on the field. This
can include things such as, checking the ethernet to the crio, checking that the correct
autonomous mode is set, checking the minibot is on, checking the pressure gauge is closed,
Phillipians 4:8 - Finally, brethren, whatever is true, whatever is honorable, whatever is
right, whatever is pure, whatever is lovely, whatever is of good repute, if there is any
excellence and if anything worthy of praise, dwell on these things.

God created FIRST as one of many wonderful things to dwell upon (just don't get obsessed
... whoops too late)  .

Re: Check lists and debuging lists needed

Always debug moving from mechanics to code.

For example, if you have a limping drivetrain, you check the wheels, then the chain, then
the gearbox, then the motors, then the encoders, then the victors, then the power
distribution board, then the digital sidecar, then the cRIO, and lastly the code.
You can't fix something that isn't broken...

but you can always break things that aren't fixed!

 bookworm0422                                                                               Join Date: Jan 2011
                                                                                            Rookie Year: 2003
 bookworm0422                                                                               Location: Wayne, MI
 AKA: Karl Heinrich                                                                         Posts: 8
     FRC #0313 (Bionic Union)
 Team Role: Mechanical

 Robot Inspection Checklist Prior to Matches

 Ok I've been tasked with making a Robot Saftey Checklist for use by our team prior to
 every match we have to ensure everything is in order and functioning properly, would any
 one have any ideas of what to include or maybe have a template that their team uses that
 i could have and make into my own. Please and Thank you.
Re: Robot Inspection Checklist Prior to Matches

Replace and secure battery
Check that purge valve is closed if applicable
Verify bumper color matches alliance color
Possible quick power up to make sure everything is getting power and pressurize pneumatic
Our team also places our robot on blocks and quickly tests every function, such as drive
train, arm, and minibot deployment. We also try to remember to charge our pneumatics
with a used battery instead of the one that will go on the field just so we can save some

Oh, and make sure you have the right code and the right autonomous.
It may seem silly but - continually check for loose screws! - with the battery disconnected of

Our team makes (and iterates) custom pit & drive team lists every season, starting with
what we notice is temperamental during build & pre-ship practice. It's saved us a lot of
"do'h!" moments and definitely helps keep maintenance under control. Here's this year's.
Yes, the majority of a list like this will be robot specific. On 2175 it is known as the "Stupid"
List because you feel real stupid when you lose a match because you didn't check
something on it.
We always try to have a checklist but this year it has actually been used every match
because we put it on the back side of a piece of lexan on the robot and check it off with a
dry-erase prior to each match. This allows us to have it on the field where stuff like turn it
on and remove safety pin comes into play.
Our team has a checklist as well. We print off several copies then check off every item on
it before each of our matches. Always make sure that everything is plugged in right on the
electrical board. Sometimes one thing out of line here can make the entire robot stop
working. We usually test our drive train before each match too, just to be sure that if all
else fails our bot still has defensive capability.
Our team has learned the hard way at the Week Zero and thursday at GSR, make sure
every pnuematic end is closed.
Re: Robot Inspection Checklist Prior to Matches

In addition to always just checking for loose screws and such, we've found it helpful to
actually list specifics on our sheet- figure out which things are more likely to ever come
loose, so we make sure they always get extra special attention!

We always check wires and connections, too, as well as clearances- if say a zip tie broke off
and now a wire is hanging in the path where your rotating arm travels... just things like
that. But checking for clearances could apply to a number of things anyway.

Then, Bumpers! Just to make sure we have the right color for the next match! And then this
also helps us to keep track of matches when we check to see our next alliance, the times
are right next to it if matches are still on schedule.

Most of the rest of our checklist is specific to our robot, but like some others have said,
just restoring whatever needs to be restored, making sure hostbot and minibot batteries are
fully charged (part of this check is to actually use a multimeter for us at least), and even
making sure your driver station is ready to go, would all probably be beneficial.

Good luck!
As I recall, our checklist, which is robot-specific, went something like this:

-   Bumpers correct color
-   Bumpers right side up
-   Elevator cables correctly seated in pulleys
-   Radio plugged in
-   Battery plugged in and strapped down
-   Robot on
-   Minibot on robot
-   Minibot battery connected
-   Minibot switches in correct position
-   Electronics Hatch secured
-   Minibot Deployment Arm retraction hard stop locked in place
-   Minibot Deployment Arm cotter pin secured.
-   Beak closed on ubertube in correct orientation
-   Robot properly aimed for auton (check at least twice)

Before every match I make sure that I have zip ties and a 7/16ths wrench and ratchet in
my pocket in case I see any issues. I also check the driver’s station to make sure that the
controller and joystick are read by it
For the Robot:
-Make sure PWM's are connected and haven't fallen out. It is quite tough to drive if you
don't have all of your wheels connected.

-Check battery voltage.

-Make sure crimps stay crimped and wires have not fallen out of the crimp.


-Make sure your Arm is in starting configuration if it ended the last match out of starting

-Make sure your Radio is plugged in the right port.

-If your sponsor logos are detachable, make sure they are on the robot.

For Driving:
-Make sure the joysticks are plugged in.

-Make sure your classmate is charged and able to be turned on. If the classmate is not
charged, be prepared to plug it in immediately in the driver station.

-Make sure your drivers are present.

Thats all I have from my experience.
Re: Robot Inspection Checklist Prior to Matches
We dind't have a checklist this year, and I wish we had.
I would include:

New, legal battery in and secured. (Minibot and robot)
Any stored energy springs set
No broken parts (We had a piece of steel wire connecting a servo to our deployment latch
which nobody checked. Our minibot didn't deploy, and we lost the match
Bumpers are secured and of the right colors
Parts are within the starting configuration
Bolts are tightened
Chains/belts are tensioned

Almost all of those had been problems for us either in our testing or in the competition.
Having a checklist probably would have put us in position to pick alliances at our regional,
due to an unsecured minibot battery hanging off the back while it was climbing.
Re: Robot Inspection Checklist Prior to Matches

Shure. This is what our team used for two regionals this year:

1. Check Bumper Color
2. Change the Robot's battery
3. Is everything plugged in? (it listed specific line items)
4. Turn Robot on, with the tether
5. Retract the arm to starting configuration (specific instructions followed)
6. Make shure the robot moves
7. Robot off
8. Fresh minibot battery
9. Fresh robot battery
10. Check loose screws (listed specific locations)

We've done checklists for two years now. We've found it helps alot, when we actually use
them. Probably the best example to use is the emergency checklists for airplanes. All small
airplanes have an about 20 page series of checklists for normal operations. This is all well
and nice, but 20 pages is too long, seeing as we don't have all the time in the world. Look at
the language of the plane's emergency checklists. We try to emulate that.

Example checklist:

(granted, it's not in the real format, but it'll give you a good idea)

mabye this'll help for you too?
Re: Robot Inspection Checklist Prior to Matches

Come hell or high water, we WILL have a checklist next year! A improperly seated (and
easily checked) connection to a minibot motor cost us a spotin the Dallas Regional finals.
And of course this happens in the same game where our teammate gets their arm beat up
in the autonomous period and their minibot is turned off by the uber-tube falling on it -
Team 599 has a particularity exhaustive set of checklists. They broke it up in several
checklists based on subsystem and when the check is being performed. Each checklist had
a place for two people to write their names and check.

Post Match Electronics Checklist:
Check Battery Voltage / New battery
6 awg wires are secure to DB board
All fuses are present on Distribution board
Wire connections to distribution board are secure
Power wire to cRIO are secure
Power cable to camera is plugged in on both ends
Power to digital sidecar (both) is plugged in on both ends
pneumatics module is in slot 8 of cRIO
Analog module in slot 1 of cRIO
Digital Sidecar 4 in slot 4 of cRIO
Digital Sidecar 6 in slot 6 of cRIO
shifter solenoid in pneumatics mod. 2
claw solenoid in pneumatics mod. 4
minibot solenoid in pneumatics mod. 5&6
PWMs in digitical sidecar 4 are secure and in straight
PWM in victor is secure and all in all the way
Power to victor is secure and plugged in to DB
Victor connection to lift motor is secure and plugged in
PWM in relay is secure
Power to relay is plugged in and secure
relay connections to compressor are plugged in and secure
PWM in jaguars are secure and plugged in
Jaguar connections to motors are secure

Post Match Drive Checklist
Screws on the wheel shafts are tight
shafts are sitting properly in the wheels and chassis
Feathers and other components are secured on the chain
Chains are present and tension is AWESOME!
chain path is clear
bolts holding transmissions are tight
Gearbox plates are sitting properly and bolted tightly
Bolts are tight on bearing blocks
Bearings are sitting flush against bearing blocks
Wheel treads in good condition
Wheels are secure and are linked to drive chain

Post Match Chassis Checklist
Bumper color (red/blue) correct for next match
Front bumper securely mounted
rear bumper securely mounted
Left bumper securely mounted
Right bumper securely mounted
Bumper brackets tight
Battery mount screws tight
Pins looped through bumper
fresh battery
Lift Checklist
Lift motor temperature is normal
Drum and encoder shafts are unbent and undamaged
Top outer-rail bearing mounts aligned
U-channel is unstressed
Bearing mounts are undamaged
Rope is undamaged
Bearings have freedom of movement (where possible)
Springs are at correct position
Bolts and nuts are tight for top bearing mounts
Bolts and nuts are tight for top bracing
Bolts and nuts are tight for lift bracing
Bolts and nuts are tight for top inner rail
Bolts and nuts are tight for bottom of lift
Bolts and nuts are tight for encoder and line sensor mounts
Bolts and nuts are tight for drum and motor mounts

Post Match Claw/Arm Checklist
Put the finger safety on
All the bolts on the metal bar are tightened
Lexan pieces do not have cracks
The pool noodle has no tears
Pistons do not have cracks
There are 4 zip-ties on each lexan piece holding the pool noodles
PWM cables are connected to the piston solenoid on the arm, and there are no tears in
PWM cables are connected to the piston solenoid on the carriage and there are no tears in
Make sure that all the bolts on the carriage are tight
The axles that hold the pistons in place have an e-ring on each side
The pneumatic tubing on the claw is completely plugged into the pistons, solenoids, and
Bolts connecting arm to backstop are tight
Bolts on the rider are tight
Bolts Connecting bearing to rider are tight
E-clips on shafts on rider are tight
E-clips connection rider to pivot point on arm are tight
Shafts are in good condition.

Post Match minibot/Deployment checklist
All mounting screws holding deployment are tight
Make sure deployment is tilted (check vertical blue lines)
Stop is tight on both sides
Stop stops the deployment slide and bearings one centimeter away (adjust bearings if
'Liftoff' poles are tight
Screw holding the surgical tubing is tight

Post Match Pneumatics Checklist
All tubes are secure
all solenoid wires are plugged in
solenoid screws are tight
Tanks are secure, nice and tight
Pistons are connected to their tubing
Pressure release valve is closed
Rejoice, hi-5, then kumba-ya

Pre Match Driver Station Checklist
Driver Station is on
Driver station is in "Driver" user id
Stop button is disabled
PSoC chip is recognized by Driver Station
Drive joystick is plugged in and recognized
Lift joystick is plugged in and recognized
Score button is active (press to check)
Pickup button is active (press to check)
Minibot switch is active (flip to check)
Also, check all electrical connections, breakers, fuses, etc. Be sure to include the fans on
victors, the 5 volt regulated output (if used for a camera) and the 12 volt regulated output
on the power distribution board, and the breaker in the spike that controls the compressor
(the other spikes should have fuses which are a bit more secure since they don't stick out.
Also, check to see if any chains have come off their sprockets and for any other type of
If your robot is jumpy, has watchdog timeouts, loses connection to the field, etc.

I just wanted to pass on a discovery we made about a problem with our robot, in case it
helps some other team that is in the same boat, either this year (in off-season
tournaments) or in a future year.

Twice this season (fortunately, not during a tournament match), our robot has suddenly
developed a vexing problem where the driving is jumpy, the robot starts and stops, and
there are watchdog timeouts (visible in the error display on the driver station). Very weird
in both cases, because just minutes before, the robot was working great, with no change in
software or wiring.

In both cases, we eventually discovered that the problem was an intermittent power
connection on the robot. The first time, we found that one of the wires going to the robot's
main breaker was getting loose, and making an intermittent connection. We fixed that, and
the problem completely disappeared. We got lucky, and noticed a small spark at the main
breaker that clued us in to the problem.

The second time, we discovered that the lug nut holding one of the wires to the battery had
gotten loose, and the battery was making an intermittent connection. Swapping batteries
fixed the problem. We tried the previous battery again, jiggled the battery wires, and found
the problem. We then checked all of our batteries, and found multiple batteries with loose
connections (yikes!).

Last year, there were several tournament matches where our robot lost connection with the
field during the match for 30 seconds or so, especially when another robot collided with ours
during the match. Field personnel told us, from their diagnostic screens, that our cRIO was
rebooting itself during those 30-second blackouts. We had all kinds of theories about what
might be happening -- perhaps we had a component that was not electrically isolated from
the robot frame (especially the camera and the cRIO -- see <R36> in the 2011 rules), or
perhaps the Ethernet connector to the robot radio was not a solid connection, or maybe the
cRIO itself needed better shock mounting. We never did figure out that problem last year,
but based on our experience this year, I'll bet you dollars to donuts we had some kind of
loose electrical connection providing power to the cRIO and the rest of the robot.

So, if you find your robot is jumpy, starts and stops, has watchdog timeouts, or is losing
connection with the field, I would strongly encourage you to check your robot's main
electrical connections. In fact, these are excellent checks to make periodically in any case:

1. Check the connection of the wires to the battery, on all of your batteries. Make sure they
are nice and tight.

2. Check the connection of the wires to the main breaker on the robot.

3. Check both ends of the wires from the power distribution panel that provide 24V power to
the cRIO itself. Make sure the wires are firmly inserted into their connectors on both ends.

I hope this helps someone. These types of symptoms can be maddening, and the above
checks are easy to make.
Re: If your robot is jumpy, has watchdog timeouts, loses connection to the field, etc

A simple fix for your battery connections is something I have suggested here on CD over
the years. It is something WildStang has used for years. When you are assembling the
terminal to the battery post, add an external tooth star washer between the two mating
surfaces. This, in addition to the locking hardware supplied, prevents the terminals from
rotating with vibration or mishandling. Once the two terminal faces are locked in this way,
the supplied hardware cannot loosen. The star washer also serves to cut through any
surface corrosion or dirt on either the cable terminal or the battery terminal.
The loose hardware on the main breaker or PD is another common problem. It is an issue
on the main breaker as the high resistance causes heat and that heat is conducted into the
main breaker. This added heat derates the trip point of the main breaker and may cause the
breaker to open during a match.

Originally Posted by Randy Forgaard
Twice this season...our robot has suddenly developed a vexing problem where the driving is
jumpy, the robot starts and stops, and there are watchdog timeouts (visible in the error
display on the driver station)....In both cases, we eventually discovered that the problem
was an intermittent power connection on the robot. The first time, we found that one of the
wires going to the robot's main breaker was getting loose, and making an intermittent
connection....The second time, we discovered that the lug nut holding one of the wires to
the battery had gotten loose, and the battery was making an intermittent connection.
After fixing the above problems, and our robot behaving well for a while, our robot has
twice more developed these same jumpy, start-and-stop symptoms, for other reasons. I
wanted to share these as well, in case this info is useful to another team:


In our robot lab, we discovered we apparently have a lot of wireless communications
interference in the 2.4GHz band that the Classmate PC on our driver station (and our
programming laptop PC) uses to communicate with the radio on the robot.
We had two symptoms of this. The "Communications" indicator on the driver station kept
flashing from green to red to green, and driver station commands to the robot were
delayed, sometimes by a couple of seconds, which led to weird and dangerous jumpy robot
behavior while trying to control it from the driver station.

In addition, our programming PC, which also uses wireless communications to transfer
updated software to the cRIO, was weirdly slow when transferring code to the cRIO.

Using a long Ethernet cable to tether the robot radio to a wired Ethernet hub for both the
driver station and programming PC completely fixed both of these problems, which clued us
in that there was something wrong with the wireless communications. And the fact that
both the Classmate and our programming PC had trouble communicating wirelessly with the
robot either implied that the wireless capability on the robot radio was somehow defective,
or that the 2.4GHz communications band had a lot of interference in our robot lab.

The FRC 2011 robot radio uses 802.11n wireless, operating either at 2.4GHz or 5GHz. On
Page 7 of "How to Configure Your Radio," it recommends setting your robot radio to 2.4GHz,
because the Classmate PC only has built-in wireless capability at 2.4GHz. However, in the
footnote on that page, it goes on to say: "If a team's home facility has a significant amount
of 2.4GHz wireless traffic/interference, the team may want to select 5GHz." We decided to
follow this advice, and try using 5GHz in our robot lab.

To do this, we had to add 5GHz wireless capability to the Classmate PC we use for our
driver station. (If your team uses an alternate laptop that already has 5GHz wireless
capability, you can skip this step.) We bought and installed the Cisco-Linksys AE1000 High-
Performance Wireless-N Adapter (about $50), which we attached to a spare port on the USB
hub that we use with our Classmate PC. This is a high-end option; there are less-expensive
USB/Wireless-N options out there (including the one below). You need to make sure you
choose one that offers 5.0GHz, and that has Windows 7 drivers (since Windows 7 is the
standard OS for the driver station this year).

It turns out that our programming laptop also only has 2.4GHz wireless, not 5GHz. So we
tried out the less-expensive Cisco-Linksys WUSB600N Dual-Band Wireless-N USB Network
Adapter (about $40) for our programming laptop.

Both of the above USB/Wireless-N adapters offer 5.0GHz and Windows 7 drivers (as well as
drivers for Windows Vista and Windows XP).

We followed the radio configuration instructions in "How to Configure Your Radio" to set the
robot's radio to use 5GHz rather than 2.4GHz.

So now, the robot, driver station, and programming PC are all communicating at 5GHz, and
our wireless communication problems with the robot have vanished. The robot no longer
stutter-stops or has delayed reactions, and the "Communications" indicator on the driver
station is a solid green all the time. The programming laptop is now able to transfer new
software to the cRIO quite fast, the same speed as when we have a tethered connection. I
think we must have wireless interference at 2.4GHz in our robot lab, so this 5GHz
workaround has fixed the problem.

NOTE: At an FRC event (or, at this time of year, an off-season event), you of course don't
need these USB/Wireless-N adapters for your driver station or your programming laptop.
The event organizers will of course provide you with a station where you encrypt your robot
radio and put it into bridge mode so that you are using the wireless capability on the field.
And in the pits, as you know, teams are only allowed to use tethered wired communications
to the robot radio anyway. The above 5GHz workarounds would just be for use in your robot
lab at home.


We checked and fixed all of the robot power connections mentioned in my original post on
this thread (main breakers, battery, and power to the cRIO). Although those checks and
fixes cleared up our problems earlier this season, we were again (as of a few days ago)
getting jumpy behavior from the robot, even though we double-checked all the latter

On careful investigation, we discovered that, over the course of the season, the screw had
loosened on a power lead going into one of our Jaguars. As a result, it was making
intermittent contact, which made that motor (and our whole robot) jumpy. We then checked
and tightened the screw terminals on all of our Jaguars, and checked all of our other robot's
power connections as well.

Tightening that Jaguar screw terminal (and the other Jaguar screw terminals) completely
fixed the jumpyness of the robot.

So, I just wanted to add the above two items (checking and tightening ALL power
connections on the robot including the Jaguars, and trying 5GHz network communications if
your wireless connection from the driver station to the robot is iffy) as additional possible
checklist items to look for if your robot is jumpy and unreliable. Hope this helps someone!
Re: If your robot is jumpy, has watchdog timeouts, loses connection to the field, etc

We had a similar issue with interference in the 2.4 GHz band from our schools local wireless

I connected a bridge to a computer to do a scan of all local networks to find that our robot
network and the schools network were both attempting to use the same channel, in this
case 10. I just set the bridge to a different channel that was not listed. That corrected the
interference issue.

I was very surprised that we had 12 local systems. The lesson learned was to know what is
in your air!


To top