What are the limitations to roboRIO modifications?
 

What are the limitations for modifications we can perform on the roboRIO, so that we stay competition legal?

Some examples include:

• Changing the OS
• Building and deploying a custom JRE
• Installing linux packages (node.js, ex...)

Re: What are the limitations to roboRIO modifications?
 

R45 says the RoboRIO must use image version FRC_2015_v23 and firmware 2.1.0f3

Re: What are the limitations to roboRIO modifications?
 

I think the OP was referring to the root cause that led the FRC rule makers to make such a rule.

Re: What are the limitations to roboRIO modifications?
 

You can do exactly what the Manual says you can. This would be R45 (image and firmware that MUST be used) and R55 (programming user programmable code).

Conversely, you are NOT allowed to make any other changes (if you want to stay competition legal). I would regard a different OS as being a change, and an illegal one. Not that I'd know how to spot it, but I'm sure someone would.

Note, though, that I'm only commenting on legality, not on ability to do something.

Re: What are the limitations to roboRIO modifications?
 

Since the kernel comes in the image, I would agree with this. Changing the OS and the kernel would not be allowed.

For installing packages, and recompiling the JDK, I would say both of those are perfectly fine. The JDK does not come with the image, so if doing either of those things was illegal, both the Python and Java implementations would be illegal, and we know that both of those are legal.

Re: What are the limitations to roboRIO modifications?
 

I suspect loading a new kernel module would not be considered illegal.

Re: What are the limitations to roboRIO modifications?
 

It's all about safety and fairness. FRC requires everyone to use the same base software so that the field can control your robot. This way everyone starts autonomous at the same time and such. Also, it gives the field the ability to e-stop the robot that jumps over the guardrail.

Re: What are the limitations to roboRIO modifications?
 

FIRST (and really everyone that ever comes into the proximity of your robot) needs to know that when your robot is disabled/emergency stopped, nothing is going to actuate. That function is hard-coded into the specified firmware and image and can't be overrode by any user code. Using a different firmware could potentially allow the robot to move when disabled/emergency stopped, which is a major safety issue for what I hope are obvious reasons.

Re: What are the limitations to roboRIO modifications?
 

And there's another factor. It's a lot easier to troubleshoot 40+ "identical" systems (same basic layout, etc) than it is to troubleshoot 40+ non-identical systems. Even 1 and 39+ isn't as easy as 40+, because that one could cause all sorts of problems (potentially).


The last thing you want is for your robot to be having comm issues, everybody else not having them, and the CSA going "Why did you change X item? It wasn't supposed to be changed."

Re: What are the limitations to roboRIO modifications?
 

This is why it's a good idea to design systems with minimal interfaces. Unfortunately, we have exactly the opposite, and beta testers who were told that their purpose was only to find bugs, not to question design descisions. :(

Re: What are the limitations to roboRIO modifications?
 

The system is open, but has a simple reset. If you modify the roboRIO and see issues, reimage it. This is actually quite a bit easier than what can happen to your DS or programming laptop.

Greg McKaskle

Re: What are the limitations to roboRIO modifications?
 

Quote, please.