"Da Bull" Knows - 2010 Control System Reference

So here we are in a new season again, and we have some new toys from FIRST to play with. In 2010 we now have a laptop computer as the main driver's station. This is a change from 2009 where we had a purpose built piece of hardware (running Linux, yea!) to be the drivers station interface. In 2009 if you wanted a fancy dashboard like the BullBots had, you needed to include your own laptop. Not in 2010! Maybe an external monitor so you can actually read it (wow that screen is small), but the laptop is now included, yea!

In this article I will be covering how the control system operates in the game environment. This will not cover specific programming tasks, we will touch on that in other articles.

To begin, let's run through the various parts of the communications system.

At Team Home Network Setup

On the robot side of the communications there are these components:

• National Instruments cRio
• Wireless Bridge

On the Driver Station side there are these components:

• Classmate PC
• Joysticks (or other input devices)
• E-Stop (emergency stop) button
• Wireless Router

There are two types of setups we will review. First we will review the setup you have at home. This is to facilitate practice driving, demonstrations, and friendly competition with your local area teams. The second setup is the setup which will be at the competition both on the field and in the pit area.

Let's walk through the local setup by first reviewing a diagram to show how everything fits together.

It is key to follow the setup guidelines in the control system references located here:

Start in section 2.5 for control system setup. This includes the wireless configuration. We are not going to go over the detailed steps, but hit the high level of how this all works.

In this setup every device connected to the network will have an IP address. It is important to understand which addresses are in use and which ones are required in order for your development team to work effectively.

Let's go through the assigned IP addresses. Normally on a wireless network you might have at home, the IP addresses are assigned dynamically, via a tool called DHCP. In this network there are available DHCP IP addresses, but the robot is expecting the IP addresses to be static, or manually setup and configured.

The "x.x"ť part of the network number assignment is done by the team number. In our case the team number is 1891. So the network number for the cRio is 10.18.91.2. If it was team 50 then network number would look like the following: 10.0.50.2.

The netmask on all devices will be set to 255.255.255.0.

The reason it is important to know the IP addresses in use is because if there is a conflict, communications will not work and the robot will not function. We will cover some basic trouble shooting steps to make sure the network is working before you spend hours trying to figure out what is wrong in your program. If you have ever spent hours trying to figure out a broken program and later find out the issues was the network is really frustrating. By doing a quick verification on the network when there are issues it is a quick step and may save you hours of trouble shooting.

So how simple is this trouble shooting tool. It is as simple as "ping"ť. If you have never used ping before, it is a simple tool to check to see if a computer is responding on a network. Let's walk through the steps. We will also touch on a tool call ipconfig.

Start by opening a windows command prompt. "Start -> Run"ť and you will get a dialog box like this.

Type cmd in the open text box and hit “enter”.

You will get a window like the following.

This is where we will do our magic.

First let's run ipconfig and make sure our network is set up correctly. Type "ipconfig /all"ť The output will look like the following.

Look for an entry which should have your IP address with your team number. If I was team number 1020 this is what my address might look like. If you do not see any entries that have your team number in the 10.xx.xx.5 or 10.xx.xx.6 then you might have a network error on your PC. If that looks OK, then let's jump to the next step.

Make sure the robot is on and the cRio has power (the green light should be on). Run ping by typing "ping 10.xx.xx.2"ť. make sure the "xx.xx"ť is replaced with your team number. You will get output like follows.

In this example I used a different IP address, but if the robot is up and communicating, then you will get a response which looks like this in the picture above.

If you get this in the picture below.

Then there is an issue in the communications between the PC and the robot. Work back through your setup and verify the various components.

OK with that quick test, and by following the FIRST setup guide we are communicating with the robot. So, how does this all work?

The Driver's Station PC (#4) runs a program in the “driver” login called driver.exe. This is a Labview program which handles input from the USB ports on the PC and translates the control data received into data for the cRio(#1). It formats this into a standard communications packet which C/C++, Labview and Java all understand. This is then transmitted on the network with a destination address of the cRio(#1).

The cRio receives this data packet and then disassembles it, places it in special control structures, which are then consumed by the robot application. In Labview, the joystick input VI has the x and y axis, and the buttons. The location where this data comes from is the data packet received on the network. This data is populated in the data packet by the driver program on the Driver's Station PC(#4).

Now the robot will send data back to the driver station as well. This data includes things like the battery level, the status of the relays, and other important data. There is also a user defined section of 1000 bytes where programs can add extra elements which they want to display on the dashboard. This message is packaged by the robot program and transmitted back on the network with the address of the Driver's Station PC(#4). When the PC receives this message it does the same thing as the robot, it disassembles it, puts the data into special control structures and then acts on it.

This communications is constant while the robot in on and the Driver's Station program is running. If there is a communications error between the Driver's Station and the robot this trigger a situation on the robot where the watch dog on the robot does not get fed and dies (poor puppy). A watch dog is a special piece of code that expects to receive a update on a set frequency. If this does not happen and it's time expires (1-2 seconds), then it's job is to stop the robot. If it was not there, then the robot might continue to execute it's last command until something drastic happens. Imagine your robot you just spent 5 weeks building were to go hurtling at full forward speed towards the concrete wall. You will be happy the watch dog is there to stop it if something goes wrong.

The other way to stop the robot is with the emergency stop button (#6). This is a clear way to the team on how to stop the robot if something starts to go horribly wrong (which never happens right guys?). Hit the button and it sends a stop message on the network for the robot to stop its program and shut down. In order to restart the robot after this, the cRio will need to be powered off and turned back on (or reset/rebooted).

Competition and Pit Setup.

Watch for updates as we will be adding to this section as we get closer to competition and have a better idea how they will be configuring the field setup.

Hopefully this article is helpful for your teams understanding of how the communications work on the robot. Let us know if you have questions.

Contact Da Bull with a question

Back to Top