|
Re: Statistics on top 20 teams?
Quote:
|
Re: Statistics on top 20 teams?
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? |
Re: Statistics on top 20 teams?
Quote:
|
Re: Statistics on top 20 teams?
Quote:
|
Re: Statistics on top 20 teams?
Oh rly? How'd I miss that o_o ?
|
Re: Statistics on top 20 teams?
Programming:
Robot Design:
The Driver Station
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. Quote:
|
Re: Statistics on top 20 teams?
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 |
Re: Statistics on top 20 teams?
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/sh...ad.php?t=77412) |
Re: Statistics on top 20 teams?
2001
71 - ? 294 - 4WD-long. And still functioning today! :-D 125 - ? 365 - ? 279 - ? |
Re: Statistics on top 20 teams?
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. |
Re: Statistics on top 20 teams?
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. |
Summary: Top Team statistics!
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 |
Re: Statistics on top 20 teams?
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. |
Re: Statistics on top 20 teams?
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 |
Re: Statistics on top 20 teams?
Quote:
|
| All times are GMT -5. The time now is 04:16. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi