Real/extend kick transmission

[energy-in-joles]

Adds KICK_PERSIST_TIMESTEPS and KICK_COOLDOWN_TIMESTEPS.

1. The former keeps kicking HIGH in the transmission packet for that amount of timesteps. This is to combat packet loss and works because embedded only detects rising edge of kick transmission.
2. 2. The latter prevents kick from being actuated more than once in the cooldown period. This is to protect the hardware.

[Copilot]

Pull request overview

Extends the real robot serial command transmission so kick/chip commands can be “persisted” across multiple control timesteps to mitigate packet loss and rising-edge-only triggering on embedded firmware.

Changes:

• Add kick/chip persistence trackers in RealRobotController and decrement them each send cycle.
• Apply persistence when generating the command buffer (kick bit currently; chip intended).
• Add KICK_PERSIST_TIMESTEPS to global settings.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
utama_core/team_controller/src/controllers/real/real_robot_controller.py	Adds kick/chip persistence tracking and uses it during command buffer generation.
utama_core/config/settings.py	Introduces a new persistence duration constant for the real controller.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

[Copilot]

Kick/chip persistence can override safety stop commands: even if a stop/empty RobotCommand has kick/chip set to 0, the outgoing kicker_byte will still be set HIGH while the robot_id remains in _kick_tracker/_chip_tracker. If an emergency stop happens after a kick request but before embedded received the rising edge, the subsequent stop packets could create the rising edge and trigger a kick during shutdown. Consider adding an explicit way to clear/disable kick/chip persistence (e.g., a controller method to clear trackers, invoked by stop routines) or a hard override that forces kicker_byte=0 when the caller intends a stop packet.

[energy-in-joles]

this is a valid point. Right now there's no way to distinguish between an emergency stop and a regular empty_command(). We have to look into this in the future, but the risk right now is not high

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

utama_core/team_controller/src/controllers/real/real_robot_controller.py:218

• There is unreachable / redundant code at the end of _generate_command_buffer(): return packet at line 214 already exits the function, so the subsequent commented-out packet_str line and the second return packet can never run. Please remove the dead code to avoid confusion and to ensure future edits don’t accidentally go into the unreachable block.

        return packet

        # packet_str = " ".join(f"{byte:08b}" for byte in packet)

        return packet

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.