This thread reminded my of something strange I saw a tournament once.
A robot blew a brain port during a match and as a result, it was continuously driving in a circle. It wasn’t match affecting in any way so we just turned off the robot and scored the match as normal.
But what if this continues motor movement caused a game object to oscillate from a scored and unscored position. For example, a robot is driving a circle in possession of a mogo. The mogo is moving in and out of the alliance zone as a result. Would the goal be counted scored or unscored? Even more interesting, what if this single goal decided the outcome of the match? Or a ring conveyor is brushing past scored rings and momentarily descoring the whole stack?
The game manual doesn’t have much to say on this. G18 reads as follows:
It’s not over until it’s over. Scores will be calculated for all Matches immediately after the Match ends, once all Scoring Objects, Field Elements, and Robots on the field come to rest
However, it could take an hour before this robots battery dies and it comes to rest. It would seem that G3 (common sense) would overrule this time consuming approach.
Its an interesting hypothetical, and is unlikely to happen, but I wonder what would be done. I could see the call going either way leading to a very upset alliance. Each side could reasonably argue that if if G18 was followed to the strictest interpretation, there is a chance they deserve to win. Feel free to discuss this interesting dilemma.
Field control should disable the robot
At least that’s what I would think
As a last resort going and unplugging the battery is what I could do
If powering off the controller didn’t work
Usually there are other circumstances that make the determination easier (i.e. match affecting).
IMO: If something is repeatedly scored / unscored then the points are not a lock so I would not count them. I can’t think of a good counter argument but I’m sure someone will have one.
If robot still active, it could result in a DQ for team or alliance. Then, I would see if the robot can be safely removed and do damage control score best as possible.
It is not a case of field failure, but robot not responding to field control, so it is a team problem. No replay.
I might be missing it, but I don’t see any rule that actually warrants a DQ for failure to respond to field control. R27 requires that it be programmed to follow field control, but if it’s a hardware failure outside the team’s control it’s not a programming issue.
White screens are also not a field failure but a team problem, and that explicitly warrants a replay. Replays are also left to head referee/EP discretion, and the rules only list examples of cases where it should be used.
So if a motor failed such that it stopped responding to field control, and it caused the score to keep changing who won, I’d just say replay.
I feel like the, erm, spirited discussion with teams if it was ruled one way or another would take longer than just saying “ok, this is weird, we’re gonna replay the match” and running the match again.
As a Head Ref, I’m of the same general opinion as AlecMiller. If the robot is still clearly connected to the field, but not responding to any inputs, I’d be inclined to handle it like a white screen or other weirdness that’s out of the team’s control. I’d likely have some brave soul snag and unpower the bot then assess/repair, test, and replay.
I feel like the fact that it’s a weird edge case where nobody did anything wrong or could have done anything to prevent it and there’s no good answer either way is precisely the reason it should be a replay. The rules seem to give pretty wide latitude for what warrants a replay (which is good, in my opinion), and if you make a decision either way one alliance is going to come away feeling wronged.
I guess this probably warrants a Q&A at the start of next season in case this happens at an event.
Match replays are allowed, but rare. Match replays, i.e. playing a Match over again from its start, are at the discretion of the Event Partner and Head Referee, and will only be issued in the most extreme circumstances. Some example situations that may warrant a Match replay are as follows:
The EP/head ref have discretion for what requires a match replay, and the bulleted list are just examples of the kind of situation that warrants a replay.
I’d also argue that this is also similar to the bullet point
The field is reset before a score is determined
In this case, the field has been interfered with before the field has “come to rest” so a correct score could not be determined
I’d like to respond to this. Considering this behavior is caused by a combination of the motor’s firmware programming and spontaneous hardware damage, both of which are prohibited by rule from being modified by teams, how exactly is this a team problem? Moreover, how would you have teams mitigate this?
Well, let’s fit this around, how do you know the port malfunction is happening at all? Referees will see behavior of robot, Worlds, lots of field techs to diagnose. My gut response is due to behavior robot is what can be observed, not necessarily the cause of the behavior.
As others have said, good to post as a Q&A when it opens again - maybe there will be a new bullet point for this kind of behavior for match replays and guidance in the referee training videos on how to handle it next season.
The team illegally modified the firmware on both the controller and the brain, maybe the motor too, managed to make it past the firmware verification checks in inspection, managed to make it past the firmware check on the field brain, only to activate their super secret highly illegal firmware modification that could get them G1ed until the end of time that took hundreds of hours of work… in order to spin their robot in circles.
A port burned out at the wrong moment on the brain.
I’m going with #2.
My gut response is to go with the most likely explanation rather than to accuse a team of something as complex as modifying the V5 firmware.
There are other explanations, such as wiring mishaps. Should you replay the match due to poor cable management? That was what I was getting at with team responsibility. We had team blame loudly the event for having faulty towers, when in fact the explanation is their alliance partner had bent pins in their controller. Moreover, we’ve seen enough robots keep moving during cortex days when teams would break the retaining tab of the joystick controller.
So, long winded way to say it is not really something you can determine right there on the field and not everything deserves a replay.
Wiring would be pretty easy to check and verify vs a dead port. If a port dies, it is not the team’s responsibility; the GDC has made that very clear this year.
This is not the same circumstance as is being discussed in this topic
This is pretty easy to verify at the field.
It is pretty easy to verify all of this at the field in my experience, especially with V5’s very helpful field control status icons.
Of course. However, in extreme circumstances such as those described in the OP I am well within my rights to initiate a replay at my discretion.
If a motor stops communicating with the brain for any reason, the motor will perform a hardware reset after 1 second and return to the bootloader which will place the H-Bridge in brake mode. I checked this again today. So if a brain port is damaged and cannot communicate with a motor, the motor will stop.
score best as possible.