Hi Gang,
Is there a copy of the 2015 WPILib available for download yet?
If not, does anyone know when the library sources will be available?
TIA,
Mike
I don’t have official knowledge so take this for what it is worth. Normally it would be at kickoff. Since they are selling roborios Nov/Dec they might release it earlier. I would expect it until after Beta is done though. Part of the Beta non disclosure (at least in the past) is not to release the Beta versions, one reason given is so not to have multiple versions out there.
The project is available here: https://usfirst.collab.net/sf/projects/wpilib/
If you have an account (ie. from signing up for the Gazebo beta) you can pull it, but otherwise I don’t know how to get it.
It is actually available on a publicly accessible website if you happen to look hard enough.
Disclaimer: I am not on a alpha or beta testing team, nor have I received any special non-public information from anyone.
My immediate guess is that changes to WPILib might well not be done or finalized, so the 2015 version might not truly exist yet.
As the updated wpilib is going to be designed for the roboRio, I’m not sure how much good it will do you at this point. I haven’t heard yet if it will be backwards compatible with the cRio, or if they’ll maintain separate libraries…
At any rate, the new Wpilib, at least at this point, isn’t really any different from the old. The entire Alpha Test phase (which isn’t done yet) has been all about getting the libraries updated to work with the roboRio, not adding new features or changing things dramatically.
Actually, I’m not interested in backwards compatibility. As a guy who does embedded Linux for a living, I’m more interested in seeing the implementation to see what needs to be changed to make it work correctly in a multi-core environment.
You can’t just take the uni-processor version and hack it to run on a multi-core. There are race conditions galore intoduced in mutli-core systems because of the 1-1 threading model that Linux uses. And, since the NI-Linux is rumored to have the PREEMPT_RT patch in place, there are a number of tweaks that need to be done in order for the data flow to work smoothly. Not to mention simply knowing what kernel release is being used will tell me a lot about what to expect in the driver model.
Additionally, there’s the issue of moving from a big endian PPC to a little endian ARM (let alone VxWorks to Linux). I developed a lot of training materials for Wind River to help customers move from VxWorks to Linux. So, I know most of the pitfalls. I just don’t want to spend the first two seasons with the roboRio trying to shake out bugs when I know how to fix most of the ones that will be introduced in the move to Linux.
Thanks,
Mike
There’s 2 days left to apply to beta test. http://www.usfirst.org/roboticsprograms/frc/blog-2015-Control-System-KOP-Survey
+1 applying for Beta. That is where you can provide the best feedback.
C++ is going to Eclipse for 2015 (along with Java). You can search around NI’s website & find information on how they implement Linux. They are doing it on other platforms than the RoboRio I doubt that it is a hack. :] The current Crio uses a different operating system.
OK, I’ve applied for the Beta. Thanks for the link.
I’ve been using Eclipse for embedded Linux work on ARM architectures since 2006 and I helped develop some of the VxWorks operating system-level code that ran on the cRio. So, I’m familiar with the issues of translating from one to the other. Also, I’m on the Arduino Tre beta-test team where we’re mixing a Beaglebone black and an Arduino Leonardo on the same board. In that process, I’ve also rebuilt the kernel and perfomed several tests to prove out functionality.
From what I’ve read so far, the NI Linux release looks like a standard 3.x kernel with the PREEMPT_RT patch applied. But, I’ll wait to actually see some of it to make sure. As for the processor, the Zynq 7000 used on the roboRIO is a known quantity. So, they shouldn’t be having too many issues with the kernel port these days. The only issue will be the device tree structure that they’ve put together for the BSP on the Zynq. Given the pinmux isses of so many I/O pins, but no way to route them, it’s easy to make mistakes.
Due to the limited storage on the roboRIO, the Linux distribution will be a tricky tuning job that will be easy to miss things. I’m sure they’re probably using Yocto to build it because that will give the best size. But, it will be interesting to see what they’ve included on the file system.
In any case, 2015 is shaping up to be a really interesting season. There are a lot of exciting possibilities for the new control system. But, only time will tell if they can be realized.
Thanks!
Mike
Do you mind sharing? I’ve looked at GitHub, Google Code, the FirstForge page, and the NI page, and I can’t find it.
Googling “wpilib source” gives https://usfirst.collab.net/sf/projects/wpilib/
as one of the first few results. Then, under the wiki, you can find directions to install the eclipse plugins. The address that is hyperlinked is incorrect, but the text “http://frcbuilder.wpi.edu:8190/view/2015/job/eclipse-plugins/lastSuccessfulBuild/artifact/edu.wpi.first.wpilib.plugins.updatesite/target/site/” is correct.
Installing the plugins puts wpilib at C:\users[your user]\wpilib\java\2014.03.267\lib\Wpilib-sources.jar. You can use winRar to extract the source code.
Exploring other pages on the site brings you to lost of other good stuff too, like
http://frcbuilder.wpi.edu:8190/view/2015/job/WPILibJ-Athena/ws/WPILibJ/
which looks like what you’re looking for.
Unfortunately, all of this stuff appears to be for VxWorks and not for Linux. Many of the directories still have VxWorks build artifacts in them. So, it was interesting to take a look. However, this doesn’t appear to the be Linux code.
In the Eclipse plugins, however, they do mention both Linux and OS/X. That’s not to say that these are the real plugins. The Linux and OS/X references could be red herrings.
I’ll keep looking…
Thanks!
Mike
Something about the WPILib, is I think most off the communication libraries are not open sourced, but closed libraries that the 3 languages then access. I know those libraries do all the hardware and network communication, and the robot code just reads and writes directly to those. So most code would be fairly portable, and not usually interfacing at the system level.
If this were Windows or OS/X, then you’d be correct. Most of the libraries are closed. But, the WPILib is licensed under the BSD license and is therefore considered open source. Additionally, must of the libraries on Linux (the new roboRIO O/S) are available in source code. And, based on past issues with code like the hacked-up network tables code and the other communications code where they had problems (e.g., needing to take off the Nagle algorithm to get the C++ code to not overwhelm the FMS) communications libraries are precisely the places where WPI needs the most help.
It certainly is possible to have one set of binary libraries and then provide binding to different languages. This means that a bug in the library will cause all languages to fail equally 
. Brad Miller and his folks work diligently on the WPILib. But, putting extra sets of eyes on it only help to make it more robust and safer. The students in the beta tests will be trying to implement a robot as users of the code. But, those of us with significant development experience in the multi-core ARM Linux environment can help make sure that more of the inevitable multi-core Heisenbugs are terminated before the start of the 2015 season.
It would appear that this page is no longer updated, but there’s some new stuff that’s definitely not for the cRIO, like this.
There’s more too.
I’m looking at the code in the link and I see are terms like SEM_Q_PRIORITY and VX_FP_TASK that are very VxWorks specific. That, and the total lack of anything with “inux” in it, make me believe that this is still a VxWorks file. In fact, this file looks to be autogenerated by the jnaerator code. So, these are not the droids you’re looking for… 
But, it does give some clue as to how they might go about supporting the different languages.