New REQUIRED version of C++ libraries

[BradAMiller]

There was an issue with the C++ NetworkTables implementation that only appeared when there were several robots all updating a number of variables very frequently. This usually occurred with SmartDashboard but would also fail with the default LabVIEW dashboard and NetworkTables or any other NetworkTables client program on the robot network.

There is a new version of WPILib that will be required for C++ teams that has been posted here:

http://firstforge.wpi.edu/sf/frs/do/...ate_rev_362 2

Install the update on your development system. Then rebuild your robot program and redeploy.

Brad

[JesseK]

Will this be in an email update or on the FRC Blog?
Do you expect any logic issues after the update?
Is there a way to get ONLY items 1,2 & 7 rather than all of them?
I'm not familiar with the Smart Dashboard -- that's the driver's display side of things? We use C++ on the robot, but write a custom Java display for the driver's station. (I'm not the lead robot programming mentor; I'm the System Architect for the 3 software systems we'll have -- sorry I'm don't know more)

While I'm sure code works right now, any required update after competitions have started is a pretty big deal for teams who can't test the updates on their robot ahead of time. More information is definitely needed.

[Jefferson]

Thanks for your work to resolve these issues. I think we were affected in one match during Week 1. Glad to hear there is a resolution.
I'm curious, though, how this will be enforced. Terms like "mandatory" and "required" are used, but as far as I know, there is no way to check the version of WPILib that the code was compiled with. Nor is there anything in the rules requiring specific libraries.
I hope there will be some help during inspection to help teams through this. I don't think we can rely on CD and those of us watching FirstForge to get the word out to all teams.

On a related note, I thought some of the changes in the FMS this season were to limit the impact that data traffic from one team could have on another. Did I misunderstand, or was the issue not fully addressed?

[Jon Stratis]

Any bets on the number of teams that will need to get this update from my USB drive at LSR on Thursday?

[Joe Ross]

Originally Posted by JesseK

Will this be in an email update or on the FRC Blog?

It is supposed to be in today's team update.

[BradAMiller]

I didn't see it in the email blast but it should be in the team update. You can verify that it is installed by looking in the c:\windriver\wpilib folder and looking at the version on the source code zip file. It should be 3622 if the update was installed.

The changes numbered 3, 4, 5, and 6 should not effect anyone not using those features (changes are very local) and the features had serious defects before the update. Was there a particular change you were concerned about?

Brad

[virtuald]

Originally Posted by BradAMiller

There was an issue with the C++ NetworkTables implementation that only appeared when there were several robots all updating a number of variables very frequently.

Wait a second... I thought all of the robots were supposed to be isolated from each other?

[rrossbach]

Brad -
I could check this by looking at the sources, but....

My understanding is that the WPILib Java implementation closely tracks the C++ implementation.

Does the NetworkTables issue also exist in the Java implementation?

- Ron
Team #2607 controls mentor

[BradAMiller]

Originally Posted by rrossbach

Brad -
I could check this by looking at the sources, but....

My understanding is that the WPILib Java implementation closely tracks the C++ implementation.

Does the NetworkTables issue also exist in the Java implementation?

- Ron
Team #2607 controls mentor

It does track closely like you said, but the issue was in some C++ specific socket creation code and that Java library does not have the same issue.

Also, I'd like to add that the new version of the library was run successfully on Saturday afternoon and Sunday in California last week and for Sunday in Michigan (I think) for all the C++ teams at those events. So we believe that the changes are very safe and would have never rolled it out mid-event if we were thought it would add risk to the success of teams at those events.

Brad

[Mike Copioli]

Brad,

Thank you for this update.

What is the observed robot behavior that this fixes?

[virtuald]

Originally Posted by Mike Copioli

Brad,

Thank you for this update.

What is the observed robot behavior that this fixes?

A diff can be seen here. Looks like the big changes are disabling TCP_NODELAY, requiring a newer version of the Jaguar firmware, and fixing the way it searches for entries.

[Joe Ross]

It's the night before week 2 competition starts and only 119 downloads of the update (compared to 600 or 700 downloads of the first two updates, and 2000 downloads of the kickoff version).

[taichichuan]

Originally Posted by virtuald

A diff can be seen here. Looks like the big changes are disabling TCP_NODELAY, requiring a newer version of the Jaguar firmware, and fixing the way it searches for entries.

Hmm... Disabling TCP_NODELAY. That will add several ms of latency to the link. Was there a problem in polling the socket connection that required this? Just curious because in almost 30 years of working with VxWorks, you typically want to *add* TCP_NODELAY to reduce communicaitons latency rather than remove it.

TIA,

Mike

[Greg McKaskle]

I haven't seen the code, but my understanding is that at last some of the writes were done a byte at a time -- likely with the iostream ++ syntax. That plus the no-delay resulted in lots of packets that made the router unhappy.

I agree with your comment about no-delay. I'd expect the latency to be around as much as 100ms.

Greg McKaskle

[taichichuan]

Originally Posted by Greg McKaskle

I haven't seen the code, but my understanding is that at last some of the writes were done a byte at a time -- likely with the iostream ++ syntax. That plus the no-delay resulted in lots of packets that made the router unhappy.

I agree with your comment about no-delay. I'd expect the latency to be around as much as 100ms.

Greg McKaskle

Hi Greg,

Yeah, I could believe that. Given the number of packets in normal driver station comms, I could see that there's likely a fair amount of 802.3x flow control packets if the switches are being overrun. However, this sounds like a hack. VxWorks is a very deterministic O/S. If it's resorting to very short payloads, it's likely because there's a resource starvation going on someplace and this is a quick hack to get past the problem. I've seen multiple places in WPILib that look like desktop folks trying to understand operating in real-time -- unsuccessfully. But, they keep introducing additional layers of abstraction hoping to make things easier. However, abstraction layers have a price. I suspect that this small payload issue is one of those prices.

How much longer are we using this control system? There are many ways to improve performance on the 'bot without losing the 3 language support. I've been a long time user and developer on VxWorks. But the reality is that WRS, really isn't doing much to promote the use of VxWorks on the 'bot. They're really missing an opportunity, IMHO.

Thanks,

Mike