Custom Driver Station on the Field

[NHoffmann]

Ours worked. You have to do a custom driver station project (from the launch screen of Labview), with a numeric selector of some sort (slider, counter, whatever). You have to build that, then take the application (under LabviewData, then builds, then FRC Driver Station), possibly transfer it to whatever computer you use as an on-field driver station if it's different than your programming computer, then edit the properties of the driver station built program in order to auto-launch the new station, as well as overwrite the old station program. Then, you have to use the "driver station get numeric value" block in your auton mode vi. After that, give the get value block the same name as you gave it on the driver station. Finally, wire that into a numeric case structure, with each numbered case being a different auton mode. When you set the number before the match, the robot should grab the value at first. I can't take a screenshot of ours right now, but if you would like, I will try to take and post one after school today.

[Slade]

Originally Posted by Slade

Well for the driver station end, we made a list, and made wrote it to the dashboard data like so:
http://puu.sh/ggndY/7f4bb61c6e.png

Then, in Autonomous for our case selector, we referenced it and put it to our case selector (which selects the autonomous mode):
http://puu.sh/ggnQW/e4c23b7496.png

and this is how our cases are numbered:
http://puu.sh/ggnSQ/e8ce2212a1.png

I know it works cause when I deploy it regularly its fine, but when I run as startup and we go on the field, it just always runs 0

Look at the pictures in that post. That's essentially what we did already

[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.

[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

[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.

[Levansic]

Originally Posted by Slade

Well for the driver station end, we made a list, and made wrote it to the dashboard data like so:
http://puu.sh/ggndY/7f4bb61c6e.png

I see the problem!

For lack of a better way to describe what is happening, you have a namespace collision. You have the same name for the Network Table variable as you have for your numeric control. Change the name of one, but not the other. I would suggest shortening the control name to "Auto Mode", then see if you have the errant behavior.

We discovered this issue in our dashboard, where we tried to pass a value to the robot by a name that was also shared by a numeric control. At first, it made sense, as the network table name was the same as what we had on our dashboard. It didn't occur to us that there would be any issue. We manually typed values into the control, and didn't notice that the sent value was not updating every time. We discovered the problem when we added a different mode to generate a sawtooth signal, passed through the same network table variable. To our surprise, the numeric control on the dashboard (which should be an input only) started to display the numbers we sent to the robot through the network table as if it was an indicator for that variable. This is not supposed to happen!

This bug caused unpredictable behavior on the robot, where sometimes it did what we expected, and other times, it seemed that we couldn't override the last value that was set. We discovered that our successes had more to do with setting the control a second or third time to the desired number, as if there was a race condition of some sort.

Changing the names to non-identical identifiers fixed our issue. I will note that MikeF1617 did essentially the same having "Autonomous Mode" as the name for the control, and "auto_mode" as the network table variable.

[Slade]

Originally Posted by Levansic

I see the problem!

For lack of a better way to describe what is happening, you have a namespace collision. You have the same name for the Network Table variable as you have for your numeric control. Change the name of one, but not the other. I would suggest shortening the control name to "Auto Mode", then see if you have the errant behavior.

We discovered this issue in our dashboard, where we tried to pass a value to the robot by a name that was also shared by a numeric control. At first, it made sense, as the network table name was the same as what we had on our dashboard. It didn't occur to us that there would be any issue. We manually typed values into the control, and didn't notice that the sent value was not updating every time. We discovered the problem when we added a different mode to generate a sawtooth signal, passed through the same network table variable. To our surprise, the numeric control on the dashboard (which should be an input only) started to display the numbers we sent to the robot through the network table as if it was an indicator for that variable. This is not supposed to happen!

This bug caused unpredictable behavior on the robot, where sometimes it did what we expected, and other times, it seemed that we couldn't override the last value that was set. We discovered that our successes had more to do with setting the control a second or third time to the desired number, as if there was a race condition of some sort.

Changing the names to non-identical identifiers fixed our issue. I will note that MikeF1617 did essentially the same having "Autonomous Mode" as the name for the control, and "auto_mode" as the network table variable.

I will definately try that, but I am still a bit skeptical because it did work when we went to the practice field and tried changing the autonomous mode around. Only when we went for an actual match was it not getting the right value.

[Alan Anderson]

Originally Posted by Slade

...it did work when we went to the practice field and tried changing the autonomous mode around. Only when we went for an actual match was it not getting the right value.

This sounds exactly like the symptoms reported by several teams now. It could just be coincidence or a false pattern, but the common factors seem to be using LabVIEW robot code and connecting the Driver Station while the code is already running after a cold boot.

One proven but clunky workaround is to power up the robot in queue with the DS already connected. The currently suggested procedure is to restart the robot code after the robot and DS are communicating on the field.

[wt200999]

Originally Posted by Alan Anderson

It could just be coincidence or a false pattern, but the common factors seem to be using LabVIEW robot code and connecting the Driver Station while the code is already running after a cold boot.

This description leads me to think it could be related to a fix jhersh provided to our team at Dallas. He can provide a better explanation then I can, but his description was roughly as follows:

In the below code, if the create listener VI fails (first VI), it does not attempt to recreate this listener and the connection never occurs.



The fix is below. I'd paste it as a VI snippet, but the local variable makes it not as straight forward.



In both the error cases there is a simple 100ms wait.

[Slade]

Originally Posted by wt200999

This description leads me to think it could be related to a fix jhersh provided to our team at Dallas. He can provide a better explanation then I can, but his description was roughly as follows:

In the below code, if the create listener VI fails (first VI), it does not attempt to recreate this listener and the connection never occurs.

Attachment 18560

The fix is below. I'd paste it as a VI snippet, but the local variable makes it not as straight forward.

Attachment 18561

In both the error cases there is a simple 100ms wait.

I checked in the NT Server.vi and I saw this. What you have and what I have are very different.

Case "No Error":
http://puu.sh/gmB4f/e4087185f4.png


Case "Error":
http://puu.sh/gmB5a/0a5d48af60.png

Theoretically, couldnt I just set the timeout to -1 so it keeps waiting till it finds a connection under the TCP Wait on Listener?

[jhersh]

Originally Posted by Slade

I checked in the NT Server.vi and I saw this. What you have and what I have are very different.

The code we are talking about is in the top-level VI for the Dashboard code. It is the TCP connection between the DriverStation and the Dashboard. The reason this impacts the NetworkTables connection is that the Dashboard gets the robot IP that it will connect to from the DriverStation.