Adding standby state before ready #153

ben47955 · 2024-05-02T01:43:15Z

No description provided.

ben47955 · 2024-05-02T12:23:45Z

Implementing #152

rules/forbidden_actions.tex

sseering · 2024-05-09T22:48:17Z

rules/game_process.tex

@@ -33,12 +33,15 @@ \subsection{Robot States}
    So while in the \texttt{unstiff} state the robot is not allowed to move in any fashion! After booting, the robots are in their \texttt{unstiff} state.
    Pressing the chest button once while in the \texttt{unstiff} state, permits the robot to stiffen its joints and return to the \texttt{initial} state, or a state as indicated by GameController.

-  \item[Initial.] The robots are not allowed to be moving in any fashion besides initially standing up.
-    Shortly pressing the chest button will switch the robot to the \texttt{penalized} state.
+    \item[Setup.] The robots are not allowed to be moving in any fashion besides initially standing up.


We introduce the setup state to give teams a guaranteed safe time where they are do any pre-game preparations. Arguably, this means that there should be little or no limits to robot movement in setup at all?

If we want to mention limits here, what comes to my mind is:

don't damage the field

don't hinder the other team

Though, these 2 were always kinda implicit, so I'm not sure if we should make the rules more complicated by mentioning them here.

Other opinions?

I think the issue is the initial was not well defined and I did the same mistake. I will update.

sseering · 2024-05-09T22:52:32Z

rules/game_process.tex

@@ -33,12 +33,15 @@ \subsection{Robot States}
    So while in the \texttt{unstiff} state the robot is not allowed to move in any fashion! After booting, the robots are in their \texttt{unstiff} state.
    Pressing the chest button once while in the \texttt{unstiff} state, permits the robot to stiffen its joints and return to the \texttt{initial} state, or a state as indicated by GameController.

-  \item[Initial.] The robots are not allowed to be moving in any fashion besides initially standing up.
-    Shortly pressing the chest button will switch the robot to the \texttt{penalized} state.
+    \item[Setup.] The robots are not allowed to be moving in any fashion besides initially standing up.


Furtherup in this section the number of game states needs updating:

Robots can be in \textit{eight} different \emph{primary} states ...

sseering · 2024-05-09T22:57:24Z

rules/game_process.tex

-  \item[Initial.] The robots are not allowed to be moving in any fashion besides initially standing up.
-    Shortly pressing the chest button will switch the robot to the \texttt{penalized} state.
+    \item[Setup.] The robots are not allowed to be moving in any fashion besides initially standing up.
+    Shortly pressing the chest button will switch the robot to the \texttt{penalized} state. 


Do we need to change the last sentence of the unstiff state?

Pressing the chest button once while in the \texttt{unstiff} state, permits the robot to stiffen its joints and return to the \texttt{initial} state, or a state as indicated by GameController

Other opinions?

sseering · 2024-05-09T23:05:03Z

rules/game_process.tex

@@ -75,6 +78,8 @@ \subsection{Robot States}
  \label{fig:robot_states}
 \end{figure}

+The referee must tell the GameController operator to switch to \texttt{initial} state once everyone is in place or that teams are falling under forfeit rule (see \cref{sec:forfeit}).


"The referee will announce the transition from the \texttt{setup} to \texttt{initial} ...."

Make the sentence simpler and consistent with the following text 2 sentences later.

sseering · 2024-05-09T23:06:50Z

rules/game_process.tex

@@ -75,6 +78,8 @@ \subsection{Robot States}
  \label{fig:robot_states}
 \end{figure}

+The referee must tell the GameController operator to switch to \texttt{initial} state once everyone is in place or that teams are falling under forfeit rule (see \cref{sec:forfeit}).


once everyone is in place or that teams are falling under forfeit rule (see \cref{sec:forfeit}).

I don't like introducing "once everyone is in place" here.

The head ref starts the game according to the schedule. If a team is not ready in time its their own fault. What happens if you are late/no-show is already detailed elsewhere.

I didn't like either. I will try to formulate that differently.

sseering · 2024-05-09T23:07:29Z

rules/game_process.tex

@@ -75,6 +78,8 @@ \subsection{Robot States}
  \label{fig:robot_states}
 \end{figure}

+The referee must tell the GameController operator to switch to \texttt{initial} state once everyone is in place or that teams are falling under forfeit rule (see \cref{sec:forfeit}).
+The referee should wait between 10 to 120 seconds before announcing the transition to \texttt{ready}. 


How about increasing the mininmum to 30 secs?

