Custom Driver Station on the Field

[Slade]

Originally Posted by Alan Anderson

A team at the Indianapolis district competition had the same problem. The SD variables on the Basic tab don't seem to be getting to the robot when they're connected on the field. The team says they were working fine earlier in the day, but now don't -- and they made no code changes at the time.

They came up with a workaround: they tether the robot in the queue and set the value then, leaving the robot on until the match is over.

So instead of building the code and pressing Run as Startup, we should just press the button that is a "soft" deploy(The button to the left: http://puu.sh/ghsYK/d1b8777f29.png) and then pick it through the dashboard, then disconnect the thether, and when we get to the field, just do our thing and connect the computer to their ethernet?

[Alan Anderson]

Originally Posted by Slade

So instead of building the code and pressing Run as Startup, we should just press the button that is a "soft" deploy(The button to the left: http://puu.sh/ghsYK/d1b8777f29.png) and then pick it through the dashboard, then disconnect the thether, and when we get to the field, just do our thing and connect the computer to their ethernet?

No. Why would you think you should do that? As soon as you unplug and lose the network connection, the interactive execution will stop. All the team did was to power up the robot with the Driver Station computer connected by wire, set the control on the Dashboard appropriately, and unplug the tether. The SD value was retained by the roboRIO as long as it didn't get powered down before the match began.

[MrRoboSteve]

Another thing to try is to close and reopen the driver station and dashboard prior to connecting to the field.

[MikeF1617]

Originally Posted by MrRoboSteve

Another thing to try is to close and reopen the driver station and dashboard prior to connecting to the field.

This may fix it, except after connecting to the field and being sure the robot code is started (boot your robot before going onto the field and peeking at other driver stations to see if FMS is established or seeing if team numbers are on correct on the player stations). I found that the TCP connection (contains all the network variables) does not open for some reason with the dashboard code if the robot has not been started up first and the FMS hasn't established a connection yet, it matters the boot order of the robot code and the FMS connection. I found that if you wait on opening the dashboard (logging into driver on the classmate PC if you have it as start-up), everything works fine. I created indicators that indicate when the dashboard establishes connection with the robot by checking to see if a code revision was written to a network variable by the robot, this or checking your variables tab will tell you if you have connected.

We set our autonomous mode before the match starts, and it is stored in a global variable (not necessary but we have dashboard code and robot code separated in different loops in different areas, its a custom structure) on the robot, and that does the trick, as long as there is a connection to the dashboard established. This seems to be a bug with the dashboard code, and if other people are having this issue, then I would assume its a problem with the code provided in the WPIlib or the TCP just doesn't work well in certain scenarios for some reason, and I haven't found a fix yet. Its a pretty weird problem.

[TylerStaudigel]

Check your data types in automatous mode. The data coming from your numeric read does not match the date type that you loop is looking for causing the loop to default to zero every time you run the program.
http://puu.sh/ggnQW/e4c23b7496.png

[Mark McLeod]

Yea, your data type in Autonomous is a floating point number not the integer type of the Case. The floating point number doesn't equal any of the integer cases, so it is taking the default.

The problem exists on both the Dashboard side and the robot side.
You need to write/read an integer on both sides and you need to make sure the enum order matches the numbers you expect.

[MikeF1617]

Originally Posted by Mark McLeod

Yea, your data type in Autonomous is a floating point number not the integer type of the Case. The floating point number doesn't equal any of the integer cases, so it is taking the default.

The problem exists on both the Dashboard side and the robot side.
You need to write/read an integer on both sides and you need to make sure the enum order matches the numbers you expect.

This is how I managed the different datatypes in our code. (The image contains two screenshots, one from the dashboard and one from the robot code.) On the robot code side, the mode is being casted into an enum typedef using the Type Cast function in the Numeric Palette under Data Manipulation.

However, LabVIEW should be (and I assume is) automatically casting the double into an integer, as shown by the red dot in this screenshot that you are referencing:
http://puu.sh/ggnQW/e4c23b7496.png

So technically, that part should be working fine, but it is better to cast it yourself, just as good practice. There is probably some communication issue occurring here, however, so try to recreate the problem in practice with a similar setup to how you run your robot at competition, specifically the boot order and time of connection.

[Joe Ross]

Originally Posted by MikeF1617

This may fix it, except after connecting to the field and being sure the robot code is started (boot your robot before going onto the field and peeking at other driver stations to see if FMS is established or seeing if team numbers are on correct on the player stations). I found that the TCP connection (contains all the network variables) does not open for some reason with the dashboard code if the robot has not been started up first and the FMS hasn't established a connection yet, it matters the boot order of the robot code and the FMS connection. I found that if you wait on opening the dashboard (logging into driver on the classmate PC if you have it as start-up), everything works fine. I created indicators that indicate when the dashboard establishes connection with the robot by checking to see if a code revision was written to a network variable by the robot, this or checking your variables tab will tell you if you have connected.

FIRST is looking into this: http://forums.usfirst.org/showthread...3862#post93862