Archive Page 2


Mentoring and using LabVIEW and Joystick buttons

First I want to share the FIRST in Texas blog on FIRST mentoring. I’m very dedicated to FIRST and helping kids learn about Science, Technology, and Robotics. I also have a lot of fun mentoring and blessed to be able to help.

Next, it’s drawing near the end of the robot build season and time is getting tight. I’m hoping everyone is getting close to getting done or at least has a plan on getting done. With most teams, as in real engineering, the programming is getting done last. Even though the programming is getting done last you still need to test it before you get to the events.

One thing that I’ve found very useful is a way to hit and release a button and cause an action. Then later hit and release the same button and cause the opposite action. For instance, you hit the button to close the grabber and the same button to open the same grabber. Below is one way to do it, using button 8 of the joystick to control a solenoid. All the figures below are the same while loop showing the different case structure code.

Figure 1 is the diagram for the case where the button is still pressed after the processing has happened. The case structure is true when the button is pressed and the last time through the processing the button was also pressed.

Figure 1

Figure 2 below is when the button is not pressed. The result is false and no processing is done. The button is not pressed AND the last time through the processing the button was not pressed.

Figure 2

In figure 3 below, the button has been pressed and it’s first time through the loop to do the operation. This shows the processing when button was pressed AND last time through the processing the button was not pressed. This is when the actual operation is done. The innermost case statement is where the solenoid operation is done. In this case the last operation on the solenoid was turned on and the operation had been set to true. In the inner case statement it’s set to false this time so that next time the solenoid will be set opposite it currently is.

Figure 3

The false case of the innermost case statement would be opposite of figure 3, the solenoid would be turned on and a TRUE sent out. Also, the joystick and solenoid would need to be initialized in the

This vi would allow the opposite operation be done each time the button is pressed. There may be easier ways to do this by the NI folks, but this is the solution I came up with. I hope this helps.


FRC – Analog and Digital Sensors

Sensors can really help with robot performance. There are several sensors that come in the Kit Of Parts (KOP), limit switches, the encoders (2 kinds), IR sensors (for line following), gyro, camera, and accelerometer. There are several different ways these sensors interface with the computer. Some through communications protocols such as TCP/IP that the camera uses or I2C protocol that some of the Lego Mindstorms sensors use. There’s also a digital interface used by the Quadrature wheel encoder and the limit switches and an analog interface used by the gyro and the magnetic wheel encoder. I’m going to focus on the the two simplest, digital and analog sensor interfaces.

A lot of the analog and digital sensors use a 3 pin interface. There is a ground (minus) and 5 volt (plus) pins to provide power to a device. The third pin is a signal. On the analog input the signal pin accepts voltages between 0 and 10 volts. On the digital input, it accepts a voltage between 0 and 6 volts. If the voltage is above 3.2 volts (I think) a “1” is read and below 3.2 volts a zero is detected.

The Analog bumper is shown but digital side car has the same pin out.

As long as any sensor you have is 5 volt you can wire the 5 volt sensor line to the 5 volt pin on the analog or digital interface, the ground to the GND pin (minus) and the signal line to the SIG pin, the sensor should work. Note that if you get the ground and power lines backwards, the sensor may burn up. In other words, be careful about wiring and look for black spots on the chip or a funny smell after you hook it up.

A sensor that uses a digital interface basically sends an on/off signal. Limit switches are the best example. When the limit switch is closed, a one can be read by the computer. When the switch is open, a zero is read. Limit switches are good for checking the end of a mechanical movement or when something is in place like a scoring piece. The quadrature encoder sends digital signals for each rotation to the digital sidecar. This creates a pulse stream as shown in the diagram. By counting the digital signals, the computer can tell how far the robot has traveled. That’s basically how the LabVIEW encoder blocks work.

Analog sensors send out a voltage that can be measured by the analog module on the robot. Analog sensors such as distance sensors will put out a voltage based on the distance an object is from the sensors, the closer the object the more voltage the sensor puts out. If you know how much voltage is put out per inch, the distance can be figured out by multiplying the distance per inch with the voltage. The gyro puts out a voltage as the gyro is turned.

If you read the data sheet on a sensor it should say if it’s analog or digital, what pin is for power, what pin is for ground and what pin is the signal. Almost any sensor for analog or digital should be able to be used fairly easily. If you have any questions about sensors or about other robot issues you can e-mail me at Good luck.


FRC build week 2 musings