Other opinions?

I didn't want to introduce a different rule for CS and CC. I think this should be handled at referee meeting. I'm sure no one really gonna wait for 120 seconds doing nothing, but at the same time we don't want every initial state to be 30 seconds. I think this give more room to have the duration between 20-45 seconds.

If we handle this during the referee meeting, then we could not give any time in the rules. Keeping it simpler.

sseering · 2024-05-09T23:10:43Z

rules/game_process.tex

@@ -89,7 +94,8 @@ \subsection{Robot States}
 The colors corresponding to the game states are:
 \begin{itemize}
  \item \texttt{Unstiff}: Blue-Blinking
-  \item \texttt{Initial}: Off
+  \item \texttt{Setup}: Off
+  \item \texttt{Initial}: Cyan or Off


Don't make the rules more complicated by introducing options here. Just leave it as off (the head ref can see the gamestate on the GSV/TCM screen anyways)? Other opinions?

I make it optional for now because we are late in the season, but at the same time I think it's great to the option to differentiate every state on the robot. Suggestion for next years should be to make it mandatory.

I prefer "off", however in any case we should not introduce ambiguity into the rules. Please choose 1 option.

I agree with Stefan - let's go with one option. I vote for Cyan. I think it will be helpful to teams to distinguish the states.

sseering · 2024-05-09T23:12:55Z

rules/game_process.tex

@@ -75,6 +78,8 @@ \subsection{Robot States}
  \label{fig:robot_states}
 \end{figure}

+The referee must tell the GameController operator to switch to \texttt{initial} state once everyone is in place or that teams are falling under forfeit rule (see \cref{sec:forfeit}).


Should we explain here that both halves start with the setup state?

Previous sections already imply it, though the text is kinda vague. In the past the rules also didn't write more explicitly that halves start with initial.

opinions?

sseering · 2024-05-09T23:17:18Z

rules/game_process.tex

@@ -75,6 +78,8 @@ \subsection{Robot States}
  \label{fig:robot_states}
 \end{figure}

+The referee must tell the GameController operator to switch to \texttt{initial} state once everyone is in place or that teams are falling under forfeit rule (see \cref{sec:forfeit}).


We should use this change to formalize/define when human members of the playing teams need to leave the field/stop touching their robots.

In the past it varied wildly from team to team how late before initial human members of the playing teams where touching the robots. It should be somewhat consistent across all teams for fairness.

We could introduce a requirement like "The head referee announces setup time will be ending in 60 seconds. All human members of the playing teams must leave the field and stop interacting with participating robots manually and via network before initial."

Other opinions?

rvilling · 2024-05-10T13:16:03Z

It would be important to signal to readers of the rules that there would be a delay to be finalised in the referee meeting so that no teams write their code on the expectation of no delay.

