Archive for December, 2010

20
Dec
10

The FRC 2011 season kickoff is near!! January 8th will begin “Robot Season”. In case anyone doesn’t know, January 8th is when FIRST will unveil the 2011 Robot Competition Game. As most of us know, this is a worldwide event.

For the rookie teams who haven’t experienced the fun and exhaustion of an FRC season, this may be just an announcement of the game and time to get the kit of parts. For those of us veterans of the FRC robot games, it’s the kickoff of Robot Season. Six weeks to design, prototype, build, test, fix, and re-test your robot. The engineers at Lockheed Martin could not get this done, but thousands of high school students do this every year.

My goal is to help the rookie teams to have a fun and successful season. I would also like to see all teams move in autonomous mode, even if they don’t really do anything. Last year I talked with some rookie teams who weren’t sure what needed to be done for the 6 week robot build. They took a long time to plan, a short time to build, and a lot of last minute building/fixes at the event. I’d like to layout a simple time line to follow to allow for a successful season.

I also would like for people to e-mail (frc704mentor@qweztech.com) me during the season if they have questions, need some help, or are stuck. However, one of the best resources for teams is some of the more experienced teams. Most veteran teams are more than willing to help rookie teams. Go to the events list on www.usfirst.org, find the event you’re entered in, and go to see what teams are registered. Find teams with lower team numbers (possibly those under 2000, they’ve been around longest) and see which ones are in your area. Contact them and talk to them, see what they’re doing, if they’ll let you. I know Team 704 in the DFW (Texas) metroplex is willing to let people come out and see our Robot room.

Here’s my suggested time line.
Prior to season start – Learn about sensor’s, learn to program, learn about the mechanical aspects of robots. Build a create that can handle the maximum robot from the earlier seasons. If you don’t use all the weight or size, you can ship extra stuff like tools.

Jan 8th – Go to the kickoff and if they have a quick build session (where you put the robot together with the help of experienced people), go to that.
Jan 9th (Sunday) Each person should think about the game, the scoring aspects, the field elements, and the possible strategies.

Week 1, day 1: BRAINSTORM! Talk about scoring, the field, and possible strategies with the entire team, the mentors. Make sure everyone understands the each aspect.

Week 1, rest of the week: Design the robot. Figure out what you want the robot to look like, what apparatus’ should be on the robot (i.e. kicker, blocker, etc) You shouldn’t decide HOW everything should work, but WHAT should be on the robot. Also think about sensor’s that might help get the job done. Like light sensor for following lines or touch sensor to decide when you touch something.

Week 2: Prototype. For whatever apparatus that will be on the robot, figure out how they’re going to work. You may need pneumatics or electronics, or mechanical actions. Also the programmers should be putting together the program structure. What buttons are going to control what and adding code to deal with sensors and actuators. Also, start putting together the robot, the structure, electronics, pieces that are static. The drive train should be one thing that is being put together.

Week 3 and 4: Keep prototyping and continue building and continue programming. As you are figuring out how the apparatus work, they should be built. Also the programming should be coming along to control them.

Week 5: hopefully, by now, you should have something at least partially put together. So now, Test!! Even if it’s not 100%, test it, see what’s working and what’s not working. Put it under some stress and see what breaks. Imagine what might happen in the game and test it under those conditions or possibly even tougher conditions.

Week 6: fine tune. Do some more testing but the goal of fine tuning. Of course, anything that breaks, fix it and make it stronger. However, you should be fine tuning the connection between the programming, the electronics, and the mechanics. Also, you should take pictures and measurements of your robot.

End of week 6: Either bag and tag or create up and ship your robot. Hold back your cRio and electronics if possible. You can keep programming and trying little things.
This is only a suggested time line. Every robot is different, every team is different, and every game is different.

Remember, your design will change over the 6 weeks, your ideas will change over the 6 weeks, your strategy will change over the 6 weeks so be flexible. Stay focused on the game and the robot for 6 weeks; then relax until the event. And over all, have fun.

07
Dec
10

FRC LabVIEW – Trimmed Down

Some people complain that the LabVIEW is slow and teams should go to C++ for better performance. I say it’s not slow; it’s just all that’s put into the default code that eats up a lot of time. There are several things that can be done to improve the response of the robot using LabVIEW.

First, make sure all the loops have waits in them. If a loop doesn’t have a wait in it, the loop will run as fast as it can and take of most of the processing time.

Second, strip out everything from the code that’s not being used, including vision. Below is a stripped down Robot main.vi and teleop.vi. All the vision, gyro, other loops have been removed. A 10 millisecond wait was put in the main loop because there’s nothing to slow this loop. If other loops are added to do other things, then this wait needs to be in there. By the way, quick human reaction time is 100 milliseconds, so the 10 milliseconds is quick enough.

Robot main.vi stripped down with nothing going back to the Dashboard

Teleop.vi stripped down for Joystick control only

Ok, the robot code is stripped down; all that’s present is the Joystick to motor control and the watchdog. No information back to the dashboard only the camera image back through the FPGA.

The Robot code is only half of the issue. The dashboard code is the other half, there is stuff, mainly video, that is going on in the classmate dashboard computer. Below is the dashboard code, stripped down. I have to admit I haven’t tried using this version of the code. We have to move our Robot room and everything is in mild chaos. So give this a try.

Stripped down dashboard code

Trimmed down code is one way to get better response out of the robot.