Statistics on top 20 teams?

[taichichuan]

Hi Gang,

Does anyone have any statistics on say the top 20 teams in Atlanta? Things like:

Programming:
What language did they use?
Threaded code or just poll in the teleop loop?
Did they do something in autonomous? If so, what worked?
What problems did you encounter, if any, with WPILib?
Did you download the sources and rebuild WPILib/CanJaguarLib?
CAN or PWM control?
Did you use the Classmate for programming your robot or student/school supplied computers?

Robot Design:
What sensors were used?
Did you use the vision system?
If so, what modifications did you have to make to the code?
What drive system?
Wheels?
How many motors?
What material was used for the frame (Aluminum, steel, unobtanium)?
How did they control the ball?
Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?
How did you cut your parts (water jet, LASER, mill, hand tools,etc.)?
Did you hang?
If so, what wenching approach did you use?

The Driver Station
Did you reprogram your dashboard code?
Did you use external controls beyond your joysticks?
Any problems in getting the USB to behave?
Did you use any unusual controls like WiiMotes, XBox controllers, etc.?
Did you feel that the Classmate was fast enough?

Anything else?
Any techniques that you feel might be beneficial to others in the future?

I'm just looking to try to collect a "lessons learned" from this year's competition. I'll collate the results and post them back to CD.

TIA,

Mike

[Dancin103]

I do not, but sounds like an AWESOME project for someone. Can you tell I love statistics. If I was not in the middle of crunch time I would do it right now. lol

Cass

[apalrd]

If you want information on 33, I can give it to you:

Software:
LabVIEW
Threaded, Teleop only gets driver data and sets variables.
multi-zone kick ball, made avg. 2 of 3 far zone, could attempt 5. Routines selected from operator control console, feedback on Driver Station verifies selection
-feedback on speed and triggers on distance, runs at 1.2 ft/sec to avoid 2-second rule penalties over 3 feet
WPI problems: Compressor no well documented, and can be highly inefficient if not used correctly. Cypress IO gives you last old data if you loose the Cypress board.
LV rebuilds and redownloads WPI every time it downloads, so I guess yes. I did make modifications to the Compressor lib.
PWM (Victors)
My laptop (student-provided).

Design:
Potentiometers on arm axis, kicker, and chassis articulatioin, broken-beam on ball sensor, encoders and gyro in drivetrain. Arm software uses both chassis and axis sensor to control chassis ride height.
No vision (any vision attempts caused problems in PID timing and control lag)
We rewrote the part that the default code has in Teleop to get a new image after it achieved its gyro setpoint, as well as light up the red light when the target was aligned.
6wd articulated-center for drop but raised when going over the bump
4 AM Plaction, 2 AM Omni
4 CIM drive
Almost entirely aluminum, mostly sheet metal, backbone frame welded.
top-roller pincher
Spring kicker
Frame sheet metal was waterjetted, everything else was done by hand (bandsaw, drill press, lathe, mill)
We hung from the vertical pole. In ATL we hung every match except one, where we were knocked off the pole and almost were able to get back on.
800:1 CIM, CIM->DeWalt->Toughbox->Chain


DriverStation:
Custom tabbed dashboard with camera image, tabs for Disabled, Auton, and Teleop with important match data, Debug tabs for sensor, setpoint, output, and other data for the pits.
Logitech gamepad for driver, "kitty's kat box" for operator, using Cypress board.
No problems with USB gamepad, lots of problems with Cypress comm (rebooting DS usually fixed this, so we booted the Classmate two matches ahead of time and didn't shut it down ever)
Logitech gamepad, nothing more special
The classmate itself was fast enough for DS and Dashboard, but having to reboot to regain Cypress comm or log out to clear FMS lock was far too slow.


Future:
Radio reliability
Improved Cypress comm (NI has informed us they know of a fix but FIRST would not let them release it during this season)
Loss of Kitty's Kat Box was very difficult, as it sends old data on loss of Cypress comm. If it boots up without the Cypress board, it will send all 0's so you can pull an input high and detect loss when the input is low.
No Cypress drivers with Driver Station causes Virtual DS to not find Cypress board.

[Josh Drake]

What constitutes top 20? We were finalists for Newton, but qualified 15th in the division, so I wouldn't say we were top 20 in the nation.

I like the idea of gathering info, so if you care to know what we did, holler.

[slavik262]

I think a lot of the questions about the robot and control system are great, but some of the programming questions leave me confused as to what can be gained by their answers.

What language did they use?
As it's been said many times, the language used is really just a preference issue. You should really just go with whatever your team is most comfortable with. Some like the graphical environment of LabVIEW. Others like Java or C++. My team personally uses C++ because we have the most experience in it and like the flexibility, but again, the language you use should be whichever one your programmers will be most productive in.

Threaded code or just poll in the teleop loop?
In terms of performance, a single thread will run faster since the cRIO is a single-core processor and less threads cause less time to be spent on context switching. We had a huge bug with the watchdog tripping this year because our extra threads were hogging too much CPU time. That said, you can play around with task priority or cause your tasks to sleep when they're not needed to make up for it in performance (i.e. have a task that updates your PWM outputs sleep the length of the Victor/Jaguar update speed).

Did you use the Classmate for programming your robot or student/school supplied computers?

I'm confused how this has anything to do with how a team would perform. I guess I'm assuming this poll is to see what can be learned from the top 20 teams so that other teams can use this knowledge to become better themselves.

[Andrew Schreiber]

What constitutes top 20? We were finalists for Newton, but qualified 15th in the division, so I wouldn't say we were top 20 in the nation.

I like the idea of gathering info, so if you care to know what we did, holler.

Going by Win/Loss record:

1114
2481
2056
25
971
254
67
330
2119
1676
1086
3221
359
217
224
1807
3305
2992
148
987


These teams won more than 70% of their matches.

[rsisk]

I think the hardest part would be determining the top 20 teams in Atlanta :yikes:

Might be interesting to throw together a SurveyMonkey survey and then correlate the data from that with team ranking

Anecdotal evidence: while judging in Atlanta for machine attributes, I asked every team I interviewed what language they used, 95% said Labview, 5% said C++, and 0 said Java

[sircedric4]

The question is are you willing to get this data from any team that is still reading Chief Delphi now that crunch time has slowed down, because I could answer all these questions on our team.

I see your just looking for the top teams, whoever they are, but I know I'd be interested to see what worked and didn't work for those that fought tooth and nail to just compete. It might even bring to light some issues that held the non-top teams back and help us make things better for all involved?

Now that I said that, I am gonna answer these questions anyway. :-) But to keep this post from taking the whole board up, I am putting the answers in CODE tags.

Programming:

What language did they use?
C++

Threaded code or just poll in the teleop loop?
I am assuming what we did would be considered poll in the loop. I know we used the Iterative Robot example and treated the teleop section like one continously running do loop.

Did they do something in autonomous? If so, what worked?
We had 8 modes for autonomous depending on starting location and number of balls kicked. We used encoders to keep our robot traveling straight and to determine travel distance. The programmers couldn't get a PID loop going so our travel distance was based on an if-then statement. Next year we intend to do PID because it meant we didn't kick like we wanted one match because the power wasn't enough while we were tweaking the distances traveled. Overall we were successful, just had variable tweaking issues.

