Hold robotInit() Until Driver Station Data Arrives?

Technical Control System
1

Hi -

I have a question about another 2023 WPILib change where a method went away (maybe it never worked - but we were using it), and I’m wondering if anyone knows the equivalent way to do it this year.

I would like to hold the initialization of all the robot code until we get access to the driver station data, as we use dynamic class loading at initialization, and it (used to) take settings from the dashboard to do so. (I realize it’s possible to do it differently, but would like to try and get back to our old approach).

Here is the method as it worked in previous years (up until this year) - the particular method that went away is “isNewControlData()”. I tried looking through the source for the DriverStation and couldn’t seem to find anything equivalent …

Thanks in advance!
Stu

/**
* Holds the constructor until we receive at least one update of the control
* data, which holds the run-time configuration.
**/
private void waitForDriverStationData() {
long count = 0;
while (!DriverStation.isNewControlData()) {
if ((count % 100) == 0) {
logger.trace(“Waiting …”);
}
try {
Thread.sleep(100);
} catch (InterruptedException ex) {
logger.error("exception for sleep: ", ex);
}
count++;
}
}

2

I’m interested to see what youre actually doing that requires this… a rearchitecture of that bit of code might be necessary. Generally speaking, you never want potentially-unbounded loops like that in robot code. If i were starting a project and ran into the need to dynamically change implementation like that, I might do it in robotPeriodic and hide it behind an “isInitialized” flag so I know it only runs once and before anything else runs. If it needs to be able to change dynamically at any point, then i could either remove the flag check, or make it more event-based (depending on how the settings are being transferred over the network, this might be super easy or a bit more difficult).

1 Like
3

You can check for DriverStation.isDSAttached();. This doesn’t do exactly what you want but I imagine it could get you close enough.
This doesn’t work in robotInit- driver station data is processed synchronously with the main robot loop, so robotInit would not end.

Just a note here- Driver station data != dashboard data. Dashboard data is entirely separate, and checking for driver station status does not imply anything about dashboard connection.

3 Likes
4

How did you handle the case where the wrong choice was selected initially and needs to be changed?

1 Like
5

You could make a trigger for DriverStation.isDSAttached and call a command onTrue

6

The big issue I see here is having a driver station connection is not the same as having a dashboard connection. They run on completely separate unrelated protocols, and having one in no way guarantees you have the other.

7 
int handle = WPIUtilJNI.createEvent(false, false);
DriverStationJNI.provideNewDataEventHandle(handle);
try {
  WPIUtilJNI.waitForObject(handle);
} catch (InterruptedException e) {
  Thread.currentThread().interrupt();
}
DriverStationJNI.removeNewDataEventHandle(handle);
WPIUtilJNI.destroyEvent(handle);

Thats the code to do that this year. We don’t have a high level way to do it this year, its all JNI This does mean its technically unsupported, and we can break it even in mid season updates (Although this is generally unlikely). The plan is to add a high level method back again next year, but for a different purpose.

1 Like