I hope everyone’s Robot planning is going well. I’m also hoping all the teams have their strategy down and have a plan to fit the Robot to the strategy. Make sure whatever strategy is chosen is done well. If it’s a defensive strategy make sure the Robot is built to push other Robots around or to be the best blocker possible. If you have a scoring robot, make sure you can score quickly and efficiently.

The Kit Of Parts (KOP) came with many sensors, everyone should try to make use of them where they can. The sensors can be used to aid the driver in Robot operation and to help in autonomous mode. Some of the sensors like the wheel encoders can let you know the distance you move. The linear encoder can help the Robot tell the distance an actuator moves. The gyro can help your robot tell which direction it is pointing. All the sensors have examples that are runnable. To get to them, open LabVIEW and in the lower right hand corner of the opening screen are the FRC examples. All examples have diagrams of how to hookup the sensor. Also, all the data sheets are located on the site Make sure you scroll down.

Right now is a very important time in the build, some parts of the Robot are coming together well, some parts are not coming together and are in need of redesigned. Don’t get discouraged, just keep working at it. There are only four weeks left in the build season but it is plenty of time to get things together.

One thing people should think about is Prototyping. Prototyping is to build a quick and dirty model of whatever you are prototyping. One example is the kicker on last year’s robot. We (team 704) built a wooden frame, screwed it down to the floor and then used different things to kick a soccer ball. We made a kicker and tried various pneumatics, surgical tubing, and bungee cords. We made prototypes of different ways to kick a soccer ball. This year you might prototype various ways to put the game pieces on the scoring pegs. Come up with a way to score the game pieces and build something to try out your ideas.

It’s important to get your robot to a point you can test it before the ship date. Getting out there and running it through its paces is a key to success. Last year’s FRC challenge contained humps the robot had to go over. Our robot was ready somewhat early (a week early) and so we did some testing on a practice field.

During testing last year, after a couple of test runs our chains started to fall off and this bent axle is what we discovered. This along with a torn aluminum pan holding the battery. You don’t want to find out about this during the competition.

Good luck to all. Figure out what to do and do it.


FRC Robot Season – Getting started in programming

Its FIRST Robot season and everyone should be well into making sure they know the game and into discussions on what they want their robots to do. The game is fairly simple in concept and can be played in many, many ways. The programming of the robot can be key, the way you move around the arena, the way the game piece manipulator is operated, and how autonomous is played.

Really, there’s three sets of programming the teams need to be concerned with, the Robot, the dashboard, and the mini-bot. I’m not really going to write much about the mini-bot for now, mainly because we are putting that part off for a while.

The LabVIEW programming is fairly close to last years. After opening LabVIEW, make sure you remember about the “Find FRC Examples…” in the lower right corner. It will bring up the LabVIEW example finder to the FRC examples, but there are thousands of other standard LabVIEW examples in the example finder. There are tutorials on various FRC subjects. The tutorials don’t go into depth but show you how to get started on the different subjects. It does have some important information on how to set up the camera. The left side contains LabVIEW projects that have been opened and new projects to be started with the Dashboard project and the Robot project.

Also, when starting your project, don’t forget to put in your cRio IP address. The project that is opened is the way LabVIEW (and other programming languages) group required files together.

The Robot is the starting point. Make sure you read the green area’s those are note added by the NI people to help guide the teams as they navigate the code.

For now I’m just going to write about the Autonomous and Timed Tasks, circled in red below.

One thing to remember is that LabVIEW is parallel, each top level while loop acts independent of every other loop. One programming issue that should be remembered is that different things you want the robot to do should be put in separate while loops. In other words, you should put your game piece manipulator control vi’s in one while loop, other controls in another while loop, and leave the motor drives in another while loop…such as the

