The issue has been raised that what happens if you have a ball in your robot but then have to e-stop or loose power.
What are teams thinking of doing incase this happens so you don’t choke your alliance?
I was thinking have a system that any robot can hit your robot in a way so that it forces the ball to leave the system. So maybe a rod that is able to contact the ball regardless of where it is in or on the robot.
While I do like Aerial Assist, this is something that kind of worries me about this game. Along with the autonomas shots missed, it’s now easier to pinpoint exactly whose fault it was that a match was lost and why.
Thia will be a great test of gracious Professionalism! Although if teams meet before a match like they should lots of problems can be avoided. If I had to as a driver I wouldn’t like a team to load a ball into their robot if they haven’t tested it or been successful with it.
I’m not sure this really solves the issue. If you load your robot, start autonomous, and your robot never establishes connection for some reason, how does this deadman’s switch work to release the ball so that your alliance can score?
Whatever your strategy is when you lose power or e-stop, ultimately your best bet is just to not lose power or get e-stopped. New batteries every match, make sure your robot and code are working well. The best medicine is preventative.
And then the power cable slips out of your router even though you taped and zip tied it, or there is interference from cell phones or whatever the kids are using these days, or the field malfunctions as it is known to do. I think the whole robot malfunctioning thing is (at least in part) out of your control. I’m probably just awful at making communications work though.
I for one think that robots moving without connection to the driver station constitutes a safety issue, as does FIRST. This is why the base robot project shipped with your choice of programming language tends to make the robot refuse to do anything without connection to the driver station, and a signal that it is in teleop or autonomous mode.
This would be good for the Q&A, maybe they could declare it field debris? Although how would a ref know to declare it as field debris if it is a result of power failure…?
Could they add a button to the alliance station to declare their current ball(s) field debris? That would add an interesting dynamic to the game (if they left the rule open ended).
If open ended, maybe an alliance could even do that to balls left from Autonomous.
If close ended though, let the rule be only for if the ball is trapped somehow.
Otherwise, the strongly robust robots might hold more weight in alliance selection…
Well, hypothetically, if you have 2 robots that can throw, none of the robots left available to pick can catch, and one of your robots has a multi-ball autonomous, the safest pick is a box (or ramp if you want to get fancy with loading) with a good drive-train under it.
The Driver’s Station (and FMS) are responsible for telling the robot if it is in teleop, in autonomous, or if it has been disabled. If there is no communication with the DS/FMS, the robot cannot move. Allowing the robot to move at all (electronically) in this situation would be a huge safety issue.
I think the point of the question also goes beyond communication issues. What if the robot loses power (due to a loose wire, a battery that fell out, or something else)? What if a hit from another robot resets your cRIO?
There are a number of problems that could cause your robot to become inoperable with a ball in its grasp.
This is what it should be like:
If the driver thinks the robot is jammed, either the robot is disabled by FMS, or that ball is invalidated if it ever exits the robot. That way, even if the robot is stuck, it can perform something else, like defense or if they add an endgame!