Archive for the 'Compact Rio' Category


Prototyping and Trying it out

I hope everyone is doing well this second week of Robot build season. Last week and possibly early this week everyone should have a chassis planned, a way to get up and down the field, and maybe some way to get the balls to a hoop.

But first, a lot of people are having trouble setting up the cRio and LabVIEW software. I’d like to suggest to RTM (Read The Manual). Most of the information is in the document at this link (

On with prototyping: You don’t necessarily need to do everything in the game. If you’re a rookie team you might think about doing one thing very well. One thing that can be helpful is getting the balls from one end of the field to the other. Or you might play defense well, keep the balls from moving or have some type of shield that moves up to 84 inches to block shots.

No matter what, by now you should understand the game and how you plan on playing it.

When you know how you want to play the game and are designing your robot to play you should brainstorm on how to get your robot to do it. Prototyping is a way of trying out thing quickly before going to the time and expense of building it on your robot.

To prototype, decide what you are trying to test to see if it would work, quickly build something out of wood or plastic that is approximately what you want and try it. Sometimes parts are C-Clamped together or tied with rope.

One example is a couple of years ago on Breakaway, we were prototyping a ball kicker. First we rigged up some pneumatics on the kitbot, held a pneumatic cylinder by hand and punched the ball. It didn’t work well. We then screwed a frame down to the floor (Our Robot room is an old trailer), took some surgical tubing, rigged up a wooden kicker on a long meddle screw. We would pull the kicker by hand and see how well it would work.  We the switched the surgical tubing to pneumatics and tried it again. We liked the pneumatics the best. It took about 5 hours to try everything, we didn’t waste time building a full robot part to see if something worked or not, and we had a pretty good robot that could score from two-thirds of the field and move the ball the full distance.

Good luck to all


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 – Sensor basics – Encoder

Sensors are the way the robots interact with the world when not being controlled by the driver. NI has some basic sensor information.
They can also help the driver with operations for control. The basic paradigm for using sensors is Sense Think Act. This link has some good information on the Sense Think Act paradigm.
Think Sense Act means to use the Sensors to sense the world, distance, objects, orientation. Process and integrate the data from the various sensors. And then act on it, move in the direction or do an action based on that data.
The first thing to do is understand the sensors, how they’re used, and how to communicate with them. Some of the easiest sensor communication is digital I/O. Sensors like limit use digital I/O (DIO). The compressor pressure switch also uses DIO. DIO indicates on or off, it’d that simple. From there some thinking has to occur. “Are we at a limit?” “How many times has a DIO turned on?” Things like that.
Another easy to use interface is Analog Input. Analog input measures the input voltage of a sensor. Distance sensors are a good example of how an Analog Input can operate. Some distance sensor output a higher voltage when an object is close and a lower voltage when an object is farther away. The voltage would have to be calibrated to distance. Just note that not all Distance sensors are analog input.
Some sensors have serial communications. This can be a little more complicated than the simple DIO or Analog In data but you can get a lot more information from sensors and data can be sent to the sensor for various reasons.

Blocks for sensor communication

There many different serial communications protocols. A protocol is the process for sending and receiving data. Who sends what, when, and in what order. Serial, I2C, and SPI are two of the protocols supported by the robot code. There are blocks for standard serial communications, I2C communications, and SPI communications in the WPI Robotics library
Each device that uses serial communications has individual commands and responses based on the sensor. The user’s manual should have information on how to communicate.
The WPI Robotics Library has interfaces to most of the sensors used by the FRC robots. This makes it easy to interface with the standard sensors.

In my opinion, one of the more useful sensors are the wheel encoders. There are examples, sample code, and blocks to support them. Encoders can tell how far your robot has moved. It’s based on the number of DIO “ticks” happen. Ticks are each time a DIO line goes high then low. Each tick represents a distance. The number of ticks for a distance is determined by seeing how many ticks it is for one rotation of the wheels and figure the distance traveled with one rotation of a wheel. After that, if you want to go a certain distance, divide the distance to go by wheel rotation distance and multiply by ticks. That will give you the number of ticks it takes to go a distance.
# ticks = (D / Cw) * tick per rotation
D is distance to go
Cw is Circumference of wheel (wheel base)

If you want to turn, you have to have one wheel encoder go more than the other wheel encoder. To do a turn where one side wheels don’t turn and the other turns the robot you need to have the wheel encoders on one side move while the others stay in place.
There is a good encoder example for the encoders that come in the Kit Of Parts. From the LabVIEW opening screen, in the lower right hand corner, there is an examples area. At the bottom of that, there is a “more…” folder. Click on that and look for the encoder example. Below are some pictures of the encoder example.

Encoder example front panel

Encoder example block diagram

On the front panel there is a picture of how to hook up the encoder and a ready to use block diagram for deploying to the robot. Hookup the motor encoder leads according to the picture and then hit the run arrow. This will deploy and run the example. The driver station must also be hooked up over the network, running, and enabled.
Notice in the block diagram there is an open, configure, and start blocks outside the while loop. The encoder get is inside the while loop and so that it will execute over and over. There is a 100 hooked up to a timer which means the loop will execute every 100 ms.
Before you run the code, if you click on the “highlight” execution button, in red above, you can follow the execution.
Encoders are an easy to use sensor that can really help, especially during autonomous mode.
More on sensors next week.


FRC – Adding Elements to the Robot Code

This week I’m going to lead you through adding an operation to your FRC robot. This will be to show where different block operations should go and how to find the operations you want.
I’m going to use pneumatics and their operation to show how to get something set up. To get started in pneumatics you should read the FIRST pneumatics manual to learn how to set them up and the required “plumbing” behind them. Pneumatics are very useful operation on robots.
So, to dive in:
– Open up LabVIEW and the Robot Main Vi from Robot project
– Then double click on the Begin Vi and hit to open up the Begin Vi block diagram. You should have the default Begin code there. We need to open (initiate) what we’re going to use
– Right click on a blank area to open the Compressor pallet as shown below.

Path to the Compressor Pallet

– Click on the open compressor block and move to just under the Gyro and left click again to drop it.
– Do the same for the set reference block. Both are shown circled in red above
– After the two blocks have been dropped they should be connected as show below. This is done by hovering your cursor over the Compressor open block in order to see the terminals on the block. (hint: hit h to get the help screen up so you can see what terminals are there). Hover over the CompressorDevRef and you’ll see a little spool of wire. Hold the left mouse button down and make a wire from the Compressor open to the registerRefNum block for the Device reference (the pink wire at the top of the block).
Our new blocks in the begin block
– Do the same for the error wire (yellow wire at the bottom of the block).
– To get the “DIO 1” and the “Relay 1” right click on the “Pressure Switch DIO Channel” terminal and a menu will show up. Go to the Create >> Constant and click. This will wire in a constant of the default for the terminal.
NOTE: If you’re ever not sure what you need to attach to a terminal, create a constant for it with the right click >> Create >> Constant
– If you want to change the constant value that was created, click on the blue down arrow and it will bring up your choices
– The “Relay 1” refers to the digital sidecar (smaller of the two blue blocks that came in the kit of parts). On there, there is the label “Relays”. The “Relay 1” means you will plug in a control wire from relay 1 to the Spike relay that controls power to the compressor (page 3 of the pneumatics manual).
– On the Compressor open, the “DIO 1” refers to the digital I/O line the pressure switch is connected to (see the pressure switch on page 3 of the pneumatics manual).
– The block the error wires are connected to start as 2 inputs. To make it longer to accommodate the Compressor error wire, hover over the “build array” block (it’s official name). Then you can drag the bottom blue dot down to open up as many terminals for error wires as you want.

NOTE: The block the error wires are connected to start as 2 inputs. To make it longer to accommodate the Compressor error wire, hover over the “build array” block (it’s official name). Then you can drag the bottom blue dot down to open up as many terminals for error wires as you want.

– Now that you have the compressor open you will want to open a solenoid. You will do the same basic blocks (open and set ref num) from the solenoid pallet. The blocks you’ve added should look about like the picture below. I named my kicker solenoid “kicker” so that I would remember it was the kicker solenoid.

the blocks for opening the references You’ll notice I added another block to the compressor wires. This is to start the compressor. Since really all you do to the compressor is start and stop it (in the finish block) you may as well start it here.
In my opinion, it’s best to add the closing of things like the compressor as soon as you’ve done the open code, just so you won’t forget.

– Below is closing the compressor and the solenoid references. You get the reference to the Compressor with the name compressor and the going into a get reference block. You stop the compressor then close the reference. You do basically the same thing for the solenoid.

The close reference to the block in the Finish block Now that I’ve told you to close your references in the finish block, I read that here that the finish block is never referenced in the Robot code. However, you should close the references as a good programming practice.

– Next is the actual operation of the solenoid. Anything that delays operation should not be put in the teleop Vi. Since all the while loops execute at the same time (parallel processing). For solenoid operation to do a kick, the code should go into one of the timed loop.
100 ms Timed task loop
– Next is the actual operation of the solenoid. Anything that delays operation should not be put in the teleop Vi. Since all the while loops execute at the same time (parallel processing). For solenoid operation to do a kick, the code should go into one of the timed loop.
– Start by dropping a get solenoid reference block with the Kicker name attached. You only need to get this once so you put it outside the block. It goes into a Shift register. The shift register ensures that the reference is kept from one execution of the loop to the next.
– Then you drop in a case statement. To determine when to activate the solenoid we need a button from the joy stick
– For this you need to drop an “unbundle by name”
– Then right click on the unbundle and click on the “Select item” drop down menu. And select JoystickDevRef to get the reference to the joystick
– Then drop a get joystick block and another unbundle by name. Select Item button 1 from the unbundle (like above) with the button 1 to the “?” to select the case to execute. When the Joystick button is pushed the joystick block will read a True.
– Next drop a “flat sequence” from the structure pallet. The flat sequence will execute one frame, once complete, the next frame, etc. Right click on the right side of the flat sequence and select add frame after to add a frame.
– Next drop a solenoid set block in the first frame and create a True constant to it.
– Next frame drop a timer for 100 ms. That’s the amount of time the solenoid will be active. In the last frame drop a set solenoid with a false constant attached to it.

This is how you add the compressor and a solenoid to your robot code.


Some helpful LabVIEW stuff

LabVIEW is a rich computer language, full of features and full of complexity. I hope I can help some with LabVIEW and the cRio.

The first thing that can be done is to print out the LabVIEW quick reference card and place one next to every computer being used for LabVIEW development. LabVIEW is graphical with a lot of mouse usage. If you are used to using a keyboard on the computer, a lot of the “Keyboard short cuts” still involve the mouse.

Of the shortcut keys the I’ve found I use the most is e is the one I use the most. When you double click on a Vi it brings up the front panel. To get to the block diagram, hit e.

If you’re looking for a Vi hit space and it will allow you to search for a Vi. For example, if you’re looking up motor functions, hit space from the block diagram then type in motor and all “motor” Vi’s will be listed.
 space to do a block seach;
If you want to make a copy of a Vi on a block diagram simply put your cursor on the block, hold the key, hold the left mouse key and drag a copy.

To get the context help, a dialog box that show’s documentation for a block, hit h. Then every time you hover a block, it will show the inputs, outputs and some text on what the block does.
 <ctrl> h to get information on the block you are hovering over
If you want options for a block, right click on a block or loop and it will tell you all that you can do.

If you want to see the internals of how a block works, double click on the block to open it up to the front panel, then hit e to get to the block diagram. You can bore down into the blocks until the blocks don’t open anymore.

One thing many teams had trouble with was when they messed up on the LabVIEW, had a loop that was taking up all the time, and couldn’t deploy a new set of code into the cRio. If this happens, turn off your cRio, turn off the “No App” switch on the cRio and power up. The cRio will start but not run your robot code. You can then deploy new code for startup. Power down, put the no app switch back to off and power up.
Compact Rio front panel
Just to note another switch on the cRio is the Console Out switch, which allows a computer to hyperterminal into the serial port on the cRio. This might be good if you don’t want to unplug the Ethernet cable from the game adapter.

The other switches are probably not important for FRC except for possibly the user1 switch. You can use the FRC to get the state of the switch. This might can be used for initial field conditions or whatever else you can think of.

One other useful operation between the cRio and the classmate netbook are the soft switch settings from the setup tab in the panel at the bottom of the classmate. You can set the digital I/O switches on and off on the classmate user interface and read them with the blocks at WPI Robotics Library >> Driver Station >> Compatibility IO pallet Vi’s. The Get Digital Out gets the digital switch settings from the classmate. For the breakaway robot we used this to set which area we started in for autonomous mode. This can also be done with the analog sliders.
Blocks for getting classmate data
One thing that I saw a lot of last year was a lot of people were using the classmate to develop LabVIEW. I like a little real estate (i.e. a larger screen) to develop on. If you want to use a standard laptop to develop on you can do this by plugging a laptop into the wireless router. The laptop will need a unique IP address (set with the control panel) based on the IP address for your team. For team 704 I set my laptop IP address to If you’re at the regional event with no wireless routers you can use an Ethernet switch. Plug the cRio, your laptop, and classmate into the switch and you can still use your laptop for development and deployment. That way you won’t have the small screen of the classmate for development.

These are just a few of things that can be useful for the upcoming Robot season. I am by far not an expert but there is an abundance of experts out there. One place to go for help on LabVIEW or the cRio is the First discussion board. NI employees monitor the board, some say they “monitor” the board to much, and will answer questions. Special thanks to Olivia who always has helpful information. A link to the and click on Discussion board. There are also training material available at