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