The Timed Tasks block (named Periodic is designed handle this. There are several while loops set to run at different time intervals, one at 10 ms and one at 100 ms. There is also an example while loop to flash lights as a demonstration. In one loop, the code for the apparatus movement should added. This will make the apparatus code not interfere with the apparatus code.

Also, remember, when taking human inputs, i.e. push a joystick button, the average teenage human only has a reaction time of 100 ms. So if you’re watching for a button be pushed, the 100 ms timed loop should be fast enough. Also, make sure there is a timer in every while loop.

The autonomous is controlled separately by some underlying NI code, it is only called once. There is a simple line follower in the vi. I’ve not tried it yet but it requires the IR sensors. The IR sensors in the KOP are 12 v sensors. The wires to the sensors are as follows:

  • Blue: Negative (NEG)
  • Brown: Positive (POS)
  • White: Dark Out (DO)
  • Black: Light Out (LO)

That means the Blue and Brown wires go to the power distribution board and either the white or the black wires go to the digital IO on the sidecar.

The line following routine doesn’t take into account the Y in one of the lines. This would have to be taken care of somehow. Also, the apparatus movement would need to be added to the vi so that it doesn’t interfere with the movement.

Well, that’s it for now. Remember, if you have technical questions you can e-mail me at or get onto the NI forums at

ADDENDUM:  I tried the line following in Autonomous Independent and it didn’t work. You should probably look at the line following tutorial at to see what NI was thinking when they implemented the code, I know I am.

Thanks and Good Luck.


It’s FIRST Robot Season!

It’s FIRST Robot Season! Start of the 6 week build season. To start with I want to make sure the password is out for all. It’s kind of hard to type in but can cut it from below and paste it in the encryption password.


Next, I want to say how excited I am about the build season. This week everyone should be understanding the game, brainstorming and begin designing their Robots. Plan what needs to be done before you talk about how to do it.

I’ve read the game manual twice. I’m ready to help our FIRST team 704 to start understanding the game and brainstorming tomorrow. I know a lot of people aren’t sure where all the various resources for the game are so I want to list all the resources I’ve found so far.

At the NASA Robotics page you’ll find the full kick off video, the game animation, and a video by Grant Imahara (Mythbusters) on Robot design. Everyone should re-watch the game animation to make sure they understand it.

There is a LabVIEW update on the NI site that, I believe, is a mandatory update. You should probably run it to complete preparation for the Robot Season.

There is also a cRio update that everyone, LabVIEW or not,, must run.

National Instruments has a LabVIEW guide to FRC Robot programming that put on your hard drive that has a lot of information on the robot, robot code, and all things NI for the FIRST Robot.

Also, on the Kit Of Parts page on the FIRST website, there is more information than just the kit of parts. Make sure you scroll down. There’s a lot of information (data sheets) on a lot of the technical parts, the Pneumatics Manual, and a lot of sites you can go for help. There’s information on the sensor’s that should be helpful. But don’t forget about the LabVIEW examples for FRC. They can be really helpful.

There is a lot of information out there to help, especially for rookie teams. Remember, there is help out there. Also, I can be reached at and I can help or at least let you know where you can find help.

Get out there and start brainstorming and designing your Robot.


FRC – One Week until kickoff

It’s only one week until the FRC kickoff around the country, Jan 8th, the kickoff of Robot Season! There’s a buzz in the air around the Robot rooms all around the country. I know team 704 is preparing for the big event. At the Dallas some of us will be helping out with the event. I’ll be helping NI Bob with the set up of the Compact Rio and required software. If you’re going to the Dallas Kickoff, please drop by and say hi, I’ll be in my red team 704 polo shirt where ever the software is being set up.

In Dallas, they have a quick build the afternoon of the kickoff. Each team will have the opportunity to leave the kickoff with a basic moving robot. This is a great advantage to the rookie teams, it really helps them get a head start on the building of their robot.

The team I mentor, team 704 lead by Phil Harris, has been through the kick off, brain storm, and build many times. I would like to suggest to the rookie teams to go to the kickoffs around the country and try to make contacts with the more experienced teams. Most of the veteran teams don’t mind helping out and giving guidance to the new teams.

Before the kickoff, everyone should make sure they can decrypt the game and robot files. Go to the game documents location on the first website and follow the directions for the test. Also, once the test file is decrypted, you will get a hint to the game. Also, at some point, all the game documents will be put in this location but will only be able to be opened using a password that you will get at the kickoff.

After the kickoff, the kickoff video will be available on the FIRST website. Saturday evening, everyone should re-watch the video and think about the game. Write notes, they will come in handy during the brain storming session when you’re deciding on the robot design. Then on Sunday, re-watch the video, make more notes, and re-read the notes from Saturday. Hopefully, you should have an understanding of the game. Everyone will have a different perspective on the game that’s been announced and so it’s important for everyone to have an understanding.

When your teams meet for the first time after the kickoff, everyone should be ready to brainstorm, discuss their idea’s, and come up with a robot design to best play the game.

Good Luck to all. I also want to say the the FIRST in Texas has named me a lead mentor for North and East Texas. That means I’m here to help. If anyone has questions, need a little guidance, or just doesn’t know how to proceed, I want to encourage you to ask me. E-mail me at The only bad question is the one not asked.


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 ( 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, 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.