Driver Station limitations/bugs

[jross]

Here are some of the limitations/bugs of the Driver Station (DS) that beta teams have found.

Hot plugging joysticks is not supported. If you plug in a joystick after the DS has already booted, it will not be recognized. The workaround is to always have your joysticks plugged in.

The DS only supports joysticks that use the standard HID interface. This means that if a joystick requires special drivers on windows, it won't work with the DS. Unfortunately, this means the XBOX 360 controller won't work.

There is no API for displaying data on the DS LCD (like the UserMode byte from previous years). This is planned, but not implemented yet.

Occasionally the DS will send bad joystick data before the joystick has been moved the first time. The workaround is to always make sure the robot is disabled when first starting up, and move the joysticks before enabling for the first time. (I believe this one will be fixed soon.)

When a joystick is unplugged, it continues sending the old value. The workaround is to not unplug joysticks while running.

Occasionally, communication will lag by about 2 seconds. The workaround is to unplug any Ethernet cable for a second, then plug it back in.

Occasionally, communication will stop between the DS and the cRIO. One way to notice this the robot will stay disabled when you enable. The battery voltage on the DS display will also not update. The workaround is to unplug power to the DS and then let it reboot.

I probably don't have to say it, but FIRST and its developers are working very hard on the ones related to safety.

Praemonitus praemunitus (Forewarned is forearmed).

[page2067]

Per thread in electrical - but what you have here is a some of what I am seeing - but worse.

We did see a delay in the joysticks etc. during bench tests, but now I am not getting communication to the cRIO even after rebooting. - symptoms include the DS not responding to the dongle switch, and also not responding to the Tele/Auto switch. Battery says: no Comms.

I have tried different ethernet cords, and the data lights are on solidly. The cRIO is on.

[page2067]

Further clue - if I reboot the DS with-out the connection to the cRIO ethernet, it comes up fine, dongle and mode switch work. If I then plug in the ethernet to the cRIO after a few seconds it comes up with "invalid" for team, mode and system.

[Rwood359]

Here are some of the limitations/bugs of the Driver Station (DS) that beta teams have found.

Occasionally, communication will lag by about 2 seconds. The workaround is to unplug any Ethernet cable for a second, then plug it back in.

Occasionally, communication will stop between the DS and the cRIO. One way to notice this the robot will stay disabled when you enable. The battery voltage on the DS display will also not update. The workaround is to unplug power to the DS and then let it reboot.

Can you expand on these conditions?

Do they only occur when tethered or can they happen during wireless operation or both?

Does the safety system kick in and stop the robot on loss of communication?

How often do they happen?

Either of these conditions could be a problem in our practice area.

Thanks

[jross]

Do they only occur when tethered or can they happen during wireless operation or both?

Everyone is still working to fully characterize these two issues. The definitely occur over wireless, and may occur while tethered.

Does the safety system kick in and stop the robot on loss of communication?

In the case of the loss of communication (the second one) yes, the robot is disabled.

How often do they happen?

Not very often. I've seen them maybe 4-5 times over the past few weeks.

[willson.thomas]

When the delay is present, is there also a delay in the disable/enable dongle?

[jross]

When the delay is present, is there also a delay in the disable/enable dongle?

I have not tried the disable switch while the delay is happening. It does not happen very often, which makes precisely characterizing the problem very hard.

[omalleyj]

Is anyone who can reproduce this problem doing so while running a packet sniffer? I would suggest doing so if not. Then look at whether the entire stream just stops or there is a burst in ICMP, etc.. This will help narrow it to the stack or the HW.
Wireshark is a good, ____ sniffer and there are others
http://www.wireshark.org/

[DarkOps_Developer]

Here are some of the limitations/bugs of the Driver Station (DS) that beta teams have found.

Hot plugging joysticks is not supported. If you plug in a joystick after the DS has already booted, it will not be recognized. The workaround is to always have your joysticks plugged in.

The DS only supports joysticks that use the standard HID interface. This means that if a joystick requires special drivers on windows, it won't work with the DS. Unfortunately, this means the XBOX 360 controller won't work.

There is no API for displaying data on the DS LCD (like the UserMode byte from previous years). This is planned, but not implemented yet.

Occasionally the DS will send bad joystick data before the joystick has been moved the first time. The workaround is to always make sure the robot is disabled when first starting up, and move the joysticks before enabling for the first time. (I believe this one will be fixed soon.)

When a joystick is unplugged, it continues sending the old value. The workaround is to not unplug joysticks while running.

Occasionally, communication will lag by about 2 seconds. The workaround is to unplug any Ethernet cable for a second, then plug it back in.

Occasionally, communication will stop between the DS and the cRIO. One way to notice this the robot will stay disabled when you enable. The battery voltage on the DS display will also not update. The workaround is to unplug power to the DS and then let it reboot.

I probably don't have to say it, but FIRST and its developers are working very hard on the ones related to safety.

Praemonitus praemunitus (Forewarned is forearmed).

I would add to this post that FIRST is working on the bad data from joysticks and has a preliminary fix but not for the OTB image on the Driver Station.

FIRST and NI are very busy working on the 2sec delay issue and may have narrowed it down. Testing is slow due to the holiday but we are working on it.

Something to keep in mind for both Beta Testers and the teams, there has been a lot of work updating and modifying documentation, software, drivers, and everyone involved is really pushing hard to get things right as soon as possible.

[usacat6]

Requesting clarification of the driver station interface to the field control system. I have seen notes indicating that the alliance driver stations have a predetermined order, station R1, R2 and R3, representing red alliance drive positions. Does the field control system match an alliance drive station (ie. R1) to a specific alliance field robot start location (ie. Red launch pad next to Blue outpost)? The drive station get alliance vi suggests that this information might be provided by the field control system or by the electrical team installing switches to set these important information values.