2015 RoboRIO/Control System Feedback

[Jared Russell]

Originally Posted by Jared

-Timertasks don't work properly if they are started before connecting to the driver station, but work if the reset button is pushed on the roboRIO. Troubleshooting this behavior is difficult, and it's never comforting when resetting or redeploying code puts the controller in a different state than a cold boot.

-Java timertask timing is worse than in previous years.

We ran into the first issue at CVR...the problem is that the scheduleAtFixedRate() method schedules execution relative to the timestamp of the first execution (and the RoboRIO initially assumes it is turned on at the beginning of the epoch), but when the robot connects to the driver station, the local clock is synched to the driver station time. Your code freaks out because it thinks it has ~45 years worth of work to do in order to catch up, and as a result your TimerTask hogs the entire CPU. TL;DR, never use scheduleAtFixedRate(). Thanks to Joe Hershberger for helping us to figure this out.

As for TimerTask timing being bad otherwise, this is because of some incomplete JNI between the HAL and WPIlibJ. Whereas LabView and C++ use the onboard hardware timer to generate interrupts for calling recurring tasks, the current implementation of TimerTask uses Thread.sleep(), which is quite unreliable. We would schedule 5 ms periods and get around 5 ms most of the time, but we would see several 10+ ms periods per second, and occasionally even 200+ ms periods.

We hacked our WPIlib JAR with some additional JNI to get to the FPGA timer and were much, much happier with our timing jitter. I think Tom submitted a patch to WPIlib, so hopefully this will be fixed for next year. It took us a long, long time to figure it all out...

[wireties]

I generally loved the new control systems and the Talon SRX motor controllers this year. Just a few requests:

1 - Please reconfigure the kernel to include POSIX message queues and semaphores. Embedded Linux is incomplete w/o these primitives.

2 - Please make it easier to use static priorities in threads. Many teams roll their own software solutions and we can't do the same things we did with VxWorks.

3 - Please use latching connectors on the roboRio. It is nearly a crime that we use the old PWM connectors in a high vibration environment.

4 - Please do not use Silverlight. It requires the client be Windoze and install a bunch of crap.

TIA

[RyanShoff]

Requiring Silverlight to manage a Linux device bugged me.

If we left the robot on for a long time, maybe 15-30 minutes, the robot would freak out. Planning to debug that later.

[Thad House]

Originally Posted by RyanShoff

Requiring Silverlight to manage a Linux device bugged me.

If we left the robot on for a long time, maybe 15-30 minutes, the robot would freak out. Planning to debug that later.

This was actually an issue at Worlds, since Chrome dropped NPAPI support the week before. So we spent about 10 minutes trying to connect to the webdash, until I remembered, and we switched to IE. I would prefer to use chrome, which means they should switch to something chrome supports, and not silverlight.

[RyanShoff]

Originally Posted by Thad House

This was actually an issue at Worlds, since Chrome dropped NPAPI support the week before. So we spent about 10 minutes trying to connect to the webdash, until I remembered, and we switched to IE. I would prefer to use chrome, which means they should switch to something chrome supports, and not silverlight.

This chrome://flags/#enable-npapi and click enable will work for another year or so until Google has said they will really remove it.

[timytamy]

Originally Posted by RyanShoff

Requiring Silverlight to manage a Linux device bugged me.

I agree it seems wrong, however maybe have a look at Pipelight (http://pipelight.net/cms/installation.html). Seemed to work ok for me (admittedly, I only opened the management page and clicked around, I didn't do any serious work with the roboRIO this year).

For convenience, Pipelight installation on Ubuntu (and derivatives):

sudo add-apt-repository ppa:pipelight/stable && sudo apt-get update && sudo apt-get install --install-recommends pipelight-multi && sudo pipelight-plugin --update

[billbo911]

Originally Posted by Thad House

The mDNS SmartDashboard issue cost us a match thursday at champs. I hope they can figure that and maybe a few other mDNS issues out for next year. Having to restart Driver Stations when running back to back matches is sometimes very odd.

Originally Posted by Alan Anderson

I saw lots of teams with lots of control system issues this year. None of them was really the fault of the control system itself. When the instructions are followed by someone who actually pays attention to them, and who is not sloppy with the wiring, things just work. The roboRIO's web console is great, and the rework of the DS-to-robot communication protocol seemed to make a positive difference in connectivity. I just wish Windows weren't so unpredictable in how it deals with switching between networks with and without DNS active.

....

I completely agree with both of these quotes.

What I believe would make a huge improvement to the quirkiness of mDNS is to put a "Restart mDNS" button on the DS. It would give all users a really quick way to connect to the field and RR. Restarting the DS, changing the team number and changing it back, disabling and re-enabling the NIC all work, but they are all more difficult processes than what is needed.

[MrRoboSteve]

Originally Posted by billbo911

What I believe would make a huge improvement to the quirkiness of mDNS is to put a "Restart mDNS" button on the DS. It would give all users a really quick way to connect to the field and RR. Restarting the DS, changing the team number and changing it back, disabling and re-enabling the NIC all work, but they are all more difficult processes than what is needed.

The developers got a lot of feedback about the DS connection issues at the field. Based on historic response to feedback, it will likely be a focus for them in the off season.

Originally Posted by Alan Anderson

the Weidmuller connectors seem to be happiest with 20 gauge wire, but teams seem to want to use 18 gauge or thicker. This makes inserting the wires without risking short circuits more difficult than it ought to be.

Agreed. I saw a bunch of this last year as CSA, less this year as FTAA but I suspect a lot of it was dealt with by our crack CSA crews. I tell teams that, if you can't give the wires a good tug, they're not in there well enough.

[Bryan Herbst]

From what I heard from folks at FIRST, NI has an update ready to go that fixes the need to restart the DS (or toggle the team number) between back to back matches.

It wasn't released during the season due to the complexity involved with trying to ensure that every team got a mid-competition season update, but *should* be available sometime during the offseason.

Overall, the new control system has been great. I love the web config, and I have dreamt of being able to use more modern versions of Java for years.

The most annoying problems I ran into were also the most common (mDNS being slow on the field and Axis camera configuration), so I have faith that they will improve for 2016. We've already seen some improvements, so hopefully another few months will make it even better.

As Alan mentioned, the Weidmuller connectors are easy for teams to wire incorrectly. Too many teams have copper splayed out around the connection. Hopefully this will get better as teams gain more experience with the connectors (and with their robot shorting out on the field).