What are the limitations to roboRIO modifications?

[michaelwm]

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...)

[cgmv123]

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

[Hugo_Klepsch]

Originally Posted by cgmv123

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

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

[EricH]

Originally Posted by michaelwm

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...)

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.

[Thad House]

Originally Posted by EricH

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.

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.

[virtuald]

Originally Posted by Thad House

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.

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

[Joey1939]

Originally Posted by Hugo_Klepsch

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

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.

[cgmv123]

Originally Posted by Hugo_Klepsch

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

Originally Posted by Joey1939

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.

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.

[EricH]

Originally Posted by Joey1939

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.

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."

[SoftwareBug2.0]

Originally Posted by EricH

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."

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.

[Greg McKaskle]

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

[jhersh]

Originally Posted by SoftwareBug2.0

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.

Quote, please.