Archive for the 'Uncategorized' Category

08
Jan
12

Sample Schedule for FIRST 3 weeks

Hey every one, due to work, I’ve been out of pocket for a while…But it’s Robot Season and time to really get down to the most fun work you’ll ever have.

Scroll to the bottom for Woodie Flowers presentatono from the kickoff.

To all the Rookie teams: One problem I’ve seen in the past is, teams that have never been through this get over whelmed easily. Between the robot build, reading the manual, and organizing the team with kids who have never been through this before either, time gets away from people. Teams will put off building the robot until the last minute. This is a huge problem because a robot is not built in a week. Here is a sample schedule for when things need to get done.

Please try not to stress out too much and remember there are people out there who can help. Look at FIRST event at the teams that will be at the event you will be attending and contact one of the veteran teams. They’ll usually help. Or contact your regional director, or contact me and I’ll see what I can do to help. I’m Joe Varnell, Engineer at Lockheed Martin, Technical mentor for Team 704, and my e-mail is frc704mentor@qweztech.com. I don’t want the rookie teams to get stuck. Also, don’t wait until the last week of the build to get help. Ask as early as you can.

Organize your team. There needs to be programmers, electrical people, frame/gear/build people (i.e. gear heads). Unless you have a large team, everyone will probably be doing a little of each. Plus, some kids may want to try it all so they can see what they are most interested in. There should also be a student team leader who knows what’s going on in the various parts. FIRST has information on organizing teams at this link (http://www.usfirst.org/roboticsprograms/frc/mentor-resources-library).

Week 1 – Figure out “What” needs to be done (Requirements) and “How” your robot will drive

Read the manual!!! This is probably the hardest part because there is a lot of other stuff to do and people, especially kids, want to get on with the robot building.

Analyze the game and the rules for the Robot. Figure out your drive train.

Brainstorm on what how you’re going to do things. Remember when brainstorming, no idea is a bad idea. Some ideas that seem to be “out there” may start other people thinking about different ways of doing things. Once you have a bunch of ideas, start narrowing them down to idea’s that can be implemented by you. You can also refine some of the ideas that have already been brought up.

Have the programmers start testing the sensor’s, learning the language, and running the example programs.

Find someone who can help with building using whatever materials are going to be used on the robot. Some teams will use aluminum, some use carbon fiber, possibly fiber glass, and many people used wood (Last year many teams used wood). A mediocre to good machinist can really help a team.

Week 2 – Continue design and prototype

Figure out what type of appendages and apparatuses you need to do the job you want and try some stuff. Issues that should be though about are things such as, this year is a shooting game, do you just want to dump balls in the lower basket? Do you catapult like arm to throw balls? Do you want something like a baseball pitching machine?

Build prototypes to test the designs. Prototyping is just rigging up something that is similar to what you want and seeing if it will work. You might use wood or PVC. Be safe while your prototyping, sometimes the apparatus need to be held together by hand while testing.

Begin building the chassis frame, put on the transmission, and figuring out where everything will go.

Week 3 – Build the drive train and continue to prototype.

Continue on with building the Chassis, putting on the motor’s, wheels and chains.

Finish up prototyping the appendages and apparatus. Once you get something decided for the apparatuses and start building it.

Good luck

PS Here is the link to the youtube video of Woodie Flowers from the 2012 kickoff. I thought it was very good.

24
Feb
11

FIRST Competition Season

FIRST Robot build season for 2011 is complete and now it’s on to the FIRST Competition season. Starting March 3rd the FRC events begin, time for your robots to pucker up…assuming you put that feature on your robot.

I’m going to be a volunteer at the San Antonio FIRST Regional event. I’m going to be working Field Technical stuff. I would appreciate it if anyone is there would drop by and say hi. Since you don’t know my face, ask where Joe Varnell is; that’s me.

I’ve had several rookie teams ask “What should I expect at the competition?” Here are a few things to think about beforehand:

  1. Make sure you bring safety glasses and gloves. All the competitions are fairly strict on wearing safety glasses in the pits.
  2. Be prepared to work on or fix your robot! Bring tools, tie wraps, extra parts in case your robot breaks, duct tape (which is good for everything)
  3. One good idea is to bring ice chests with food for lunch. A lot of teams will be outside having lunch and relaxing during lunch. It’s also cheaper that way.
  4. Read the rules on what to bring. You’ll need a bill of goods, a list of items on your robot that didn’t come out of that years kit.
  5. Bring a long Ethernet cord. They don’t allow wireless communication in the pits so you need to tether your robot in the pits.
  6. Be prepared to keep your batteries that you are not using on the charger. This is so you can have a fresh battery for every match.
  7. Have a banner to display your team number, team mascot, and your sponsors. You should always support your sponsors.

At the competition, on Thursday, be prepared for:

  1. Robot weight in. After you get your robot unpacked and put together you’ll need to get it weighed in and sized. The weight is without the battery or bumpers.
  2. Access point setup. You’ll have to take you white access point off your robot to be setup with the WPA for the competition. This is so it will communicate properly with the Field Control System (FCS)
  3. Robot inspection. Robot inspectors will come around to your pit and verify your robot meets the spec’s from the robot manual. Some of the top things they check are bumper height and that they meet bumper specifications. Also, the pneumatic pressure is 120 psi max on the storage tank side and 60 psi on the solenoid side (make sure you read the pneumatics manual). The electronics power will be checked and probably that the driver station shows the battery voltage. (this is done by powering the analog bumper and putting a jumper on it)
  4. Try to get out on the field for a practice match. This will let you see how matches are run and what to expect.
  5. Don’t be afraid to ask for help. This is important. If you’re having problems, don’t struggle to long. Ask a more experienced team, mainly those with numbers under about 3000 or teams with robots that look really well put together. Also, there will probably be some experts there who can help the teams.
  6. There will also be a practice field somewhere to test your robots operation.
  7. There will also be a machine shop in case you need parts worked on.

On Friday and on Saturday morning are the qualifying rounds.

  1. Be prepared to answer the judge’s questions. There will be judges in blue shirts walking around asking questions. They are judging various categories and there should be students around (except during matches) to answer questions.
  2. Get your robot to the robot queue when it’s called. Look at the match schedule and see about when your matches are. Also, listen for your team number to be announced and get to the field quickly.
  3. Make sure you have time to look around and to watch other teams. This will give you ideas for next year.
  4. Talk to the veteran teams and make friends with them. The next year you can probably go out to other teams and see how they operate.
  5. Before your matches, talk with the other teams you have alliances with. Be a team player and plan your strategy. Learn each of the alliances robots strengths and weaknesses and plan what each team should be doing.
  6. Because of the random alliance parings, even rookie teams have a chance to be in the finals.

Saturday afternoon are the finals.

  1. The top 8 teams will be picking alliance partners, be prepared to pick just in case you make it to the finals. If you are choosing alliance partners and don’t know who to choose, the team rankings will be on the screen (probably behind you). Look at that and pick the top numbered team on the list.
  2. The rules of how to alliance pick will be explained. However, if you don’t understand then ask someone.
  3. If you are in the finals, have fresh batteries ready to go. Make sure your batteries are charged. The finials are fast paced.

I’ve probably left out some things and I apologize for that. There will be a lot going on, don’t let it overwhelm you.

In a nutshell, this is what will go on. My closing advice is to get plenty of sleep, be friendly, eat breakfast, talk to other teams, and, above all, HAVE FUN! It will be hardest fun you’ve ever had.

29
Nov
10

FRC Autonomous mode

I have 2 goals for teams, especially rookie teams, and the 2 goals are for every team to be on the field and ready to go for every regular match and for every team to move in autonomous. Hopefully, when you build the kit, you will have a movable robot.
There are two ways to move in autonomous. The first is to do action after action after action as shown below.
Sequential operations
The problem with this is if anything interferes with the sequence, there is no change in behavior. If the robot hits a wall or another robot knocks it off course, it will keep trying to move forward. It will try to turn against the wall which it may or may not be able to do. And move forward again. This could be a problem. Also, it only goes on for as long as make steps to move.
Another way to handle it with a little more programming and more flexibility is a state machine. I’ve written some about state machines but I’m not sure I’ve emphasized the importance of state machines. A state machine is a basic software engineering paradigm. National Instruments has a state machine tutorial for LabVIEW. It’s a for LabVIEW only, no robots involved but it demonstrates the principle.
The program starts in a state. The program will watch for one or more actions to occur. Actions like a touch sensor activating, a sonar sensor senses something, or something comes within a specified distance. Based on the action detected, the program moves to another state. Then other actions are waited for.
State Diagram Sample
This over-simplified state machine demonstrates some operations based on a state machine. This says to go straight and watch the touch sensor. If the touch sensor is hit the state moves to the go back 1 foot state. If the distance is reached then it moves to the turn right 90 deg. state. Coming from the move back 1 foot state, once the distance of 1 ft is reached it changes states to the turn right 90 deg. state. Once the turn 90 degrees have been reached the state changes back to the initial move forward 10 ft state and everything starts over. The robot will go around in a square but if it hits something it tries to avoid it.
For the FRC robot, the state machine is perfect for autonomous mode. In autonomous mode you want to do something, like drive until something happens, like a certain distance is achieved or something is hit.

07
Nov
10

FRC Touch Sensor

Sensor’s come in handy in Robots. Sensors can be used when the robot is autonomous or when the driver needs some help. In the breakaway game, to help the driver we used the camera to see the ball on the far end of the field and to line up on the target from the middle area. Touch sensors could have been used to sense when the ball was in place and ready to be kicked or distance sensors on each side to help go through the tunnel. And I’ve already talked about encoders to move specific distances.
For next year’s FRC game who knows what sensors can be used. So you need to be ready and understand how sensors work and how you get information from them.
I’ve put in these links before but they are important learning about sensors. National Instruments has some good papers on sensors and their effective use. They have some basic sensor information and their basic paradigm is ”Sense Think Act”.
Digital I/O (DIO) is one of the simplest Sensor inputs. This can be used for touch sensor to tell when you’re against a wall or when something is in place. To get to the Digital IO go to the WPI Robotics Library >> IO >> Digital IO >> DigitalInput pallet.
> IO >> DIO” />
In the DIO example it show’s on the blue digital sidecar that there’s a signal diagram showing three connections, a positive, power, and a signal. For a simple touch sensor, electronics store have some touch sensor switches. Or a simple switch for touch can be built with some stiff wire going through a loop as shown below.

The resistor should be a 2.5 Kohm. The 5Volts will make the value hi when the wire through the loop is not touching. When the ground wire touches the loop it will ground the signal to a 0.

The LabVIEW code from the example is shown below.

The block diagram shows the Digital IO is opened according to the slot the DIO module is in and the DIO line. This example will simply show the value coming in from the digital IO line on the front panel. However, this can be used to sense when something is being touched, a wall, a ball is in the right place, or you’re in contact with a tower. It’s simple but very useful.
More about sensor’s next week.

28
Sep
10

FRC LabVIEW Programming – more basics

LabVIEW is a Graphical Programming Language. As a programming language it has a lot of the constructs as text based languages but also has a lot of features that make it easier to use. It also has things to keep in mind when you’re programming.

First thing to remember is that LabVIEW is a data flow language. What that means is that a block has to have all its connected data inputs ready before it executes. Also, there is no guarantee of order of execution of the blocks unless they are wired from one to another. In the example below, block 1 will not put out its output until the two inputs are both ready. Also, with block 2 and block 3, there is no way to tell for sure which block will execute first.

The main way to sequence blocks is to use the error wires to sequence the blocks as shown below.

Above, since all of the inputs have to be at the block before it executes, since the output of block 2 goes to block 3, this will force block 2 to execute before block 3.
Another important item that you need to be aware of is that Loops are threads. What that means is that each loop executes independent of each other and executes at the same time…as far as you’re concerned. An excellent use of this feature for your FRC Code is one loop waiting for a button to be pushed to kick while another loop is taking Joystick inputs to drive the robot. The two loops below both run at the same time and would see no difference in execution. One thing to remember is to put “wait” blocks in the loops. Without the wait blocks other loops may not have any time to execute because one is taking up all the processor time. In the example below, without the wait block in the loop with the button read all that would be going on is the processor waiting on buttons the joystick. The loop with the joystick read would only run occasionally and you would see a lot of sluggishness in the movement of the Robot.

Another important construct in any programming language is the state machine. The state machine allows the robot to do one step, once complete, do the next, then do the next, etc. This is great for the autonomous mode where you want to do a sequence of steps. Such as move forward, stop, kick, move forward again, etc.

The pictures below show a simplistic state machine example with 3 states and an idle state (state 0). In the Begin block (in robot main) you would initialize the State Number.vi with a 1. Then once you start executing the loop the state machine is in it would execute the case #1. Of course you would actually need to do something where below I just say to do something. It may be drive the motors forward for a certain amount of time. The true/false case inside the state case should have the output of something with the output of false if not complete and true if the operation is complete. Once the operation is complete a 2 would be output and put into the state number.vi.

Once the state number is 2 then the state case 2 would be executed. Notice the true/false case shown in the picture below shows the false case. What this shows is that if the operation not complete (i.e. a false is output) the state case number stays at 2. And again, once whatever operation is complete and a true is fed into the true/false case, the case number would be changed to 3 (not shown below).

Once the state case is 3, again some actions are performed. Since 3 is the last case we have, once the operation is completed a 0 is put into the state number.

In this case we do nothing else we would just stay in case 0. In this case there is no way to move to another case without re-starting.

Now that I’ve talked about LabVIEW and some concepts of programming, next week, I’m going to go back and talk about some LabVIEW navigation and short cuts that are helpful.