What problems did you encounter, if any, with WPILib?
Lack of functional examples and better detailing of what does what in the User's Guide. Better documentation is a must I feel. Sure there was the DOXYGEN file or whatever but plain straightforward text in the user manuals with copious examples would help tremendously for new and young learning teams.
Also better beta testing or something since we got burned several times throughout the update process and the installer cost us a week while we were trying to get our compressor code running because some setting wasn't correct in an example that survived from last year.
Overall, once we got the stuff setup right and got through the no robot code errors, the basic methods and classes seemed to function if you could figure out what they did and what variables they wanted.

Did you download the sources and rebuild WPILib/CanJaguarLib?
We did not rebuild or change anything from the WPILib or do anything with the Jaguars.
CAN or PWM control?
PWM
Did you use the Classmate for programming your robot or student/school supplied computers?
We used personal laptops for our programming and only used the Classmate as a golden goose driver station, never to be messed with. We were having so many troubles with just getting the Classmate to talk with Cypress chips and getting the updates to take the first time that when we had a functional driver station we would take no chances on messing it up.



Robot Design:

What sensors were used?
We started with just encoders and limit switches, but eliminated all but the encoders on the drive wheels. Our limit switches died during our regional and we couldn't get their logic to line up properly with our kick system so we put it on a time based algorithm. We have a design approach to limit the numbers of sensors to as few as possible because we have been burned in the past with them when they fail at the worst possible moment. We always have a back up plan to work if all our sensors die.

Did you use the vision system?
We tried to get it to work a little but between the time limitation of build season and the fact that we kept hearing on Chief Delphi that it was seriosly lagging the system, we decided the reward vs resources for the vision system wasn't worth it this year. We also had last year's vision experience as a bad taste in our mouth, where we spent significant resources to get it to work good and the lighting on the field totally torpedoed all that work. We'll use the camera only when we have to.

If so, what modifications did you have to make to the code? N/A

What drive system?
Because our design was looper based and our CG was going to be high, we stuck to a tank drive 4 wheel system, with the wheels as far apart as possible with a custom frame. Keeping the wheels as far apart as possible allowed our unusually tall robot (considering all the little tunnel bots) to cross the bumps.

Wheels?
Plaction wheels on the front for traction with Lunacy slick wheels on the back for maneuvaribility. Because we had a point designed possession mechanism we needed good front control.

How many motors?
4 on the drive train. 1 on the vacuum

What material was used for the frame (Aluminum, steel, unobtanium)?
Custom designed aluminum frame welded in our mentor's garage.

How did they control the ball?
1hp Shop Vac with a Fisher Price motor tied to a Home Depot yellow funnel. It worked great, but had limitation of exact ball placement required.

Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?
All pneumatic system. We used a pre-charged pneumatic cylinder that was fed from one of 3 pressure regulators to control kick power/ ball distance. We used another cylinder turning a small holder pin to hold the kick cylinder until commanded. We thought our little system was the ultimate power/versatility versus complexity system. It was simple to build and tweak and the only downside was making sure you had enough valves and the pneumatic system didn't leak. We ran the entire Championship with zero issues from our kick system.

How did you cut your parts (water jet, LASER, mill, hand tools,etc.)?
Our mentor has a mill, lathe, and various hand tools in his garage where we build our robot. All student cut.

Did you hang?
We had a design for hang but had to remove those parts for weight before ship day. No

If so, what wenching approach did you use?
Were going to use a Dewalt Transimission with the 5th CIM motor to climb.


The Driver Station

Did you reprogram your dashboard code?
Nope, used as is. No student interest in programming this year so mentor did minimum coding to make robot 100% functional. Nice to haves and play withs like Dashboard not even attempted.

Did you use external controls beyond your joysticks?
Cypress chip with toggle switches, push button switches and potentiometers.

Any problems in getting the USB to behave?
YES. Cypress chip would cut out at weird moments and sometimes wouldn't be recognized on boot up. Finally had a procedure that we shut down computer except when tinkering on robot in pit or right before matches. Only way to ensure functionality was to come up from complete shutoff right before matches.

Did you use any unusual controls like WiiMotes, XBox controllers, etc.?
No

Did you feel that the Classmate was fast enough?
Adequate, though growing pains with USB stuff and programming was painful.


Anything else?

Overall we had a positive experience and learned quite a bit from looking at the older, "powerhouse" teams while at Championships. Most of our lessons tended towards game strategy and best type of robot to build, best type of possessor to make, etc...
Overall only had one design lesson we learned this year since we've been keeping track of our past issues. Each year our team's robots gets more and more bullet proof and Champs caliber.
Would have liked to be in other division so had chance to get picked for Saturday afternoon. :-) With awesome 469 in division, other loopers were pretty much out of running.
Loved the game this year since it rewarded teamwork and building robots for different positions. Didn't like Coopertition as it stands, though with a little tweaking to make it so you qualify like you eliminate it could be good.


Any techniques that you feel might be beneficial to others in the future?

After looking at some of the other kick systems, I thought ours was more robust, versatile and elegant than most with no sensor requirements and maximum use of existing components. If you are going to have a pneumatic system at all you should maximize the use of it from a rewards vs resources factor.

Looking at ball possession, ball magnet pinch rollers look awesome and is something we'll put more study into.


I like this topic and am looking forward to how some of the other teams did their Breakway robots this year.

[taichichuan]

What constitutes top 20? We were finalists for Newton, but qualified 15th in the division, so I wouldn't say we were top 20 in the nation.

I like the idea of gathering info, so if you care to know what we did, holler.

If you made the finals, then I think that counts. I simply said 20 to get things going. So, I'd be glad to get your info and add it to the mix.

TIA,

Mike

[gvarndell]

In terms of performance, a single thread will run faster since the cRIO is a single-core processor and less threads cause less time to be spent on context switching.


This is a too simplistic view of the issue.
Yes, there is some weight associated context switching.
But if a single thread polls for some event for even 3 milliseconds, that wasted time is nowhere near recovered by avoiding context switches.

[slavik262]

This is a too simplistic view of the issue.
Yes, there is some weight associated context switching.
But if a single thread polls for some event for even 3 milliseconds, that wasted time is nowhere near recovered by avoiding context switches.

You didn't account for the rest of my post. :D As I said, depending on what you do with those threads affects performance. Obviously you'd want a separate thread if you're blocking for some input. Besides, that wasn't the overall point of my post.

[Chris is me]

I don't know if this is a Top 20 statistic or not, but there was not a single mecanum drive robot on Einstein this year. I won $10 when that happened. :)

I bet you'll find that almost all of them used roughtop or wedgetop tread in their robot, at least 4 CIMs (I don't think any of the 6 motor teams made the top 20), and they had good possession.

I also think though, that you need to figure out what is causation and what's simple correlation.

[gvarndell]

You didn't account for the rest of my post. :D As I said, depending on what you do with those threads affects performance. Obviously you'd want a separate thread if you're blocking for some input. Besides, that wasn't the overall point of my post.

Fair enough.
Just didn't want any misconceptions about multi-tasking clouding the thinking of the young 'uns.

[Tom Bottiglieri]

I don't know if this is a Top 20 statistic or not, but there was not a single mecanum drive robot on Einstein this year. I won $10 when that happened. :)

I bet you'll find that almost all of them used roughtop or wedgetop tread in their robot, at least 4 CIMs (I don't think any of the 6 motor teams made the top 20), and they had good possession.

I also think though, that you need to figure out what is causation and what's simple correlation.
Teams with mecanum drive were almost automatically put on our "Do Not Pick" list.

[JamesBrown]

I don't know if this is a Top 20 statistic or not, but there was not a single mecanum drive robot on Einstein this year. I won $10 when that happened. :)


I think it has been proven over and over again that a well designed 6/8 wheel drive train is as fast and maneuverable as mecanum. It surprises me every year that more and more teams seem to be going with mecanum designs. Mecanum wheels make for a cool demo bot (especially if you can translate and rotate simultaneously) but we are yet to see a game where they offer a real advantage (I do think they could have been a good option in this years vex game).

[Chris is me]

Fun Fact: Just looking back through 2005 (before that "no one" had mecanum), there has never, ever, ever been a mecanum drive robot on Einstein. I hope teams that consider mecanum in future years ask themselves why they think this is.

[Peter Matteson]

Fun Fact: Just looking back through 2005 (before that "no one" had mecanum), there has never, ever, ever been a mecanum drive robot on Einstein. I hope teams that consider mecanum in future years ask themselves why they think this is.

We said the same thing about wide bodies and Einstein in 2009 and 11 out of 12 robots were widebody that year.

Just because the game where mechanum makes sense hasn't happened yet doesn't mean there will never be one. It's a simple design trade that you can do when determining your team's strategy. Just because you can make something does't mean you should if you look at the big picture.

[Chris is me]

We said the same thing about wide bodies and Einstein in 2009 and 11 out of 12 robots were widebody that year.

Just because the game where mechanum makes sense hasn't happened yet doesn't mean there will never be one. It's a simple design trade that you can do when determining your team's strategy. Just because you can make something does't mean you should if you look at the big picture.

I didn't mean to imply "never will there be one" or "mecanum is always bad". I just think when teams make such a decision, they should ask themselves why this year will be different than previous years.

[thefro526]

Fun Fact: Just looking back through 2005 (before that "no one" had mecanum), there has never, ever, ever been a mecanum drive robot on Einstein. I hope teams that consider mecanum in future years ask themselves why they think this is.

Oh, and my favorite Fun-Fact: There has only been one 6WD Swerve Drive in the history of FIRST... And it went to Einstein.

Also, there have been a quite a few flop bots on Einstein as well: 71 in 2002, 67 in 2004, 67 in 2005, and 16 in 2008. Looks like they've been spaced out an average of 2 years each... Does that mean we're overdue for a Flop bot to go to Einstein? Hopefully they're legal in 2011.

[Chris is me]

Oh, and my favorite Fun-Fact: There has only been one 6WD Swerve Drive in the history of FIRST... And it went to Einstein.

Also, there have been a quite a few flop bots on Einstein as well: 71 in 2002, 67 in 2005, and 16 in 2008. Funny thing is that they've been spaced out 3 years each... Maybe we'll see a flop bot on Einstein in 2011?

You forgot 67 in 2004, which kind of wrecks your pattern a little.

[thefro526]

You forgot 67 in 2004, which kind of wrecks your pattern a little.

I edited my post to reflect this.

Hopefully the rules won't be overly restrictive and flop bots will be legal next year.

[Peter Matteson]

I didn't mean to imply "never will there be one" or "mecanum is always bad". I just think when teams make such a decision, they should ask themselves why this year will be different than previous years.

That was my point as well.

[Joe Ross]

We used LabVIEW. We did most of the work in telop this year, as we didn't have any control loops. Last year, we mostly used telop to set set-points and ran the control loops in periodic tasks (separate thread).

Our autonomous was structured into discrete VIs that had their own while loop in each one running from autonomous independent. We could then string these VIs together very much like lego programming. For example, we had a drive until ball detected, followed by a kick, followed by drive until ball detected in parallel with wait for 2 second kick retract. It was very easy to move those around as needed.

We had no problems with WPILib. We used Jaguars for most things with PWM control. Programming computers were team supplied.

The only sensor we used in competition was an analog current sensor on our ball herder to detect when a ball was captured. We played with the vision system and had it tracking at home, but didn't have a chance to integrate it into the rest of our code. We used the tracking part without modification, but changed the auto-aiming to fit the rest of the structure of our code.

We had 4 wheel, 4 CIM motor drive, with two pneumatic tires and 2 omni-wheels. Frame was aluminum tube, welded. Almost all fabrication was manual. Kicker was completely pneumatic using a pre-charged cylinder. We did hang, from the top bar There are no wenches on our team or robot (no winches either). We used a lead screw powered by a CIM to hang. We had a single powered roller on top, and an un-powered roller on the bottom that the ball spun against.

We did a custom LabVIEW dashboard, but we only used a little for debugging, and not really in a match. We only used the kit joysticks. After having problems with the provided hub during build season, we bought our own USB hub. We did not use the cypress.

Most of the problems that I helped other teams with were with loose wires, so make sure everything is tight, and that you periodically check your wires, especially in a high impact game like breakaway.

[Ether]

We had a huge bug with the watchdog tripping this year because our extra threads were hogging too much CPU time.

Would you please elaborate on this? What exactly was the bug?


you can play around with task priority or cause your tasks to sleep when they're not needed to make up for it in performance (i.e. have a task that updates your PWM outputs sleep the length of the Victor/Jaguar update speed).


Can you give a couple of examples of 2010 FRC breakaway functionality which would require (or even benefit from) changing task priority?

In the 2010 FRC LabVIEW framework, all user-created periodic tasks have the same priority, and they are preemptively time-slice multitasked by the O/S. Running these periodic tasks at a reasonable rate, as you suggested, frees up the CPU so that it should have enough throughput to service all the tasks you need, no?

~

[Tom Bottiglieri]

Programming

What language did they use?
C++

Threaded code or just poll in the teleop loop?
We just did everything sequentially in the TeleopPeriodic calls from WPILib.

Did they do something in autonomous? If so, what worked?
Our auto mode was set up so you could select a "main" and secondary function. Main functions included :
- Far Zone, Kick 3, With Bounce
- Far Zone, Kick 3, No Bounce
- Mid Zone, Kick 2, Straight on'
- Mid Zone, Kick 2, From Angle
- Near Zone, Wait and plow
- Do Nothing

Secondary Functions Included:
- Cross Bump and kick (5 ball mode)
- Cross Bump and wait
- Cross 2 bumps
- Block the tunnel
- Back up and drive to center of field (to steal opponents missed shots)
- Do Nothing

The secondary functions were smart enough to know what to do based on the first function... so 'Block the tunnel' worked from the far zone and the middle zone without having to explicitly tell it to. Everything worked. We kicked 5 balls in auto many times and made 3 from the far zone a few times.

What problems did you encounter, if any, with WPILib?
None. It seemed solid.

Did you download the sources and rebuild WPILib/CanJaguarLib?
No.

CAN or PWM control?
PWM. We only used IFI Victor speed controllers.

Did you use the Classmate for programming your robot or student/school supplied computers?
We did not use the classmate for development.


Robot Design

