Retry if software crashes within the first 30 seconds of the trial

[hawkina]

Should a team be allowed to retry their run if some software crashes/doesn't properly start within the first 30 seconds of the run? How often would they be allowed to retry?

The goal would be to avoid teams not being able to start their challenge properly, however I am not sure if our timescope would allow for such a change.

[johaq]

One idea I had was, maybe the no touching of the robot rule is only enforced as soon as the robot enters. So it would go:

• Referee opens door -> timer starts
• Robot does not move so the team is still allowed to type, fix etc.
• Referee calls the normal 30 seconds rule
• If robot enters, then from now on no touching is allowed
• If robot still does not enter, usual end of the test

Potential problem: I might invite cheating. I.e. teams quickly typing in test information while the door is open.

[LoyVanBeek]

I have definitely seen this happen when teams were setting up for a person recognition test: quickly edit the default value for the number of ppl that were also being set up while the team was setting up the robot.

[mleonetti-kcl]

Given that our only constraint is time, I was thinking that we could measure time from the start until the crash (which we do anyway), let the team go back at the end of the queue (thus having some time to reboot or fix things) and at their next attempt they have the slot time minus whatever they used up to that point. For instance, slot time 5 min, crash after 30 seconds, at the next attempt it still counts as first slot, but with 4:30. They can do this indefinitely, until there is no time left in the slot, or they decide that there is not enough time to score. For instance, if there are 10 seconds left, they may give up the last 10 seconds and move on to the following slot. We can add a little penalty for context switch.

This way the arena has always someone using it, each team occupies the arena for the same total time, and teams can use the queuing time.

[LeroyR]

Given that our only constraint is time, I was thinking that we could measure time from the start until the crash (which we do anyway), let the team go back at the end of the queue (thus having some time to reboot or fix things) and at their next attempt they have the slot time minus whatever they used up to that point. For instance, slot time 5 min, crash after 30 seconds, at the next attempt it still counts as first slot, but with 4:30. They can do this indefinitely, until there is no time left in the slot, or they decide that there is not enough time to score. For instance, if there are 10 seconds left, they may give up the last 10 seconds and move on to the following slot. We can add a little penalty for context switch.

This way the arena has always someone using it, each team occupies the arena for the same total time, and teams can use the queuing time.

It is not only the time until stop/abort but also moving the robot out of the way - depending on the setup they may have to move across the arena.

Teams would also discuss/vote until they give the abort signal and you have to include some setup in front of the door as well as referees setting up the arena (and command generation depending on the task).

I would assume a quick 30sec Task restart/requene could take 3min of real time.
But adding all this as penalty time results in only a 2min slot for the 5min task which does not make much sense.

Also, managing teams is already hard as it is and i would try to make it easier for the refs - instead of adding more load by keeping track of who has how much time etc. This, from observing as well refereeing feels like the bigger hurdle.

More reasonable "just restart but keep the time running" caps the total time and mental work of refs but obviously results in less stuff happening inside the arenas.