Custom Driver Station on the Field

[Slade]

So today at the competition, we were testing our Dashboard to make sure it would run the autonomous we had selected and it was fine on the practice field as long as we had deployed it regularly. When we built the code and put it to run as startup and went to the field, no matter what it would run the autonomous with the value 0.

Until we find a better solution, we have been setting the autonomous we need to use in the match to 0 cause it always runs.

Also, when we deployed it regularly, we made an indicator to confirm it was running the autonomous we specified and it was fine.

[GeeTwo]

I'm not familiar with NI/LV details, but some general things to check:

Is your autonomous setup somehow assuming the tethered configuration, perhaps through a static IP? If the expected network configuration is not available, it's not unreasonable that an initialization of 0 could result. Ideally, only one connection would be made and both autonomous and teleop would use it.

Another possibility is that the connection takes longer to set up via FMS, and it fully initialized when auto starts.

[Joe Ross]

You're going to have to provide more details about how the value is sent and read.

You can work with the CSA at your event for issues like this.

[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

[GuyM142]

When you run as startup check the Variables tab if it really is 0,
it will help concentrating on the source of the problem.

[Ring_Lord]

Our team was working in LabVIEW today on our autonomous mode and found the same problem so we used the dashboard values state (a vi first supplies) and it says in auto mode values are disabled. My current hypothesis is that FIRST disabled any values going from the dashboard to the robot in auto mode.

We are sending an official question to FIRST to see if we are correct.

[Slade]

Our team was working in LabVIEW today on our autonomous mode and found the same problem so we used the dashboard values state (a vi first supplies) and it says in auto mode values are disabled. My current hypothesis is that FIRST disabled any values going from the dashboard to the robot in auto mode.

We are sending an official question to FIRST to see if we are correct.

Thanks for the reply.
Please let me know what they say!

[Ring_Lord]

Will do, just submitted to FIRST about half an hour ago.

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

[Slade]

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]

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.

[jhersh]

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.

One way you can tell if your robot got the message is to look at the tree control on the Variables tab of the LV dashboard. If the variables have a diamond glyph next to them, then the variable is only known about on the dashboard. If there is no diamond glyph, then the server (your robot) is up to date and your correct auto should run.

[Levansic]

My current hypothesis is that FIRST disabled any values going from the dashboard to the robot in auto mode.

We are sending an official question to FIRST to see if we are correct.

I hope you get a reply soon, and I hope your hypothesis is not correct.

In addition to hampering autonomous mode selection, this would make it impossible to process vision on the driver station laptop, at least as far as autonomous goes.

[Alan Anderson]

Nothing is being disabled on purpose.

It seems to happen only when the robot has been turned on and is running user code before the Driver Station makes its network connection to the field. I've only heard about it from teams using LabVIEW, but that might not mean anything.

Wild guess: It might have something to do with the time-of-day clock on the roboRIO. i'll do some checking when I have access to a robot on Tuesday.

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

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]

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]

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.php?24207-Autonomous-Mode-Dashboard-Variables-(LabView)&p=93862#post93862

[MikeF1617]

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]

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]

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]

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

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.

18560

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

18561

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

[Slade]

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.

18560

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

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]

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.