Posts Tagged ‘LabVIEW


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 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 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 and 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 stripped down with nothing going back to the Dashboard 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.


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.


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.