add agressive and defensive ready positions depending on robot availability by JackyBloxx · Pull Request #2942 · HULKs/hulk

JackyBloxx · 2026-10-03T22:13:01Z

Why? What?

Currently every Robot number has fixed ready pose the problem: if there is no player with the number 3 there is no Robot to take the kickoff.
Whith this pr we now have a agressive and devensive player positioning and they replace each other if for example number 1,2 and 3 are on the field and 3 i penalized then in the next ready phase 2 would walk up to the kickoff position

Ideas for Next Iterations (Not This PR)

idea for the next iteration is that we have different ready poses for different number of player and not only a list where they fille each other spot up from top to bottom

How to Test

Test with 3 players how they walk in in ready if we have kickoff and not and with only player 1 and 2
player 2 should walk up to the kickoff position

…ility

knoellle · 2026-10-04T11:48:59Z

-    },
+    goalkeeper_pose: { position: [-4.2, 0.0], rotation: 0.0 },
+    striker_pose: { position: [-0.6, 0.0], rotation: 0.0 },
+    // Remaining players fill these support slots in descending player-number order.


Why are these comments different from the ones in the code?

knoellle · 2026-10-04T11:50:27Z

-While playing, behavior periodically creates a State message. It contains the
-player number, the robot pose, and the observed ball position and age when a
-ball is available. A message is sent only when the robot has a field pose, the
-send interval has elapsed, and the remaining game message budget is high
-enough.
+During Playing, behavior periodically creates a State message. It
+contains the player number, the robot pose, and the observed ball position and
+age when a ball is available. A message is sent only when the robot has a field
+pose, the send interval has elapsed, and the remaining game message budget is
+high enough.
+
+The interval is configured by `network.hsl_playing_state_message_send_interval`
+(300 ms by default). Received teammate states expire after
+`player_states_receiver.playing_maximum_age` (one second).
+
+Ready formation assignment uses the GameController lineup and sends no team
+State messages. GameController return messages are sent independently during
+Ready and the other states.

 Received teammate states provide the poses used for closest-to-ball selection
-and supporter positioning. Team communication can be absent or delayed, so the
-tree retains branches for simple operation, the last active robot, and missing
-ball information.
+and supporter positioning during Playing. Team communication can be absent or
+delayed, so the tree retains branches for simple operation, the last active
+robot, and missing ball information.


One sentence per line please.

knoellle · 2026-10-04T11:54:16Z

-While playing, behavior periodically creates a State message. It contains the
-player number, the robot pose, and the observed ball position and age when a
-ball is available. A message is sent only when the robot has a field pose, the
-send interval has elapsed, and the remaining game message budget is high
-enough.
+During Playing, behavior periodically creates a State message. It
+contains the player number, the robot pose, and the observed ball position and
+age when a ball is available. A message is sent only when the robot has a field
+pose, the send interval has elapsed, and the remaining game message budget is
+high enough.


Why this change?

knoellle · 2026-10-04T12:01:15Z

+## Ready Formations
+
+Ready uses static poses from `behavior_node.kickoff`, expressed in field
+coordinates (meters, with the own goal at negative x) and rotations in radians.


Specifying these units and coordinate frames here is redundant. We use these everywhere.

knoellle · 2026-10-04T12:04:55Z

+- On opponent or unknown kickoff, all field players fill `defensive_positions`
+  in the same order.
+
+The GameController's unpenalized lineup determines the active players.


"the GameController's lineup"?
what?

knoellle · 2026-10-04T12:24:20Z

+    let Some(ground_to_field) = blackboard.world_state.robot.ground_to_field else {
+        return Status::Failure;
+    };


Suggested change

let Some(ground_to_field) = blackboard.world_state.robot.ground_to_field else {

return Status::Failure;

};

let ground_to_field = blackboard.world_state.robot.ground_to_field.ok_or(Status::Failure)?

the function returns a Status and not a option of a status that is because i wrote it like that

But why? Try exists for a reason.

knoellle · 2026-10-04T12:25:31Z

+    let Some(kickoff_pose) = select_kickoff_pose(
+        &blackboard.world_state,
+        blackboard.parameters.goalkeeper.player_number,
+        &blackboard.parameters.kickoff,
+    ) else {
+        return Status::Failure;
+    };


Suggested change

let Some(kickoff_pose) = select_kickoff_pose(

&blackboard.world_state,

blackboard.parameters.goalkeeper.player_number,

&blackboard.parameters.kickoff,

) else {

return Status::Failure;

};

let kickoff_pose = select_kickoff_pose(

&blackboard.world_state,

blackboard.parameters.goalkeeper.player_number,

&blackboard.parameters.kickoff,

)?;

the function returns a Status and not a option of a status that is because i wrote it like that

knoellle · 2026-10-04T12:28:06Z

-        let kickoff_pose_in_field =
-            Pose2::from_parts(target_position, Orientation2::new(standard_pose.rotation));
+fn select_kickoff_pose(
+    world_state: &WorldState,


This is only used to short-circuit if we are penalized. Do that in the outer function pleasel.
Then you can drop the Option in the return type.

knoellle · 2026-10-04T12:32:20Z

+        kickoff_pose.position,
+        Orientation2::new(kickoff_pose.rotation),
+    );
+    let walk_and_stand = blackboard.parameters.walking.walk_and_stand;


We are already in a "walk and stand" context. Calling this variable "walk and stand" is not useful.
Please call it something with "parameters".

JackyBloxx added the cat:Behavior label Oct 3, 2026

github-project-automation Bot added this to Development Oct 3, 2026

JackyBloxx added 2 commits October 4, 2026 10:41

add agressive and devensive ready positions depending on robot avalab…

f4f0ca5

…ility

fix parameter

723bbeb

JackyBloxx force-pushed the better_ready_poses branch from e896dd5 to 723bbeb Compare October 4, 2026 08:41

JackyBloxx changed the title ~~add agressive and devensive ready positions depending on robot avalability~~ add agressive and defensive ready positions depending on robot availability Oct 4, 2026

JackyBloxx enabled auto-merge October 4, 2026 11:50

knoellle requested changes Oct 4, 2026

View reviewed changes

JackyBloxx force-pushed the better_ready_poses branch from 5ae9c3d to 723bbeb Compare October 4, 2026 14:20

Navigation Menu

add agressive and defensive ready positions depending on robot availability - #2942

add agressive and defensive ready positions depending on robot availability#2942
JackyBloxx wants to merge 2 commits into
HULKs:mainfrom
JackyBloxx:better_ready_poses

JackyBloxx commented Oct 3, 2026

Uh oh!

knoellle Oct 4, 2026

Uh oh!

knoellle Oct 4, 2026

Uh oh!

knoellle Oct 4, 2026

Uh oh!

knoellle Oct 4, 2026

Uh oh!

knoellle Oct 4, 2026

Uh oh!

knoellle Oct 4, 2026

Uh oh!

JackyBloxx Oct 4, 2026

Uh oh!

knoellle Oct 4, 2026

Uh oh!

knoellle Oct 4, 2026

Uh oh!

JackyBloxx Oct 4, 2026

Uh oh!

knoellle Oct 4, 2026

Uh oh!

Uh oh!

knoellle Oct 4, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

JackyBloxx commented Oct 3, 2026

Why? What?

Ideas for Next Iterations (Not This PR)

How to Test

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants