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

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