________________________________ From: sseering ***@***.***> Sent: Friday 10 May 2024 09:29 To: RoboCup-SPL/Rules ***@***.***> Cc: Subscribed ***@***.***> Subject: [EXTERNAL] Re: [RoboCup-SPL/Rules] Adding state before initial (PR #153) *Warning* This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. @sseering commented on this pull request.

________________________________ In rules/game_process.tex<#153 (comment)>:

@@ -75,6 +78,8 @@ \subsection{Robot States}

\label{fig:robot_states} \end{figure} +The referee must tell the GameController operator to switch to \texttt{initial} state once everyone is in place or that teams are falling under forfeit rule (see \cref{sec:forfeit}). +The referee should wait between 10 to 120 seconds before announcing the transition to \texttt{ready}. If we handle this during the referee meeting, then we could not give any time in the rules. Keeping it simpler. — Reply to this email directly, view it on GitHub<#153 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA56EEXGTVFL35PAWIHJYMTZBSAOBAVCNFSM6AAAAABHC2Z4ICVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDANBZGU4DMNRTGM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

ben47955 · 2024-05-11T21:55:36Z

Hello, I made change to the PR

rvilling · 2024-05-12T20:44:04Z

rules/game_process.tex

@@ -31,14 +31,20 @@ \subsection{Robot States}
  \item[Unstiff.] It helps to facilitate a consistent and safe handling of the robots for remote competition.
    During any state, if all head buttons are pressed at least one second, the robot should move to a safe seated/crouched position and unstiffen all joints.
    So while in the \texttt{unstiff} state the robot is not allowed to move in any fashion! After booting, the robots are in their \texttt{unstiff} state.
-    Pressing the chest button once while in the \texttt{unstiff} state, permits the robot to stiffen its joints and return to the \texttt{initial} state, or a state as indicated by GameController.
+    Pressing the chest button once while in the \texttt{unstiff} state, permits the robot to stiffen its joints and return to the state indicated by GameController.


It looks like you're assuming there will always be a game controller already running. This isn't usually the case, e.g. if you arrive at a field before GC is running or if you don't want to run GC (E.g. to do calibration). The transition from a button press in unstiff seems undefined when there is no GC. Can you define what state the robot should land in if there is no game controller running (I assume "setup").

Yes, why not go into setup and then a second chest button press transitions to the penalized state (so no real change for the handling except the first reachable state via button interface is setup)

I believe that the text still assumes that the transition to calibration takes place from initial (which can only be reached via GC). Truthfully, I would have dealt with all this differently by leaving the initial state the way it originally was and inserting a new state between initial and ready to accept the ref signal - this would have resulted in fewest changes to robot code. If you want to continue in your current direction with the setup state, then I think you will also need to enable a transition from the setup state to calibration rather than from initial to calibration.

Having the new state before or after initial is just a matter of label as at the end the definition will be the same. To my opinion we should keep the current direction. At least I will update with this direction until we decided otherwise.

rvilling · 2024-05-12T20:44:45Z

rules/game_process.tex


-  \item[Initial.] The robots are not allowed to be moving in any fashion besides initially standing up.
+    \item[Setup.] The robots are free of any movement at teams convenience.


This wording is a bit unclear. Do you mean that the robots can move in the setup state or that they cannot?

They are allowed to move.

rvilling · 2024-05-12T20:45:03Z

rules/game_process.tex

+    This state is not limited in time and teams have access to the field.
+    The GameController will activate this state before \texttt{initial} (i.e at the beginning of a half and during a timeout).
+
+    \item[Initial.] The robots are not allowed to be moving in any fashion besides initially standing up.


"to be moving" --> "to move"

rvilling · 2024-05-12T20:49:51Z

rules/game_process.tex

    Shortly pressing the chest button will switch the robot to the \texttt{penalized} state.
+    The robots are preparing to receive a visual signal from the referee.  


Suggest rewording: In \texttt{iniitial}, the robots are awaiting a visual indication from the referee which signals the transition to \texttt{ready}.

rvilling · 2024-05-12T20:50:34Z

rules/game_process.tex


  \item[Ready.] In this state, the robots walk to their legal positions for kick-off (\cf \cref{sec:kick-off}) or a penalty kick (\cf \cref{sec:penalty_kick}).
    They remain in this state, until the head referee decides that there is no significant progress, up to a maximum of \qty{\KickOffAutoTime}{\second} for a kick-off and \qty{\PenaltyKickSetupTime}{\second} for a penalty kick.
    The GameController can activate sub-states for kick-off and penalty kicks.
+    The robot can only enter this state by either receiving a message from the GameController or detecting the visual signal or by receiving a message from a teammates who did.


Since there are 3 possibilities, delete "either"

rvilling · 2024-05-12T20:52:31Z

rules/game_process.tex

+At the scheduled time, the referee will announce that the transition from the \texttt{setup} to \texttt{initial} will be executed 60 seconds later.
+The referee shall call ``Initial in 60 seconds''. 
+The GameController will execute this transition automatically once the time has passed. 
+If both teams have left the field, the head referee can announce the transition earlier by calling ``Initial''.


This sounds odd. I guess you are referring to the human team members and that the robot team members are on the field. Rewording needed I think.

rvilling · 2024-05-12T20:53:35Z

rules/game_process.tex

+
+
+The referee should wait a random time between 10 to 120 seconds before announcing the transition to \texttt{ready}. 
+Teams should expect a different time for every time they have to effectuate the transition from the \texttt{initial} to \texttt{ready}.
 The referee will announce the transition from the \texttt{initial} to \texttt{ready} state by raising both hands over its head. The referee will wear red gloves \footnote{Teams are encouraged to not rely on the red gloves as they could be removed in a following year.}.


"by raising both hands over its head" --> "by raising both hands over their head"

rules/forbidden_actions.tex

ben47955 · 2024-05-15T20:09:51Z

Change are ready to by reviewed

sseering · 2024-05-13T21:27:31Z

rules/game_process.tex


-  \item[Initial.] The robots are not allowed to be moving in any fashion besides initially standing up.
+    \item[Setup.] The robots are free of any movement at teams convenience.


They are allowed to move.

sseering · 2024-05-22T14:20:56Z

rules/game_process.tex

@@ -89,7 +94,8 @@ \subsection{Robot States}
 The colors corresponding to the game states are:
 \begin{itemize}
  \item \texttt{Unstiff}: Blue-Blinking
-  \item \texttt{Initial}: Off
+  \item \texttt{Setup}: Off
+  \item \texttt{Initial}: Cyan or Off


I prefer "off", however in any case we should not introduce ambiguity into the rules. Please choose 1 option.

sseering · 2024-05-22T15:01:46Z

rules/game_process.tex

-  \item[Initial.] The robots are not allowed to be moving in any fashion besides initially standing up.
+    \item[Setup.] The robots are free to move at teams convenience and human are allowed to interact with the robots. 
+    This state is not limited in time and teams have access to the field.
+    The GameController will activate this state before \texttt{initial} (i.e at the beginning of a half and during a timeout).


I think we should have a setup phase only before every half and not at the end of timeout. This was also discussed when we talked about GC implementation.

Everything a team could do during setup they can do during timeout. So we don't need a setup at the end of a timeout.

Which state is then active during timeout?

In the GC "timeout" is a phase. Having the robot in "setup" don't contradict that. Plus, it add consistency to have a setup before every initial. But I'm open to discuss that.

In the GC "timeout" is a phase.

In the message that is sent to the robots, yes. But in the GameController's internal logic, it is a state on the same level as Initial/Ready/Set/.... This is because the combination Penalty Shoot-out + Timeout is possible, but up to now, combinations of Timeout with any other state than Initial weren't possible.

What if we keep Timeout on GC side, but send Setup to robot ? Robot should recover the same way from a timeout than the beginning of a half. Any opinions?

You would still have to switch to sending Initial to the robots so they look for the referee again. If the Initial state starts only once the timeout is over, games would be delayed even more.

I'm not sure how this would add more delay ? Robot should be ready to play before the end of the Setup. ( There the edge case of prematurely called end of the timeout as it would require human input anyway I would say it's fine)

If the transition to Initial happens after full 5 minutes and then there are up to 2 minutes of Initial on top, this is longer than before.

Anyway, I have modified the GameController so that a Timeout is equivalent rather to Setup than to Initial, but the Timeout timer keeps running after the switch to Initial. The timer is not affected by this. The penalty shoot-out also starts with setup now.

There are still a couple of edge cases around request for pick-up to resolve for me, especially when you can pick-up a player without getting a timer, and how the timer should be set when the player already has a Forbidden Motion in Initial penalty (this is currently exploitable).

This 2 minutes is a different discussions. In fact, it's between 10 sec and 2 minutes. This is the drawback to have a more predictable signal. This delay only start when robots are ready to position. I'm still not sure I understand what we call/do before Initial affect this.
Plus, why my last commit, initial can start sooner to save couple seconds.

If others TC express their opinions in this way, we can also remove this 10/120 secs and only rely on teams to not predict the signal by others means than visual.

sseering · 2024-05-22T15:04:09Z

rules/game_process.tex

-The referee will announce the transition from the \texttt{initial} to \texttt{ready} state by raising both hands over its head. The referee will wear red gloves \footnote{Teams are encouraged to not rely on the red gloves as they could be removed in a following year.}.
+At the scheduled time, the referee will announce that the transition from the \texttt{setup} to \texttt{initial} will be executed 60 seconds later.
+The referee shall call ``Initial in 60 seconds''. 
+The GameController will execute this transition automatically once the time has passed. 


I don't think we should introduce a GC countdown here. There might be discussion between teams and the headref or GC operator.

The transition from setup to inital simply happens when the GC decides.

This was your suggestion in another comment unless I misunderstand. I liked that because it would help to have matchs starting in time and make more clear the time window teams are having to call a timeout.

What we can do is keeping the countdown but the transition to be done manually by the GC operator.

Does the suggestion of the countdown mean that the GameController should know when the match starts?

I was thinking to rely on the referee to start on time. It would add so many issues if let the GC starting match without manual input.

OK, I was reading this as if the countdown (even without automatic transition, which I consider a bad idea, too) should be displayed by the GC. If it's just the referee looking at a clock and announcing the time, it's fine.

Just to be clear I mean the operator to start the initial countdown manually ( 60s before the transition to initial). The current discussion tends to also trigger the transition manually which I will update.
There already a 1 minutes rules and 2 minutes rules about initial kick-off. This is just a matter of better defining when this start (Section 3.5). For a matter of clarity the GC should display this countdown.

