With software limitations being allowed to meet R6, at what point do inspectors say a hard-throwing robot passes inspection?
At what point do you feel a software-based solution is robust enough to be considered both safe and legal?
I mean as long as the team can explain it and demonstrate it, I feel like inspectors should have to take their word for it. At that point, its on the refs if the software limits works in actual matches. Based on this Q&A, we will probably just make it so we can only release when elevator and robot are not moving. That’s just simply encoders.
In the absence of other guidance, I’d go with either proximity or vision tracking of the goal, combined with a live demonstration on the practice field for both successful launches and successful aborts.
I hope teams realize that the result of the failure of software limits is a red card. From a strategic design point of view, I’d say relying on software is a bad call.
I would say that it depends on the robot, for me the key to R6 is “designed”. My initial question regarding R6 is going to be how does your hatch mechanism work. For a Ri3d style hook and loop grabber with pneumatic ejectors I would probably accept a simple declaration that it is controlled with software, and maybe a quick demo, with the obligatory reminder that the refs will be watching. I’m not worried that you could stick your arm 30" outside the frame perimeter 6’ in the air and spin like a dervish throwing the hatch across the arena, because at that point your concern is tipping the robot over and breaking things more than just throwing the hatch. Obviously, if during play it becomes a problem then further steps may need to be taken in order to pass a re-inspection.
On the other hand if you have a full court capable disc shooter, why you would build this is beyond me, I am going to be MUCH more skeptical of any purely software solution. I’m also going to ask why you brought your Ultimate Ascent robot to play Destination: Deep Space.
The bottom line is I’m not going to fail you for R6 just because you could conceivably, under some combination of circumstances, launch the hatch 37 inches.
If GDC thinks that hatch launching is a safety-critical rule, then allowing software to satisfy it is a huge miss. FRC software development is not sufficiently controlled or tested to meet a safety requirement.
If hatch launching is an operational “well if you tried pretty hard and don’t do it for strategic advantage in a match, that’s fine” rule, then the status quo is fine. That’s pretty much how software-limited frame extensions worked last year.
EDIT: From a practical perspective I do like Rangel’s recommendation of software lockouts during robot movements, and if we were a high-resource team implementing an elevator I’d do that even if we couldn’t mechanically launch past 36".
I’m not convinced this is the case. On one hand you’ve got R6 which is tested by inspectors, and they have to determine if they’re being fed smoke and mirrors. However, even if you get a faulty system past an inspector, if a referee sees you break G6 it’s a RED CARD. So it’s REALLY on a team to make dang sure their system works as advertised. RED CARDs are no laughing matter.
Exactly, if you rely on software limits, or any other kind of limits for that matter. And they fail, especially if they fail repeatedly or in a dangerous manner, the refs will consult with the LRI and you will have to be re-inspected. Likely your hatch mechanism will be disabled until it has been re-inspected, and that re-inspection will be much more particular about how you are preventing the hatch from being launched.