X86 cRIOs - possible roboRIO 2 processor?

So I was looking on NI’s website and noticed something on their cRIO page. All of them appear to have x86 Intel Atom processors instead of the ARM ones they’ve had in the past. (And the PPC processors I believe the FRC cRIOs used) I don’t know if the roboRIO 2 will get these, but it could be cool if it did.

I don’t think the architecture change itself would affect a whole lot programming and performance wise, but it would help robot simulation and unit testing a lot if all the libraries were built for x86 Linux by default.

1 Like

There was a point in time where I really thought we were going to get an intel replacement. I’m definitely not of that opinion now.

Who knows though? There is a pandemic and things might change in regards to a new control system.

FWIW, I’ve run NI RT Linux within an x86 VM. It runs fine, even with a custom kernel.

x86 cRIOs have existed since at least 2011, if I recall correctly. As for the roboRIO 2, FIRST has already given an official statement on the next control system in this blog post:

We received cooperative proposals from National Instruments and REV Robotics that complement FIRST’s technical needs and mission, and we’re happy to announce that the 2022-2026 system will consist of a revised roboRIO from National Instruments (increased RAM and flash memory, improved low-voltage protection, and a higher-speed grade Zynq processor) and support boards being developed by REV Robotics.

All the Zynq boards are ARM-based as far as I can tell.

Actually, teams have been able to run their robot code on personal laptops since 2019. WPILib natively targets Windows 32 and 64-bit, Linux x86, Linux ARM (roboRIO and Raspberry Pi), and macOS. Local unit testing is also supported (here’s my team’s tests, for example). I guess we’ve historically been bad at advertising our existing features. :slightly_smiling_face:

Given the current state of the world, we’re prioritizing a simulation frontend for 2021 as well as high-fidelity physics simulation using the recently merged model-based control libraries as a backend. It’ll support drivetrain, elevator, single-jointed arm, and flywheel mechanism simulation. The gist is in simulationPeriodic(), you give a mechanism simulation object motor voltages, run an update() function with a simulation timestep, then set the encoder values using that object’s position getters. One of the primary design goals was not having to touch existing teleop or autonomous code to facilitate a physics backend.

2 Likes

I was referring more to vendor libraries, which have been hit or miss in terms of supporting non-RIO builds of robot code.

I forgot FIRST had specified this before… Maybe this thread will become useful in 2025, then? :stuck_out_tongue:

1 Like

Yeah… there’s not much WPILib can do about that. Even moving the robot controller to x86 doesn’t help because you still have to do a build per OS (at a minimum, the C stdlib version is different, let alone any OS-specific libraries like the C++ runtime or winsock2). Java doesn’t have this problem, but it didn’t with ARM anyway because it’s all JVM bytecode.

We’ve wanted to have a central repository for vendordeps for a while now (GitHub - wpilibsuite/vendor-json-repo: WPILib Vendor JSON Repository (WIP)) that would build vendors’ code for them on all supported platforms, but that requires vendors being open source and being interested in using this setup in the first place.

1 Like

I’ve split and moved the discussion on the FRC Control System (the C&C stack specifically) to a new thread since it’s less relevant to this one, and could serve as a good discussion point on it’s own. Here ya go: [Split Topic] Opensource & the FRC Control System