Posts Tagged ‘Programming


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.


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.