A repurposed roboRIO as a coprocessor? A bit on the expensive side if buying new, but there will be quite a few used ones in 2027…
I definitely hope NI will release a “coprocessor” version of the roboRIO image in 2027 (assuming a hard changeover to the MRC). Or even better, a fully unlocked one (including always-enabled PWM outputs, which of course wouldn’t be legal for competition) so teams can easily repurpose it for lab projects etc (CNC anyone?) without needing a DS. The roboRIO is really a nice robust platform with a lot of IO, and because it runs Linux, is much more reusable for those things than the cRIO was (I ran a homebuilt CNC off a repurposed cRIO for a few years, but it had to have a DS continuously connected…).
It does, but it also comes without the FIRST-specific FPGA functionality, which provides quadrature decoding, PWM encoding, etc. and it would take a fair amount of effort to rewrite all that from scratch. The cRIO was the same way—you could either get the FIRST-specific image with safety controls and useful FPGA functionality, or one without either (essentially a blank slate).
So would e-stopping in DS force the crio into essentially safety mode and disable the CNC as well? That’s actually kind of nice. You could potentially use the crio as a way to get a network camera feed if you attached it all to a radio system still. Then view/enable in DS. As well as any other custom IO…
Yes, but IMO the DS isn’t the right way to do an e-stop with a CNC. I would prefer to use a proper physical e-stop button hooked up to a couple of DIOs (use the NC path, send a pulse train on one DIO, and detect pulses on the other, e-stop if pulses not received).
But yes, camera, other custom IO, etc are all available. Several high-end CNCs actually use cRIOs as the controllers. In my case, I did a poor man’s version, where the cRIO didn’t control the steppers, but we used it for various other IO, coolant pump control, etc. It would be really awesome to write the stepper control pieces as well on a roboRIO. The logic isn’t crazy to do that (it would be even more awesome if NI open-sourced the FPGA code so that stuff could be implemented in the FPGA, but in C++ it probably wouldn’t be too bad to bit-bang the DIO to control steppers?).
I mean, there are plenty of examples online for how to do e.g. quadrature decoding. The only thing in the roboRIO FRC FPGA image that would require some custom work is the LED driver logic. The catch, of course, is that you need the LabVIEW FPGA module (and associated Xilinx licencing) to compile code for the FPGA.
Note there’s a lot of other useful code in the current FPGA than LED drivers and quadrature decoding. E.g. analog sampling/oversampling/averaging, analog triggers, duty cycle decoding, PWM encoding, auto-SPI for gyro integration, programmable signal routing between these things, the list goes on. In addition to implementing whatever of these things you might need for a particular application, it’s also necessary to implement the FPGA I/O mapping to external I/O (e.g. on-board devices), register mappings to software, etc. And all of these things have existing higher-level software interfaces via WPILib. Yes, it can be reimplemented, but using it as is, or modifying the existing design if needed, is a lot easier (and if using it as-is, you don’t need the FPGA dev tools/licenses).
That being said, @Thad_House did an open reimplementation of many of the roboRIO FPGA features a couple years ago. It does need LabVIEW FPGA license/dev tools to build it. GitHub - ThadHouse/OpenSourceRoboRIO
Is there any chance of NI releasing development resources for custom images and FPGA firmware? I realize this could mean putting time and money into a discontinued product the higher-ups at Emerson don’t even have any attachment to, but surely this documentation already exists for industrial customers, right?
You can load the stock images through MAX, and compile custom FPGA images with normal LabVIEW FPGA, it can target the roboRIO. That whole setup is properly documented.
What I mean are resources for running custom software and firmware on the roboRIO without needing NI tools. (Except for NI MAX or the imaging tool for RIO 1s) Most specifically, it would be nice to see a way to make custom firmware for the FPGA without buying a $5000 software suite.
I’m pretty sure the only way to program the FPGA on all NI products is through the entire software suite. Even industrial customers won’t get that. Especially not for free.
Most of those things I would consider trivial. ADC oversampling/decimation, for example, is something that I routinely implement on PICs without any programmable logic. Similarly, if you have an FPGA with a reasonably fast clock, duty cycle measurement is just a counter.
“Programmable signal routing” piques my interest; AFAIK, the FPGA implements some pretty independent peripherals, whose data are sent to the CPU. If any inputs affect outputs, they still get boomeranged through the CPU, or at least the AXI bus that the CPU is connected to.
Fundamentally, the roboRIO is just a Zynq with a bunch of glue logic attached. If you really want, you can create a Zynq project in Vivado and burn it to a roboRIO. I don’t think that really addresses your core concern, though, because the Xilinx tooling isn’t exactly cheap.
You can actually get a pretty long chain of objects internal into the FPGA, with the FRC image. I think the longest is.
Analog Input → Analog Trigger → Duty Cycle → Analog Trigger → Interrupt.
Basically, you can take an analog input, use an analog trigger to treat that analog signal as a digital signal, feed that into a duty cycle, use another analog trigger to get a digital signal out of that duty cycle, which you can then use to feed an interrupt.
It’s kind of wacky, but that all is dynamically configurable in the FPGA. Same with things like allowing any of the inputs to work for Encoders, Counters and Interrupts. That logic is actually fairly complex to get working right. And none of it touches the CPU.