What sensors were used?
- Encoder on drive for distance measurement/control
- Yaw gyro for angular control and "drive straight" correction
- Pitch gyro for controlling the autonomous bump traversal
- Encoder on kicker to control winch for multi-distance kicks
- Encoder on ball grabber to sense when we had control of a ball
- Multiple limit switches on hanging arm used for controlling deployment and automatically starting/stopping the hanging

Did you use the vision system?
No.

What drive system?
8 wheel drive. 4" cantilevered wheels. 2 speed (w/ neutral) + power take off drive gearbox

How many motors?
4 CIM to drive. These were also used to hang and self right (which was never used)
1 CIM for kicker winch
1 FP + clutch for ball grabber

What material was used for the frame (Aluminum, steel, unobtanium)?

6061 Alum

How did they control the ball?
Pincher roller with high torque clutch on top roller.

Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?
Trampoline springs. Winch driven by CIM with ratchet and pawl. Dog gear + piston release.

How did you cut your parts (water jet, LASER, mill, hand tools,etc.)?
Most plates initially cut on water jet, finished on CNC mill. CNC mill used for most everything else.

Did you hang? If so, what wenching approach did you use?
Vertical bar. Used power take off from drive for lift with ratchet+pawl to keep suspension.


The Driver Station

Did you reprogram your dashboard code?
Yes. We just added a bunch of indicators to push out sensor values for quick debugging. We used the legacy driver station console lines to print out info about and select our auto mode.

Did you use external controls beyond your joysticks?
We used analog joysticks for the driver and 100% custom controls for the operator. Everything ran through the cypress board.

Any problems in getting the USB to behave?
Sometimes the cypress board would not be recognized by the DS software and we would have to restart the computer or restart the CyProgMini (or whatever) windows service to get it to work.

Also, after a restart the cypress board would lose its configuration data. If we did not start the robot AFTER the driver station was up and running, the correct I/O configuration (which was set from the robot) would not get pushed to the board, and everything would default to a floating input. This one was particularly tricky to figure out.

Did you use any unusual controls like WiiMotes, XBox controllers, etc.?
No.

Did you feel that the Classmate was fast enough?
Not at all. Boot up times were terrible. We wasted so much time waiting for things to boot and sync.

[apalrd]

Our autonomous was structured into discrete VIs that had their own while loop in each one running from autonomous independent. We could then string these VIs together very much like lego programming. For example, we had a drive until ball detected, followed by a kick, followed by drive until ball detected in parallel with wait for 2 second kick retract. It was very easy to move those around as needed.

I wrote a system almost identical to this, motivated by how easily the LEGO kids I mentor can write code. I had VI's to do control on speed for distance, kick, set kick recoil distance, and a few others that I rarely used. The distance control did P control on Speed (in feet/seconds).

We have a policy of integrating sensors into our design. We try to automate the more direct robot control functions to allow the driver and operator to focus on driving, which generally means the fewest button presses necessary to perform a task. We generally don't do much based on time, but some functions have (e.g. a double-action claw in 2007 would trigger the upper claw 10ms after the lower one, and the roller on this robot would kill the roller after 5 iterations after collection and reset after 20 iterations).

[JABot67]

I guess I could post for my team, though I really don't know all the details. I'll answer what I can. Most of my answers will be quick.

Programming:

What language did they use?
LabVIEW at Kettering and MSC, C++ at Wayne State and the Championship.
That's right, we had two completely different, functional codes from different programming environments. We decided to try something different this year with such a huge programming team.

Threaded code or just poll in the teleop loop?
I have no idea what this means, though I wrote basically all of the LabVIEW code. Sorry...

Did they do something in autonomous? If so, what worked?
We had many autonomous modes. We have scored from all three zones, and have started out in all three zones in eliminations. It really helped out to have so many autonomous modes. There were major differences between the autonomous modes in C++ and in LabVIEW, but they were meant to do the same thing.

What problems did you encounter, if any, with WPILib?
No problems.

Did you download the sources and rebuild WPILib/CanJaguarLib?
No.

CAN or PWM control?
PWM control.

Did you use the Classmate for programming your robot or student/school supplied computers?
We used our own computers. Using the classmate would have been just terrible.

Robot Design:

NOTE: I was not involved with the robot build. I am a programmer, and definitely not an expert. I'll try to answer these questions based on what I know, which was gathered from working in the pits or with the practice robot.

What sensors were used?
Encoders on the left and right drive, and potentiometers on the kicker and the arm. One yaw rate gyro that was especially useful in auton. No limit switches. We had a camera that we never used.

Did you use the vision system?
No.

If so, what modifications did you have to make to the code?
N/A

What drive system? Wheels?
8 wheel tank, front and back four wheels were smaller and raised.

How many motors?
4 CIM Drive
2 FP motors for the kicker and arm
2 Window - one for the roller and the other for the shifter, to kick and to shift into arm mode.

What material was used for the frame (Aluminum, steel, unobtanium)?
Water-jetted sheet aluminum. Don't know the specs.

How did they control the ball?
Pincher, with a static bottom bar and a top roller attached to a belt that slips when a ball is being possessed, but still applies torque to the ball.

Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?
Tempered garage door spring.

How did you cut your parts (water jet, LASER, mill, hand tools,etc.)?
Our frame is waterjetted.

Did you hang?
Yes.

If so, what wenching approach did you use?
We used four 200 pound gas struts, and a block and tackle. We wound up the mechanism before every match and used the stored energy to elevate the robot.

The Driver Station

Did you reprogram your dashboard code?
Yes. However, we never ended up using the new dashboard.

Did you use external controls beyond your joysticks?
No.

Any problems in getting the USB to behave?
Yes. Eventually we decided to plug our controllers directly into the Classmate, as there were enough USB ports to do so.

Did you use any unusual controls like WiiMotes, XBox controllers, etc.?
Well we have used only Logitech gamepads for the last couple years. No fancy controllers. We don't even use joysticks anymore.

Did you feel that the Classmate was fast enough?
We hated the Classmate. The one FIRST gave us decided to crash during two matches at Wayne State, disabling us for the rest of those matches. And the bootup time was way too slow.

Anything else?
We had a lot of problems this year. There were a whole lot of issues we had to face in order to come out on top. But those problem solving steps were part of what makes FIRST Robotics so fun.

Any techniques that you feel might be beneficial to others in the future?
Well we scouted a lot. Our scouting team is huge and that definitely impacted how we did at our competitions.

I'm sorry that my answers were so short, but hopefully this gives some insight into Team 67.

[Dhananjay T.]

I have most of these questions answered from team 25.

Programming:
What language did they use?
We used C/C++, with the provided WindRiver Licenses
Did they do something in autonomous? If so, what worked?
We attempted to have enough versatility to score from all zones. We had an onboard switch and up to 7 auto modes programmed to do so.
What problems did you encounter, if any, with WPILib?
We had a couple of problems while working with encoders. We got some code errors referring to the directory in WPILib. We ended up giving up on encoders, and working with other sensors.

You'll see our big problems recorded here:
http://www.chiefdelphi.com/forums/search.php?searchid=2951632
Did you download the sources and rebuild WPILib/CanJaguarLib?
We only had the updated version of WPILib to work with. Any new version we could get, we immediately refreshed our libraries with it.
CAN or PWM control?
PWMs. We did not use Jaguars at all this year, and only worked with PWMs and Victors.
Did you use the Classmate for programming your robot or student/school supplied computers?
We used a combination of an old school laptop, and a generously donated laptop to work with our programming. We found that the older one just wouldn't let us connect a drivers station, a CRio, and a laptop simultaneously.


Robot Design:
What sensors were used?
We used two different kinds of sensors. One photogate sensor was placed in the front of our robot to sense a ball.
A limit switch was attached to a gear driven bolt for our kicker, to sense if it was winded up or not (our kicker was winded by two window motors to store energy from surgical tubing).
And a last limit switch for our hanger which we added later on in the season, to sense if our pull up was at its limit.
Did you use the vision system?
No, we felt it would be too tedious a job after the trouble we went through last year, especially with the lack of the classic bright green light :D
What drive system?
Tank Drive. 6 wheels. The middle ones are not lowered, but we find turning is a breeze anyway.
Wheels?
We use skyway wheels that we tread ourselves at school. This year we had to replace a couple because we ended up shredding the rubber after two regionals :rolleyes:
How many motors?
4 CIMs for the drives
2 Window motors to wind up the kicker
1 worm-gear driven CIM motor for our hanger
2 Fisher-Price motors for our fans
2 servo pin brakes
How did they control the ball?
We used two RC Propeller blades in an air duct to pull air through the robot. We found we could suck in a ball anywhere 10 - 12 inch radius of the opening in the front. It helped with catching them in the corners.
Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?
Elastic. Surgical Tubing.
How did you cut your parts (water jet, LASER, mill, hand tools,etc.)?
Some parts we cut with hand tools, drills, bandsaws etc. Mostly with stuff you find in any high school wood shop. Nothing fancy.
Did you hang?
Yes, we hung from the side bar.
If so, what wenching approach did you use?
Side bar. We had to hook onto the side bar, and pull ourselves up.


The Driver Station
Did you reprogram your dashboard code?
nope
Did you use external controls beyond your joysticks?
Nope, this year we used three of the Logitech joysticks.
Any problems in getting the USB to behave?
Except for the provided stop button annoying us in Atlanta, no problems
Did you use any unusual controls like WiiMotes, XBox controllers, etc.?
no, we deprive our drivers of that luxury ;)
Did you feel that the Classmate was fast enough?
We found the reset times excruciatingly long during build season, but learned to adapt.

Anything techniques?
When we cut out parts for our robot, we find it easiest to print out actual size CADs of the parts, and stick them on to our material. This way our measurements are exact, as they are from full sized CADs. Gives us nice lines to follow when cutting, and saves us measuring time. I'm not sure if other teams do it as well, but it's great for us.

"Lessons learned"
We thought this year's design, and build process went fairly well, though haunted with some programming bumps in the road.

I hope this helps, please let me know if you have any questions or if I was unclear about anything.

[Alex Dinsmoor]

Well we were a division finalist, so I thought you may want our info :)

Programming:

What language did they use?
LabVIEW

Threaded code or just poll in the teleop loop?
I do believe it was a teleop loop. I'm not 100% sure though.

Did they do something in autonomous? If so, what worked?
In Autonomous we shot balls from all 3 zones; we had an autonomous for each zone, and a "sit" autonomous. The modes would tension the kicker, activate the magnet, and kick based on the amount of balls that were in the zone.

We found it beneficial to pre-tension the kicker to save time.

CAN or PWM control?
PWM

Did you use the Classmate for programming your robot or student/school supplied computers?
We use a combination of team and personal laptops. The team laptop contains the master code, while the student laptops contain the code in which they are working on.

Robot Design:

What sensors were used?
Encoders on the drive system (was not used), limit switches for the kicker and arm release, and a pot for the tensioner.

Did you use the vision system?
No.

What drive system? Wheels?
4 Wheel tank drive. 2 Pneumatic wheels in front, 2 omnis in back.

How many motors?
2 CIMs for drive system
1 CIM for winch
2 Window motors for kicker system
2 Fisher Price for magnet and arm release

What material was used for the frame (Aluminum, steel, unobtanium)?
C channel steel.

How did they control the ball?
Single roller on top.

Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?
Variable tension surgical tubing kicker

How did you cut your parts (water jet, LASER, mill, hand tools,etc.)?
Hand tools, mill, lathe.

Did you hang?
Yes.

If so, what wenching approach did you use?
Used a compressed air strut to raise arm, winch and pulley to raise robot, arm falls (http://www.youtube.com/watch?v=tvNcx8Fxtsk) once winch is engaged.

The Driver Station

Did you reprogram your dashboard code?
No.

Did you use external controls beyond your joysticks?
No.

Any problems in getting the USB to behave?
No.

Did you use any unusual controls like WiiMotes, XBox controllers, etc.?
3 Logitech Joysticks.

Did you feel that the Classmate was fast enough?
The drivers had mixed feelings about it. We did however purchase one with a larger screen (as compared to the KOP one), which may have had a faster processor and battery. The camera functionality was useful when we had one.

Anything else?
We found that designing and prototyping should always be your first steps. Also that it doesn't take professionally made parts to make a good robot.

Strategy is also your greatest aide in competition.

Any techniques that you feel might be beneficial to others in the future?
Plan, learn, improve, scout, strategize, and have fun!

[TEE]

If so, what wenching approach did you use?
Used a compressed air strut to raise arm, winch and pulley to raise robot, arm falls (http://www.youtube.com/watch?v=tvNcx8Fxtsk) once winch is engaged.



You know Alex, it would be really cool if you could get that video right-side up =]

[kstl99]

Fun Fact: Just looking back through 2005 (before that "no one" had mecanum), there has never, ever, ever been a mecanum drive robot on Einstein. I hope teams that consider mecanum in future years ask themselves why they think this is.

I am a mentor on Oz-Ram, 1922. At our first meetings after kickoff we decided our priorities would be speed, agility, and a good kicker. We used mecanum wheels and a wide orientation. We ended up being quick and very maneuverable. We were very good at getting to balls and clearing them into the front zone when we were in the middle or rear and could score well also. We could easily go over the bumps with a little momentum and go through the tunnel sideways. We were #1 seed at BAE, won in Boston and made the semi-finals in the Newton division. Sorry if I am bragging but my point is that with our strategy the mecanums were very much an asset.

[CoachPoore]

We were 5th seed on Archimedes...

Programming:
What language did they use?
C++

Threaded code or just poll in the teleop loop?
We divided the code into a number of different robot subsystems, each of which was called from {Autonomous,Teleop}Periodic. As much code as possible was shared between teleop and autonomous.

Did they do something in autonomous? If so, what worked?
We implemented an autonomous virtual machine which gave us the ability to quickly code many different autonomous modes for all 3 zones, and add more as the season progressed. We had around 20 programs ranging from "kick 5 balls" to "kick 3 and head for the center of the far zone" to "kick 2 balls then block the tunnel". Of the 20 we regularly ran about 5. I don't think we ever started in the near zone in any of our matches so far so there are several programs we never tried at a competition. We also had the ability to program a whole number of seconds delay before the autonomous program ran, which proved to be useful on a couple of occasions to make sure we were not in the way of our alliance partners. We used the 5 ball autonomous a lot at GSR and in NC. In Atlanta with a very capable field of robots we did not need it, but were still crossing the bump in autonomous when necessary for match strategy.

What problems did you encounter, if any, with WPILib?
None

Did you download the sources and rebuild WPILib/CanJaguarLib?
Downloaded the source for reference, did not rebuild WPILib. Did rebuild the CAN code so that it did not mind what firmware version number came back from the Jaguars as all of our Jags were returning the same (very) wrong number. Kept up to date with new releases.

CAN or PWM control?
CAN. No problems once we upgraded to the v89 firmware. We had 7 Jaguars on the CANbus.

Did you use the Classmate for programming your robot or student/school supplied computers?
We did not use the Classmate for programming.

Robot Design:
What sensors were used?
Encoders, limit switches, current sensing via the Jaguars, gyro.
Did you use the vision system?
We wrote aiming code but decided that ball pickup was harder than aiming the robot so we used the camera solely for video feedback to the drivers.
If so, what modifications did you have to make to the code?
What drive system?
4 CIMs, AndyMark 2 speed transmissions, pneumatic shift.
Wheels?
9" pneumatic at the front, dual omnis at the back.
How many motors?
9 motors
What material was used for the frame (Aluminum, steel, unobtanium)?
Alumimum
How did they control the ball?
"Active shepherding" units to guide the ball into a suction cup.
Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?
Compression springs.
How did you cut your parts (water jet, LASER, mill, hand tools,etc.)?
Some parts were made on a mill and lathe. Most of the robot was made using hand and power tools.
Did you hang?
No
If so, what wenching approach did you use?

The Driver Station
Did you reprogram your dashboard code?
Yes
Did you use external controls beyond your joysticks?
No
Any problems in getting the USB to behave?
Not once we replaced the KoP hub
Did you use any unusual controls like WiiMotes, XBox controllers, etc.?
Gamepad for kicker control
Did you feel that the Classmate was fast enough?
Yes, once we replaced the default dashboard code :)

Anything else?
Any techniques that you feel might be beneficial to others in the future?

[TEE]

Oh, and my favorite Fun-Fact: There has only been one 6WD Swerve Drive in the history of FIRST... And it went to Einstein.



Which team and which year?

[NickE]

Which team and which year?1625 2010

[TEE]

Oh rly? How'd I miss that o_o ?

[RobertG]

Programming:

Language: C++
Threaded code or just poll in the teleop loop: We had most of our code in a loop with the exception of the PID controllers
Did they do something in autonomous?: We had nine autonomous modes. Our autonomous code essentially would kick everything in its path until it reached a certain distance. We also could drive over the bump and wait a few seconds for the air tanks to pressurize. At the championship we usually kicked three from the far zone and went over the bump.
What problems did you encounter, if any, with WPILib?: We encountered a few problems with the vision code.
Did you download the sources and rebuild WPILib/CanJaguarLib?: We made a few modifications to WPILib.
CAN or PWM control?: CAN. This allowed us to sense the increase in current from the pincher motor when we had the ball.
Did you use the Classmate for programming your robot or student/school supplied computers?: Team supplied computers.


Robot Design:

What sensors were used?: Encoders on the kicker gearbox and drivetrain, VEX Limit Switches to calibrate the kicker gearbox encoder, and current sensors in the CAN Jaguars
Did you use the vision system?: Yes. We mounted the camera below the bumpers so our drivers and coach could see the balls.
What drive system?: 6 wheel tank
Wheels?: 7 inch tractrion
How many motors?: 4 cims for the drive train, 1 cim for the pincher, 2 Fisher Prices for the kicker
What material was used for the frame (Aluminum, steel, unobtanium)?: Aluminum
How did they control the ball?: A pincher with rubber splicing tape
Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?: Rubber sheeting
Did you hang?: No


The Driver Station

Did you reprogram your dashboard code?: We used a custom dashboard for a fast (30fps) video feed. I believe we found it on Chief Delphi.
Did you use external controls beyond your joysticks?: No
Any problems in getting the USB to behave?: No, except once during the finals on Newton when it refused to recognize the stop button.
Did you use any unusual controls like WiiMotes, XBox controllers, etc.?: No, although we did use a heads up display to signal ball possesion and whether our kicker was ready to fire.
Did you feel that the Classmate was fast enough?: I did not notice any delays during robot operation.


Any techniques that you feel might be beneficial to others in the future?: Secure the CAN bus cables. During one match a stray wire or hose depressed a tap allowing the cable to come out. Also, during the Newton finals we had watchdog errors most likely because a CAN bus cable (still secured by its tab) had come out slightly.

I'm just looking to try to collect a "lessons learned" from this year's competition. I'll collate the results and post them back to CD.
I am not sure what lessons we could learn from just this data. I suggest collecting data from as many teams as possible so you can attempt to control for variables or at least have results to compare the top 20 teams with.

[taichichuan]

Well, I'm looking for trends. What do many of these teams have in common? Essentially, if there are common characteristics for these top teams, then this is something that others might like to know to improve for future competitions.

For instance, I was not aware of the whole mechanum wheel thing. Seeing that only 1-2 teams have ever made it to the finals with mechanum wheels should give a robot design team some cause for pause. It's not that a superior design won't prevail, but perhaps starting out with mechanum may not be a good idea when facing a challenge like Breakaway.

We've been getting some great responses so far. I'm on the road at the moment. So, when I get back home, I'll start collating the data and get some preliminary information back to the group. Thanks and keep the data coming!

Mike

[sgreco]

Here are the drivetrain trends. I see a trend for skid steers. I left blank information that I either didn't know or couldn't find.

2010
67 – 8 WD long
177 – 8 WD long (articulated is sets of two, front and back)
294 - 6WD long

2009
67 - 6WD wide
111 - 4 wheel crab (non-coaxial), wide
971 - 6WD wide

2008
1114 - 6WD long
217 - 6WD long
148 - three-wheeled crab (coaxial), nonagon-shaped robot

2007
177 - 6WD long
987 - 6WD long
190 - 6WD long

2006
217 - 6WD long
522 - Treads, long
296 - 2WD long, Omnis in front

2005
67 - three-wheeled crab (non-coaxial). Flop bot.
330 - 6WD long
503 – 4WD long, omniwheels in rear


2004
71 - 4WD long
494 - 4WD long
435 - 2WD long, with casters in front

2003
111 - Four-wheeled non-coaxial crab (with dropdown skid for turning)
469 – 4WD Long
65 - 4WD Wide

2002
71 - 4WD flop bot with casters in front
173 - 4WD long
66 – 4WD long

2001
71 - ?
294 - ?
125 - ?
365 - ?
279 - ?

2000
255 - ?
232 - ?
25 - ?

1999
176 - 4WD long w/ Omnis in front
1 - tank treads, long
48 – 4WD, long

1998
45 – 4WD long with Omnis in front.

1997
71 - ?

1996
73 - ?

1995
100 - ?

1994
144 - ?

1993
148 - ?

1992
126 - ?

