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.

Originally Posted by taichichuan

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.

Originally Posted by taichichuan

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).

Originally Posted by taichichuan

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]

Originally Posted by DRAKE343

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

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]

Originally Posted by DRAKE343

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]

Originally Posted by slavik262

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]

Originally Posted by gvarndell

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. 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]

Originally Posted by slavik262

You didn't account for the rest of my post. 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]

Originally Posted by 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.

Teams with mecanum drive were almost automatically put on our "Do Not Pick" list.

[JamesBrown]

Originally Posted by 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 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).