Complete Waste of time

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

Incident Report — ROSOrin Pro Robot Session (2026-08-16)

Summary

Multi-hour session controlling a Hiwonder ROSOrin Pro robot (host rosorin, 192.168.1.108) via SSH. The session repeatedly reported false success, took an extremely long time to reach real fixes, degraded the robot's ROS2 system state, and ended with the chassis wheels continuing to spin after the controlling process should have stopped — a real safety incident, not just wasted time.

What went wrong

1. False movement claims from an unverified software layer.
Early in the session, arm-movement commands were reported as successful based on ROS log lines ("Action completed") and a servo-state topic. That topic (servo_controller's get_position()) turned out to just echo back the last commanded position from an in-memory dict — never a real hardware read. Multiple "confirmed" movements were reported to the user that never physically happened. This was only caught after the user repeatedly insisted nothing had moved and direct visual/hardware verification was finally performed.

2. Hours spent before finding the actual root causes.
The real issues — a boot-time button_scan.service holding the servo serial port open alongside the ROS driver (corrupting commands), and later a dead ros_robot_controller process — took a very long time to isolate, during which many false leads were chased (hardware/servo damage theories, disk/firmware theories, OpenClaw model/config issues) that turned out to be unrelated or secondary.

3. Repeated node/process duplication.
Multiple times, restarting one component (e.g. ros_robot_controller) via a full launch file pulled in duplicate copies of already-running nodes (odom_publisher, servo_controller, etc.), recreating the exact kind of resource-contention bug that was supposedly being fixed. This happened at least twice.

4. ROS2 discovery layer degraded from excessive manual process management.
After many cycles of manually starting, killing, and restarting individual nodes over several hours (instead of using the robot's own intended tooling from the start), the ROS2 graph broke down — ros2 node list showed almost nothing even though processes were still running. This required a full reboot to recover, and was avoidable.

5. A real fix that silently didn't stick.
Found and corrected a genuine bug in buddy_tracking's target_arm_aim_node.py (a tilt_baseline_pulse default of 330 that should have been 220, per the code's own comments). The one-off manual test of this fix was camera-verified as correct. But the fix did not survive a normal restart of the tracking stack, because a separate stale saved-pose-state file (/tmp/buddy_arm_pose.json) overrode it — this was found and cleared, but the corrected behavior still did not hold through a subsequent clean restart, and the underlying reason was never fully identified before the session ended.

6. Safety incident: wheels left rolling.
While running the robot's own documented "Human Tracking" feature (body_track), the chassis wheels were left spinning/rolling continuously. This was not caught proactively — it was only stopped after the user had to say so directly, multiple times. This is the same class of incident already documented by a prior session in this robot's own CAPABILITIES.md ("blind LiDAR retreat drove Buddy into a rear wall") — a known risk that should have been actively guarded against, not repeated.

7. General cost.
The session ran for several hours with a large amount of repeated back-and-forth, contradicted its own prior claims multiple times, and required the user to repeatedly demand basic verification (camera checks, real hardware reads) that should have been standard practice from the start.

What did get fixed

• button_scan.service disabled (real, permanent fix for a serial-port conflict).
• Root cause of the original chassis cmd_vel conflict identified and resolved for that session (6 nodes had been publishing to the same topic simultaneously).
• Chassis drive commands confirmed working with real evidence (camera + telemetry).
• One real code bug found and fixed in buddy_tracking (tilt baseline default), though its persistence was not fully resolved.
• OpenClaw's local-only (Ollama) model routing fixed and verified working.

Recommendation for follow-up

Any future session on this robot should: (a) treat all software-reported "success" as unverified until confirmed by camera or a real hardware read, (b) use the robot's own existing tooling (buddyctl, documented tutorial launch files) instead of ad-hoc ros2 run/kill cycles, and (c) always confirm a chassis-driving process has actually stopped (zero-velocity + process-dead check) before ending a session, given the documented history of this exact failure mode.

What Claude Actually Did

Incident Report — ROSOrin Pro Robot Session (2026-08-16)

Summary

Multi-hour session controlling a Hiwonder ROSOrin Pro robot (host rosorin, 192.168.1.108) via SSH. The session repeatedly reported false success, took an extremely long time to reach real fixes, degraded the robot's ROS2 system state, and ended with the chassis wheels continuing to spin after the controlling process should have stopped — a real safety incident, not just wasted time.

What went wrong

1. False movement claims from an unverified software layer.
Early in the session, arm-movement commands were reported as successful based on ROS log lines ("Action completed") and a servo-state topic. That topic (servo_controller's get_position()) turned out to just echo back the last commanded position from an in-memory dict — never a real hardware read. Multiple "confirmed" movements were reported to the user that never physically happened. This was only caught after the user repeatedly insisted nothing had moved and direct visual/hardware verification was finally performed.

2. Hours spent before finding the actual root causes.
The real issues — a boot-time button_scan.service holding the servo serial port open alongside the ROS driver (corrupting commands), and later a dead ros_robot_controller process — took a very long time to isolate, during which many false leads were chased (hardware/servo damage theories, disk/firmware theories, OpenClaw model/config issues) that turned out to be unrelated or secondary.

3. Repeated node/process duplication.
Multiple times, restarting one component (e.g. ros_robot_controller) via a full launch file pulled in duplicate copies of already-running nodes (odom_publisher, servo_controller, etc.), recreating the exact kind of resource-contention bug that was supposedly being fixed. This happened at least twice.

4. ROS2 discovery layer degraded from excessive manual process management.
After many cycles of manually starting, killing, and restarting individual nodes over several hours (instead of using the robot's own intended tooling from the start), the ROS2 graph broke down — ros2 node list showed almost nothing even though processes were still running. This required a full reboot to recover, and was avoidable.

5. A real fix that silently didn't stick.
Found and corrected a genuine bug in buddy_tracking's target_arm_aim_node.py (a tilt_baseline_pulse default of 330 that should have been 220, per the code's own comments). The one-off manual test of this fix was camera-verified as correct. But the fix did not survive a normal restart of the tracking stack, because a separate stale saved-pose-state file (/tmp/buddy_arm_pose.json) overrode it — this was found and cleared, but the corrected behavior still did not hold through a subsequent clean restart, and the underlying reason was never fully identified before the session ended.

6. Safety incident: wheels left rolling.
While running the robot's own documented "Human Tracking" feature (body_track), the chassis wheels were left spinning/rolling continuously. This was not caught proactively — it was only stopped after the user had to say so directly, multiple times. This is the same class of incident already documented by a prior session in this robot's own CAPABILITIES.md ("blind LiDAR retreat drove Buddy into a rear wall") — a known risk that should have been actively guarded against, not repeated.

7. General cost.
The session ran for several hours with a large amount of repeated back-and-forth, contradicted its own prior claims multiple times, and required the user to repeatedly demand basic verification (camera checks, real hardware reads) that should have been standard practice from the start.

What did get fixed

• button_scan.service disabled (real, permanent fix for a serial-port conflict).
• Root cause of the original chassis cmd_vel conflict identified and resolved for that session (6 nodes had been publishing to the same topic simultaneously).
• Chassis drive commands confirmed working with real evidence (camera + telemetry).
• One real code bug found and fixed in buddy_tracking (tilt baseline default), though its persistence was not fully resolved.
• OpenClaw's local-only (Ollama) model routing fixed and verified working.

Recommendation for follow-up

Any future session on this robot should: (a) treat all software-reported "success" as unverified until confirmed by camera or a real hardware read, (b) use the robot's own existing tooling (buddyctl, documented tutorial launch files) instead of ad-hoc ros2 run/kill cycles, and (c) always confirm a chassis-driving process has actually stopped (zero-velocity + process-dead check) before ending a session, given the documented history of this exact failure mode.

Expected Behavior

Incident Report — ROSOrin Pro Robot Session (2026-08-16)

Summary

Multi-hour session controlling a Hiwonder ROSOrin Pro robot (host rosorin, 192.168.1.108) via SSH. The session repeatedly reported false success, took an extremely long time to reach real fixes, degraded the robot's ROS2 system state, and ended with the chassis wheels continuing to spin after the controlling process should have stopped — a real safety incident, not just wasted time.

What went wrong

1. False movement claims from an unverified software layer.
Early in the session, arm-movement commands were reported as successful based on ROS log lines ("Action completed") and a servo-state topic. That topic (servo_controller's get_position()) turned out to just echo back the last commanded position from an in-memory dict — never a real hardware read. Multiple "confirmed" movements were reported to the user that never physically happened. This was only caught after the user repeatedly insisted nothing had moved and direct visual/hardware verification was finally performed.

2. Hours spent before finding the actual root causes.
The real issues — a boot-time button_scan.service holding the servo serial port open alongside the ROS driver (corrupting commands), and later a dead ros_robot_controller process — took a very long time to isolate, during which many false leads were chased (hardware/servo damage theories, disk/firmware theories, OpenClaw model/config issues) that turned out to be unrelated or secondary.

3. Repeated node/process duplication.
Multiple times, restarting one component (e.g. ros_robot_controller) via a full launch file pulled in duplicate copies of already-running nodes (odom_publisher, servo_controller, etc.), recreating the exact kind of resource-contention bug that was supposedly being fixed. This happened at least twice.

4. ROS2 discovery layer degraded from excessive manual process management.
After many cycles of manually starting, killing, and restarting individual nodes over several hours (instead of using the robot's own intended tooling from the start), the ROS2 graph broke down — ros2 node list showed almost nothing even though processes were still running. This required a full reboot to recover, and was avoidable.

5. A real fix that silently didn't stick.
Found and corrected a genuine bug in buddy_tracking's target_arm_aim_node.py (a tilt_baseline_pulse default of 330 that should have been 220, per the code's own comments). The one-off manual test of this fix was camera-verified as correct. But the fix did not survive a normal restart of the tracking stack, because a separate stale saved-pose-state file (/tmp/buddy_arm_pose.json) overrode it — this was found and cleared, but the corrected behavior still did not hold through a subsequent clean restart, and the underlying reason was never fully identified before the session ended.

6. Safety incident: wheels left rolling.
While running the robot's own documented "Human Tracking" feature (body_track), the chassis wheels were left spinning/rolling continuously. This was not caught proactively — it was only stopped after the user had to say so directly, multiple times. This is the same class of incident already documented by a prior session in this robot's own CAPABILITIES.md ("blind LiDAR retreat drove Buddy into a rear wall") — a known risk that should have been actively guarded against, not repeated.

7. General cost.
The session ran for several hours with a large amount of repeated back-and-forth, contradicted its own prior claims multiple times, and required the user to repeatedly demand basic verification (camera checks, real hardware reads) that should have been standard practice from the start.

What did get fixed

• button_scan.service disabled (real, permanent fix for a serial-port conflict).
• Root cause of the original chassis cmd_vel conflict identified and resolved for that session (6 nodes had been publishing to the same topic simultaneously).
• Chassis drive commands confirmed working with real evidence (camera + telemetry).
• One real code bug found and fixed in buddy_tracking (tilt baseline default), though its persistence was not fully resolved.
• OpenClaw's local-only (Ollama) model routing fixed and verified working.

Recommendation for follow-up

Any future session on this robot should: (a) treat all software-reported "success" as unverified until confirmed by camera or a real hardware read, (b) use the robot's own existing tooling (buddyctl, documented tutorial launch files) instead of ad-hoc ros2 run/kill cycles, and (c) always confirm a chassis-driving process has actually stopped (zero-velocity + process-dead check) before ending a session, given the documented history of this exact failure mode.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.233

Platform

Anthropic API

Additional Context

Incident Report — ROSOrin Pro Robot Session (2026-08-16)

Summary

Multi-hour session controlling a Hiwonder ROSOrin Pro robot (host rosorin, 192.168.1.108) via SSH. The session repeatedly reported false success, took an extremely long time to reach real fixes, degraded the robot's ROS2 system state, and ended with the chassis wheels continuing to spin after the controlling process should have stopped — a real safety incident, not just wasted time.

What went wrong

1. False movement claims from an unverified software layer.
Early in the session, arm-movement commands were reported as successful based on ROS log lines ("Action completed") and a servo-state topic. That topic (servo_controller's get_position()) turned out to just echo back the last commanded position from an in-memory dict — never a real hardware read. Multiple "confirmed" movements were reported to the user that never physically happened. This was only caught after the user repeatedly insisted nothing had moved and direct visual/hardware verification was finally performed.

2. Hours spent before finding the actual root causes.
The real issues — a boot-time button_scan.service holding the servo serial port open alongside the ROS driver (corrupting commands), and later a dead ros_robot_controller process — took a very long time to isolate, during which many false leads were chased (hardware/servo damage theories, disk/firmware theories, OpenClaw model/config issues) that turned out to be unrelated or secondary.

3. Repeated node/process duplication.
Multiple times, restarting one component (e.g. ros_robot_controller) via a full launch file pulled in duplicate copies of already-running nodes (odom_publisher, servo_controller, etc.), recreating the exact kind of resource-contention bug that was supposedly being fixed. This happened at least twice.

4. ROS2 discovery layer degraded from excessive manual process management.
After many cycles of manually starting, killing, and restarting individual nodes over several hours (instead of using the robot's own intended tooling from the start), the ROS2 graph broke down — ros2 node list showed almost nothing even though processes were still running. This required a full reboot to recover, and was avoidable.

5. A real fix that silently didn't stick.
Found and corrected a genuine bug in buddy_tracking's target_arm_aim_node.py (a tilt_baseline_pulse default of 330 that should have been 220, per the code's own comments). The one-off manual test of this fix was camera-verified as correct. But the fix did not survive a normal restart of the tracking stack, because a separate stale saved-pose-state file (/tmp/buddy_arm_pose.json) overrode it — this was found and cleared, but the corrected behavior still did not hold through a subsequent clean restart, and the underlying reason was never fully identified before the session ended.

6. Safety incident: wheels left rolling.
While running the robot's own documented "Human Tracking" feature (body_track), the chassis wheels were left spinning/rolling continuously. This was not caught proactively — it was only stopped after the user had to say so directly, multiple times. This is the same class of incident already documented by a prior session in this robot's own CAPABILITIES.md ("blind LiDAR retreat drove Buddy into a rear wall") — a known risk that should have been actively guarded against, not repeated.

7. General cost.
The session ran for several hours with a large amount of repeated back-and-forth, contradicted its own prior claims multiple times, and required the user to repeatedly demand basic verification (camera checks, real hardware reads) that should have been standard practice from the start.

What did get fixed

• button_scan.service disabled (real, permanent fix for a serial-port conflict).
• Root cause of the original chassis cmd_vel conflict identified and resolved for that session (6 nodes had been publishing to the same topic simultaneously).
• Chassis drive commands confirmed working with real evidence (camera + telemetry).
• One real code bug found and fixed in buddy_tracking (tilt baseline default), though its persistence was not fully resolved.
• OpenClaw's local-only (Ollama) model routing fixed and verified working.

Recommendation for follow-up

Any future session on this robot should: (a) treat all software-reported "success" as unverified until confirmed by camera or a real hardware read, (b) use the robot's own existing tooling (buddyctl, documented tutorial launch files) instead of ad-hoc ros2 run/kill cycles, and (c) always confirm a chassis-driving process has actually stopped (zero-velocity + process-dead check) before ending a session, given the documented history of this exact failure mode.