(I just compiled the information from this thread http://www.chiefdelphi.com/forums/showthread.php?t=77412)

[akeisic]

2001
71 - ?
294 - 4WD-long. And still functioning today! :-D
125 - ?
365 - ?
279 - ?

[akeisic]

Programming:
What language did they use?
C++

Did they do something in autonomous? If so, what worked?
1: Start far, kick 3 (no bounce)
2: Start far, kick 3 (with bounce)
3: Start far, kick 3 (no bounce), go over bump
4: Start far, kick 3 (with bounce), go over bump
5: Start mid, kick 2
6: Start mid, kick 2, back up, turn toward center
7: Start near, kick 1
8: Start near, plow into net
9: Start near, kick 1, back up, pause 5 sec, move forward, kick anything in path

In all modes we used current sensing to detect the ball and set the maximum distance. This was enormously helpful as we could easily adjust the starting position of the robot and distance from the ball without having to worry. We used mode 1 and 3 the most.

CAN or PWM control?
CAN. We had some trouble with the tan jaguars losing their identity, but fixed those with a patch. It definitely cleans up wiring, but you MUST ensure the wires are secure. If you lose 1, you lose them all! This is why we didn't move in the 2nd match of Newton finals. We're talking about using PWM for drive and CAN for auxiliary for next year.

Did you use the Classmate for programming your robot or student/school supplied computers?
The team recently purchased a dedicated programming laptop.

Robot Design:
What sensors were used?
Jaguar current sensing for the intake roller, encoders on left and right drive train, encoder for kicker winch system, 2 limit switches for kicker zero and kicker max.

Did you use the vision system?
Yes! - but not the way you would think. We mounted our camera below our bumper so we could see behind those pesky bumps. It was especially helpful in the far end of the field. It also helped us see directly below the drivers station.

What drive system?
6WD with a 0.100" lowered center wheel. The center wheel was driven directly and the front/back by a single loop of chain.

Wheels?
7" traction wheels - Thank you Northrop Grumman!

How many motors?
Drive: 4 CIMs
Intake: 1 CIM
Kicker winch: 2 FP
Pneumatics: 2 for 2 speed transmission, 1 for ratchet release

What material was used for the frame (Aluminum, steel, unobtanium)?
Welded aluminum. Mostly 1/16" wall, but 1/8" where we needed it.

How did they control the ball?
Pincher design with friction clutch and center back stop. We pulled balls away from many teams - including 1114 and 1902.

Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?
flat elastic pulled back by winch and released by ratchet.

How did you cut your parts (water jet, LASER, mill, hand tools,etc.)?
Hand, band saw, mill, lathe, water jet, CNC mill

Did you hang?
No.

The Driver Station
Did you reprogram your dashboard code?
Not to my knowledge.

Did you use external controls beyond your joysticks?
We had a heads up LED display, but no external controls

Anything else?
Any techniques that you feel might be beneficial to others in the future?
Ensure you have a battery load tester. While we tested our batteries in the lab (plotting the full drain of the battery), having a battery load tester in the pits is crucial. We disposed of 3 batteries after the championship because they were beyond their life! We couldn't climb over the bump during the finals in LA because of bad batteries.

[jspatz1]

1986: Curie #3 seed and finalist

Programming:
What language did they use?
Labview
Threaded code or just poll in the teleop loop?
huh?
Did they do something in autonomous? If so, what worked?
We could score all balls in any single zone from any position. Same basic program for each zone, just changed aim angle (robot orientation), kick strength, and number of kicks for each position. Our swerve drive allowed us to advance to each ball and maintain proper aim angle. Good success rate. We scored 3 several times.
What problems did you encounter, if any, with WPILib?
None
CAN or PWM control?
PWM
Did you use the Classmate for programming your robot or student/school supplied computers?
Other computers
Robot Design:
What sensors were used?
Potentiometer on kicker pivot to measure drawback
Magnetic encoder (KOP) on swerve steering to give absolute wheel orientation
Horizontal gyro to measure robot orientation
Verticle gyro to measure tilt on bumps and provide input to bump auto-pilot
Magnetic switch on kicker cylinder to sense extend position
Microswitches on ball magnet roller to signal ball possession
Did you use the vision system?
Tried to for autonomous. Gave up on it...too slow. We had momentary vision aiming that the driver could use on demand.
If so, what modifications did you have to make to the code?
I don't know that.
What drive system?
4 wheel crab/swerve, CIM motors within the modules. Wide format.
Wheels?
6" AM Plactions.
How many motors?
4 CIMS - drive, 1 CIM - steering, 1 FP w/ modified gearbox - ball magnet roller
What material was used for the frame (Aluminum, steel, unobtanium)?
3" aluminum C-channel, .875 dia x .055 wall aluminum tubing
How did they control the ball?
Foam pool noodle ball magnet roller, spin the ball against the carpet. Worked well.
Energy storage for kicker (elastic, pneumatic, motor driven, etc.)?
Pneumatic retract with elastic kick. We could release the kicker at any point of drawback which provided infinitely variable kick strength. This proved to be very advantagous.
How did you cut your parts (water jet, LASER, mill, hand tools,etc.)?
Water jet, mill, bandsaw
Did you hang?
No. We chose to keep scoring goals.

The Driver Station
Did you reprogram your dashboard code?
Yes
Did you use external controls beyond your joysticks?
Yes, we duplicated several pushbottun functions that were also on the joystick so either driver could do them. Kicker strength throttle pot. was external from the joystick.
Any problems in getting the USB to behave?
Yes, often. I/O board and sometimes joystick would loose connection.
Did you use any unusual controls like WiiMotes, XBox controllers, etc.?
No. Joystick, pushbuttons, potentiometer. We did have an audible buzzer that signaled ball possession.
Did you feel that the Classmate was fast enough?
No.
Anything else?
Any techniques that you feel might be beneficial to others in the future?
Facing our goals at all times with a crab drive was a big advantage for us.

[taichichuan]

Hi Gang!

Preface

OK, thanks to all those folks who responded. I started this thread to see if there were any common characteristics of the teams that experienced a modicum of success in this year's competition. By asking a series of questions (next year I'll try SurveyMonkey instead), I tried to gather some info to determine what might give a team some guidance as to what technologies they should try to come up to speed on. Obviously, there was no control group or attempt to be a rigorous scientific survey. The sample size was way too small for that to be sure. This is because many teams just stop paying attention after the build season comes to a close.

In this effort, I was just trying to get a feel for where folks found success that we all could learn from.

Results

I've collated the responses and here they are:

The language in use was pretty evenly split between C/C++ and Labview with 58% using C/C++. None of the respondents used Java.

Only a couple of teams knew what threads were. The Labview code uses threads internally. But, only 20% of the respondents were using threaded techniques consciously. Given the move to multi-core processors in the embedded industry, knowing what a thread is and how to use it is pretty important. As mentors, we should probably do something about this knowledge gap...

All of the respondents operated in autonomous mode and the majority scored in this mode. Many had multiple "plays" that they could run from different field positions. The majority used closed loop encoders to determine position from a known starting point.

Most of the respondents had little or no trouble with WPILib functionality. However, a couple of teams did rebuild the library and fix minor nits. Nonetheless, many commented on the poor documentation and lack of examples of the WPILib services.

66% of the teams used PWM for motor controls. Of those that used CAN, the biggest concern was losing a CAN cable lost the entire CAN bus from that point forward in the chain. However, the current sensor capability on the CAN-enabled Jaguars was used by several teams for ball detection.

No one used the ClassMate for development. In general, the comments indicated that the ClassMate had issues with lengthy reboot times, USB connectivity problems and an inability to keep up with the data that was being thrown at it. Most development was done on personal laptops or school-provided PCs.

