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]

Originally Posted by 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.

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]

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.

[jhersh]

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.

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]

Originally Posted by Ring_Lord

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.