What are the limitations to roboRIO modifications?

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

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