rvilling · 2024-05-22T15:19:53Z

rules/game_process.tex

+If all humans from playing teams have left the field, the head referee can announce the transition earlier by calling ``Initial''.
+
+
+The referee should wait a random time between 10 to 120 seconds before announcing the transition to \texttt{ready}. 


Since the referee must not signal until the initial state is active, I suggest:

"Once the game controller operator has confirmed the initial state, the referee should wait a random time..."

rvilling · 2024-05-22T15:22:03Z

rules/game_process.tex

+
+
+The referee should wait a random time between 10 to 120 seconds before announcing the transition to \texttt{ready}. 
+Teams should expect a different time for every time they have to effectuate the transition from the \texttt{initial} to \texttt{ready}.


"Teams should expect that the delay before the referee signals the transition from \texttt{initial} to \texttt{ready} will be different every time."

rvilling · 2024-05-22T15:25:35Z

rules/game_process.tex

+The referee should wait a random time between 10 to 120 seconds before announcing the transition to \texttt{ready}. 
+Teams should expect a different time for every time they have to effectuate the transition from the \texttt{initial} to \texttt{ready}.
+The referee will announce the transition from \texttt{initial} to \texttt{ready} state by raising both hands over their head.
+The referee will wear red gloves \footnote{Teams are encouraged to not rely on the red gloves as they could be removed in a following year.}.
 The referee must stand on the opposite side of the technical area behind the touchline and at the height of the halfway line.


"at the height of" --> "in line with"

ahasselbring · 2024-05-24T11:01:09Z

The GameController knows the setup state now (when built from the current master). Maybe you can check whether it is compatible with your intentions?

rules/game_process.tex

ahasselbring · 2024-06-04T13:41:47Z

rules/game_process.tex

  \item[Ready.] In this state, the robots walk to their legal positions for kick-off (\cf \cref{sec:kick-off}) or a penalty kick (\cf \cref{sec:penalty_kick}).
    They remain in this state, until the head referee decides that there is no significant progress, up to a maximum of \qty{\KickOffAutoTime}{\second} for a kick-off and \qty{\PenaltyKickSetupTime}{\second} for a penalty kick.
    The GameController can activate sub-states for kick-off and penalty kicks.
+    The robot can only enter this state by receiving a message from the GameController or detecting the visual signal or by receiving a message from teammates who did.


Is this sentence really required? It's missing the whistle for the transition after a goal.

Yes as there nothing else preventing educated guess of the signal without visual recognition. I will add the whistle to the list or see if I can do otherwise.

ahasselbring · 2024-06-05T10:23:05Z

rules/game_process.tex

  \item[Ready.] In this state, the robots walk to their legal positions for kick-off (\cf \cref{sec:kick-off}) or a penalty kick (\cf \cref{sec:penalty_kick}).
    They remain in this state, until the head referee decides that there is no significant progress, up to a maximum of \qty{\KickOffAutoTime}{\second} for a kick-off and \qty{\PenaltyKickSetupTime}{\second} for a penalty kick.
    The GameController can activate sub-states for kick-off and penalty kicks.
+    The robot can only enter this state by : 


I'm still not convinced of this enumeration. Estimating the state of the game can integrate a lot of cues. For instance, why should it be illegal to enter the ready state when you (visually) observe other players entering the pitch, or (after a goal) when the ball is observed to have moved in a goal and subsequently removed? Humans certainly do this to disambiguate the state of the game and don't rely only on a sound or a signal.