As for sensors, the general trends were for the use of closed-loop control of robot position and speed. Wheel encoders were used by most teams (70%). Only 25% of the respondents used gyros. None reported use of accelerometers. There were limit switches used for the hang feature and broken-beam sensors for detecting the ball. No, IR or SONAR ranging was used.

The respondents were split evenly on the use of the vision subsystem. Of the half that used it, it was not used for continuous video. In fact, it was only used sporadically to confirm target was aligned or to see balls when the robot was out of direct sight of the driver. The half that did not use the vision system sited it as being slow and having too many bugs for reliable use. 1 respondent did try to fix some of the issues.

The favored drive systems seemed to be split between 6WD (33%) and 4WD (33%). There were a couple of 8WD and 1 crab/swerve drive robot.

Remarkably, many teams mixed wheel types on their robot. Plaction and Omni were used in conjunction with each other and with pneumatic. Only one respondent used mechanum. One used slick and one use skyway wheels.

66% of the teams used 4 CIM motors to drive the robot. Window motors and FP motors were used for kickers, vacuums, and the roller/pincher assemblies. One team actually had *9* motors on their bot.

The most common frame material was definitely aluminum with only 8% saying that they used a steel frame. Likely due to its scarcity, unobtanium was not used by any team ;) . Issues of welding aluminum meant that teams using aluminum had to have access to experienced aluminum fab facilities or aluminum welders.

66% of the respondents had access to sophisticated water jet or CNC milling equipment to cut their parts. The rest used a hand mill/lathe or hand tools. All of the teams used small hand tools such as band saws etc for smaller parts.

75% of respondents used some sort of ball roller or pincher to control the ball. 25% used a vacuum of some sort with one using a ducted-fan assembly from RC airplanes. I didn't think about that possibility....

50% used elastic tubing or sheets for their kicker. 30% used springs of some sort and the rest used a pneumatic kicking assembly.

50% of the respondents said that their robot hung during competition. Of those, 33% used worm gear or screw drive and the rest used a winch of some sort.

60% reworked the dashboard code in some way. One completely replaced it commenting on the lack of speed of the default code as an issue. Another rewrote the code to be able to collect performance data for pit analysis.

60% did not use any external controls beyond the joystick. Of those that did use external controls, problems with Windows drivers, hot plug issues and Cypress board going off line problems were commonly reported. Joysticks and Logitech gamepads were the most common control in use. What? No VI gloves? A couple of teams added additional instrumentation to their robots in the form of bright LEDs to inform the drivers that the target was aligned, kicker was in position or a ball was in possession.

As for the ClassMate, then general feeling comments were:
1) It took too long to boot. This made it difficult to prepare for the match, or recover in the case that the Cypress unit failed or the FMS failed.
2) The Windows O/S crashed during matches.
3) The USB drivers for the Cypress board were unreliable. Plugging and unplugging wouldn't fix connectivity issues with the Cypress. So much for plug and play.
4) The KOP USB hub was buggy and many teams replaced it.

Thoughts

Naturally, some of these results may be simple correlation and not have a direct cause/effect relationship. Still it was interesting to look at.

If I had to try to draw any conclusions, I'd say that teams should spend some time coming to grips with closed-loop control systems (e.g., for motor control) and aluminum metal working techniques. Many, but not all, of the respondents had access to sophisticated metal cutting techniques. But, hand tools were the rule of the day in the final assembly. This means that we, as mentors, really need to take the time to show the students how best to use these tools safely and effectively.

As to whether you should spend your time learning C++ or Labview, 60% were using C/C++ and the rest were Labview. None of the respondents were using Java. Considering all of the noise made by the WPI folks over the introduction of a Java version of the WPILib, I'm somewhat surprised. But, maybe it's too early to make that judgment at this point. I'll leave you to draw your own conclusions on the language.

The ClassMate was pretty much reviled. It was too slow, required *forever* to boot and suffered from significant USB driver issues. Maybe it was a Windows thing trying to get too much code on a slow processor. But, the netbook market is pretty vibrant and lots of folks are using them. So, I,m not sure if the speed of the ClassMate, the amount of memory, the O/S, or the FLASH storage was the problem. But, clearly, there's a problem.

The other clear output of this exercise is that FIRST teams are very resourceful and imaginative. I saw some very sophisticated drive mechanisms at the competitions -- many of which actually worked ;). Whether you go for the complex or the simple, there's just nothing like seeing your team's robot go rolling across the field under your control. And, the teamwork that has to happen to deal with the unexpected is nothing short of inspiring.

Thanks and good luck in the future,

Mike

[Chris is me]

Interesting results.

For what it's worth, though 2791 isn't a top 20 team, we programmed in Java this year and had no code bugs throughout competition. We even had a consistent (albeit extremely simple) autonomous. I think the Top 20 teams just have mentors and student teams already trained in the old languages.

Do consider though how much of that is simple correlation rather than causation. Some stuff (like sensor-driven autonomous modes being more successful) would probably be correct though.

[taichichuan]

Good point on causality vs correlation. I added a comment to the post to that effect.

As for Java, I suspect that few wanted to be the guinea pigs on Java in the first year out. I know a few teams who did try it successfully. I'll add your team to that list.

In the embedded programming space, many of us look at Java as a great way to generate a GUI, but not as something targeting real-time controls due to memory issues, garbage collection delays, inability to access physical devices directly (e.g., no pointers) etc. That being said, the real-time Java folks have been able to get millisecond accuracy for a significant number of applications. That's likely more than fast enough for anything we're doing with FIRST.

Thanks,

Mike

[Jamie Kalb]

For what it's worth, though 2791 isn't a top 20 team, we programmed in Java this year and had no code bugs throughout competition. We even had a consistent (albeit extremely simple) autonomous.

Same story here on 3129. We had a rookie programmer who had taken a short class in Java before the season, and wanted to continue working with it. He picked it up fast.

[rogerlsmith]

Back when this thread was started, I wasn't sure if you guys would consider 3357 a "top 20" team. We were picked by the #1 alliance of Teams 254 and 233 on Archimedes. With the help of these awesome teams, we won our division.

At any rate, I thought I'd share our statistics.

Programming:

We programmed in Java
Our code was fully threaded
Our autonomous blindly drove and kicked, however we had camera code that aimed. Didn't use it.
No problems that I know of with WPILib
We did download the WPILib source, didn't compile it.
PWM control
Did not use the classmate for development.


Robot Design:

We used the gyro and camera
The vision system was set up to be used both in auton & teleop. We never used it in either case.
In the vision system code we tweaked the PID values. It seemed to work best with the defaults.
Drive system was direct drive, tank control.
4 Wheels, front 2 AM Plaction, rear 2 slippery plastic from KOP.
4 CIM motors, 1 direct drive on each wheel.
Material was standard KOP C-channel
Ball control via pinch roller made from pool noodle.
Energy storage for kicker - pneumatically charged elastic.
We cut parts with hand tools, and some were machined via CNC mill
We did not hang.



The Driver Station

We used the standard dashboard and a modified version (not programmed by us)
We used an X-Box controller for drive, joystick for all kicking and pneumatics operations.
USB seemed to work okay.


I did not feel the classmate was fast enough, and may have caused several communication problems on field.

[Pat Fairbank]

I'm not qualified to answer any of the detailed questions on their behalf, but I can share that 1114 used Java this year, and their programmers told me they were happy with it and would use it again.