Archive for October, 2010


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.


FIRST Robot Code – Robot Main

I’m not an expert with the Robot Code, the default code everyone gets with the kit-bot, but I do understand it. The code I’m going to write about is from last year’s FIRST LabVIEW installation. I’m assuming that the default code we get this year will be about the same, with the same basic parts. After the kickoff in January, I’ll see if there are any differences and write about them.

Now, on to the Robot code. First there is a document from NI that gives a description of the Robot code, or the FRC framework as they call it. It explains a lot about how the robot code works. It’s a good reference and I assume the will be another for the coming up Robot season.

Below is the block diagram of the overall Robot code for last year kit-bot.
Robot Main Vi code
The flow of the code is from left to right starting with the Begin Vi. The Begin Vi is where you initialize all of the operations you will be doing. In the upper center is the main While Loop that will run until the robot mode changes to Finish. Once that happens the “stop” will be activated (the little red stop sign with a green wire going to it) and the Finish Vi will execute. The Finish Vi closes all the operations that were opened in the Begin Vi. Just a note, even if you don’t close everything in the Finish Vi, when you turn off the robots power, it shuts off anyway.

Near the bottom of the while loop there is a block that says Dashbd Data. This block collects data at a slow pace from the robot and prepares it to be sent back to dashboard on the Classmate netbook. When you see the display change on the Classmate, this is what’s gathering the data. At the top of the loop is where the high priority data is sent back. Most of the time you won’t do anything with these.

In the middle is a case structure that is a state machine like I talked about a couple of weeks ago. This is where the meat of the operations that you will be mostly concerned with. Base on the Robot mode, which comes from the Field Management System (FMS) through the netbook, the state of the match is fed into the case structure. There are 5 cases Timeout, Autonomous Disabled, Autonomous Enabled, Teleop Enabled, and Finished.
Robot Modes from the Field Management System
Timeout case – no data has been received from the netbook and nothing happens on the robot. Notice there is nothing in the Timeout case above.
Autonomous Disabled – this is the case for after the Robot has been powered up and before the match starts. In the Disabled Vi, shown about, you would do operations while waiting on the match to start. Things like reset your gyro or maybe some type of calibration on sensors.
Autonomous Enabled – This case is once the match enters autonomous mode. There are two types of autonomous mode, iterative and independent. This is what you would modify if you were doing Autonomous iterative (this attribute is set in the Begin block)
Teleop Enabled – This case has the direct control from the driver. It gets information from the joy stick and sends it to the motors. This is another place you would modify for driver operations
Finish – The case for the end of the match. It has a true coming out of it to end the main while loop.

Back in the Robot Main there is a Start COM block. This is where all the information is retrieved from the netbook. It has a while loop in the block and so it runs in parallel with the main processing loop, in other words it runs at the same time.

Also below the main processing loop is a sequence structure with 2 blocks in it, Vision and Timed loop. The Vision block contains the code to process the camera image. If you want to process the image to, say, look for a color, you would modify this block. For last year’s game it was looking for the target above the goal.

There is also a Timed tasks block. Each loop in this Vi is not connected to the other block so they each run independent of the other. There is a timer in each to make each run at a different speed. In these loops you would put things like reading a joystick button and doing an action like a kick. Remember, that any blocks put outside the loops will only execute once. Anything you want to run over and over needs to go inside the loop.

I’ll help with how some of the sub Vi’s, such as Begin Vi and Autonomous Iterative Vi, from Robot main work. Remember, get the old robot out and try to add new code and see what happens.


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