I agree that there are "outside-the-box" things (such as comparing the robot's clock with the scheduled start of the match, or waiting a fixed time and such) that shouldn't be done. But my guess is that those are bad ideas that don't work well anyway. And otherwise, this is just a reiteration of the general "please don't cheat" principle.

The purpose of the visual signal rule is to evaluate the league capacity to do that and I would like to avoid bias by others strategy. I agree with what you said and this would need to be relaxed once more signal are added. I will think about that today. Meanwhile, others opinions/suggestion are welcome.

I removed the list. I was hesitating to move the meaning as exit condition of Visual state, but with all the instruction about the visual signal, let say strategy not involving the visual signal at all would be against the spirits of the game.

rules/forbidden_actions.tex

rules/game_process.tex

ahasselbring · 2024-06-11T11:53:06Z

Does the TC have an opinion whether it should be possible to take a timeout in the new state?

ben47955 · 2024-06-11T22:42:39Z

Does the TC have an opinion whether it should be possible to take a timeout in the new state?

I don't really see how we can forbid them while still allowing them in Ready. But we will have a word on that.

ben47955 · 2024-06-11T23:12:38Z

Name of the state updated again along others comments

ahasselbring · 2024-06-13T09:41:51Z

Does the TC have an opinion whether it should be possible to take a timeout in the new state?

I don't really see how we can forbid them while still allowing them in Ready. But we will have a word on that.

That makes sense.

Adding state before initial

96e774e

Add color to differentiate setup and initial state

cd2e0f3

sseering reviewed May 9, 2024

View reviewed changes

Implement the suggested change

03c94b9

ben47955 force-pushed the Add-state-before-initial branch from 4361219 to 03c94b9 Compare May 11, 2024 22:48

rvilling reviewed May 12, 2024

View reviewed changes

arnemoos reviewed May 13, 2024

View reviewed changes

rules/forbidden_actions.tex Outdated Show resolved Hide resolved

ben47955 added 2 commits May 13, 2024 22:22

Saving progress

005b301

Remove a word

41b942c

sseering reviewed May 22, 2024

View reviewed changes

rvilling reviewed May 22, 2024

View reviewed changes

arnemoos reviewed May 25, 2024

View reviewed changes

rules/game_process.tex Outdated Show resolved Hide resolved

arnemoos reviewed May 25, 2024

View reviewed changes

rules/game_process.tex Outdated Show resolved Hide resolved

arnemoos reviewed May 25, 2024

View reviewed changes

rules/game_process.tex Outdated Show resolved Hide resolved

ben47955 added 2 commits May 28, 2024 21:26

Minor wording correction

2fa2e63

Relax the process to transition to initial

bdc222a

ahasselbring reviewed Jun 4, 2024

View reviewed changes

ben47955 force-pushed the Add-state-before-initial branch 2 times, most recently from f9f07d9 to ae484eb Compare June 4, 2024 23:28

Revert setup state- New visual state created

cc48bc4

ben47955 force-pushed the Add-state-before-initial branch from ae484eb to cc48bc4 Compare June 4, 2024 23:31

ahasselbring reviewed Jun 5, 2024

View reviewed changes

ben47955 added 3 commits June 5, 2024 16:44

Remove list of condition to enter Ready

d13908c

Remove draft and edit Rule change list

2abdbc9

Explicitly exclude CS from visual

d62dad9

ben47955 changed the title ~~Adding state before initial~~ Adding visual state before ready Jun 10, 2024

arnemoos requested changes Jun 11, 2024

View reviewed changes

rules/forbidden_actions.tex Outdated Show resolved Hide resolved

rules/game_process.tex Outdated Show resolved Hide resolved

rules/game_process.tex Outdated Show resolved Hide resolved

rules/game_process.tex Outdated Show resolved Hide resolved

rules/game_process.tex Show resolved Hide resolved

ben47955 changed the title ~~Adding visual state before ready~~ Adding standby state before ready Jun 11, 2024

Update the state name again

309d3ba

ben47955 force-pushed the Add-state-before-initial branch from 12fff7f to 309d3ba Compare June 11, 2024 23:11

arnemoos approved these changes Jun 13, 2024

View reviewed changes

arnemoos merged commit 5ec6d26 into RoboCup-SPL:master Jun 13, 2024


		\item[Initial.] The robots are not allowed to be moving in any fashion besides initially standing up.
		\item[Setup.] The robots are free of any movement at teams convenience.

		Shortly pressing the chest button will switch the robot to the \texttt{penalized} state.
		The robots are preparing to receive a visual signal from the referee.

		If all humans from playing teams have left the field, the head referee can announce the transition earlier by calling ``Initial''.


		The referee should wait a random time between 10 to 120 seconds before announcing the transition to \texttt{ready}.



		The referee should wait a random time between 10 to 120 seconds before announcing the transition to \texttt{ready}.
		Teams should expect a different time for every time they have to effectuate the transition from the \texttt{initial} to \texttt{ready}.

Adding standby state before ready #153

Adding standby state before ready #153

Conversation

ben47955 commented May 2, 2024

ben47955 commented May 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sseering May 9, 2024 • edited Loading

Choose a reason for hiding this comment

rvilling commented May 10, 2024 via email

ben47955 commented May 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ben47955 commented May 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahasselbring commented May 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahasselbring commented Jun 11, 2024

ben47955 commented Jun 11, 2024

ben47955 commented Jun 11, 2024

ahasselbring commented Jun 13, 2024

sseering May 9, 2024 •

edited

Loading