What do we do with legacy cRIO when we get Athena?

What support or options will we have for using our cRIO hardware when Athena becomes the FRC controller?

Many teams have multiple controllers for use on practice bots and instructional robots. What programming options will we have going forwards for this hardware?

I’m most familiar with WindRiver, since we programmed in C++, and I worry that we will not have licenses for the workbench environment on the cRIO afterr Athena debuts. I suspect there are similar issues with cRIO labview or Java support.

I think I would like to see an open source OS with a selection of programming interfaces available so that we can continue to make use of the legacy hardware as long as it continues to function.

Maybe we could even get support for custom programming the FPGA, since the controller would not be legal for FRC competition anyway.

I would really hate to see all that hardware turn into bricks and recyclable electronics parts.

…You mean basically like most of the old IFI stuff? :yikes:

you can still use it. the new one is is software compatible, lighter, and cheaper.

The old IFI stuff didn’t necessarily rely on software licenses that expired. The problem here is that while we’ll all have cRIOs, will we be able to do anything with them after 2014?

I know that Java doesn’t need any licensing to run, but I really hope that the new stuff is backwards compatible. Our team currently has 3 crios that we can drop into 6 different robots (09-13 plus a practice 2013) and have working instantly. This is a really valuable resource for us, as we can prototype with wide, long, 6wd, 8wd, 4wd, swerve, and meccanum wheels really quickly. If the cRIO’s are no longer usable, we’ll have some trouble.

As for the IFI systems, they aren’t useless. We have 1 robot that is from before 08 that is all set to go, we just need to turn on the breaker, and plug in the OI and it will start. We also have a laptop with mplab, the compiler, and the ifi downloader that we can use if needed.

I will be slightly upset if on our old robots our team needs to replace cRIOs (released 2009) with IFI controllers (released 2005) in order to keep them going after we get robotrio.

The goal is for the SW tools given out in future years to support roboRIO and cRIO controllers – at least for a transition period. Changes made to WPILib may mean that old code needs a few tweaks to work with the new SW tools, but ideally, you simply recompile.

Things like the driver station and dashboards may undergo enough changes so as to have an old and new version that are both present on the system.

I also suspect that some of the legacy SW tools will be made available, particularly if you ask and explain the value in it. I’d love to see the FPGA tools be made available as well, but that is not getting much attention at the moment.

Greg McKaskle

That is good to hear.
My biggest concern is the licensing aspect. As official support tapers off, and moves to the more modern hardware, I don’t want to be dependent on time locked licenses for the tools needed to program the legacy hardware.

Do we need a project to create a replacement for vxWorks as the cRIO base OS?

Do we have enough info to make such a project practical?

vxworks doesn’t have a time locked license, so you don’t have to replace it. Windriver Workbench does. People have already been working on gcc compilers. See http://firstforge.wpi.edu/sf/projects/c--11_toochain

I would assume the cRio will maintain compatibility with later LV releases, so you could probably hold on to them and use them on things like robots from past seasons or prototypes.

This isn’t the official word but I’m betting strongly you will be able to use the new or old system.

They did announce that all teams will receive a RoboRio in their 2015 KOP so my bet is that it will be the only competition legal controller for that and the following seasons just as they did when the CRio replaced the IFI system. Again that is not official just my belief based on the currently available information and how things played out in the past.

Nothing in the Java toolchain has a time-restricted license. If bad comes to worse, learn another language.

I think Ed meant that teams will be able to operate both control systems (e.g. at home), as opposed to competing with either system.

That is not the way I read it. Certainly you will be able to continue to use it at “home”.