[X-F-R]

Summary

07_vel_jitter_trace starts a capture thread before the move and joins
it after. If the move throws — a refused cartesian plan or a timeout are
both normal operating conditions — the stack unwinds past the join, the
joinable std::thread is destroyed and std::terminate fires: the
example core-dumps (exit 134) and, because stdout is block-buffered on a
pipe, even the error message is lost.

Changes

• examples/07_vel_jitter_trace.cpp: the log start and the move now run
  in a try block; on failure the capture thread is stopped and joined
  before rethrowing, so the error surfaces through the normal error path.

Testing

Offline: ./build.sh — 28/28 pass (test_protocol_sync SKIP: no
firmware tree). The example harness has no injectable transport, so the
failure path was verified on the real machine instead.

Real machine (LiteArm 7J, firmware Litearm1.10.0-7J, USB 1d50:606f). A
-X cartesian move at this pose is refused by the firmware planner
(fail-closed), which reproduces the failure.

Before this change:

• ./run_example.sh 07_vel_jitter_trace --go --dist -0.01 →
  terminate called without an active exception, core dump, exit 134,
  no trace CSV written, error output lost to buffering

After this change:

• ./run_example.sh 07_vel_jitter_trace --go --dir 2 --dist 0.01 →
  出错: 固件笛卡尔规划失败: 路点 IK 无解或解跳变 (err=1), exit 1, no
  crash, the full plan printout and the error are visible
• ./run_example.sh 07_vel_jitter_trace --go --dir 3 --dist 0.01 →
  规划: ok=1 n_wp=5 settled=1, both trace CSVs written (0 dropped
  frames on the 100 Hz channel)

Issues

None.

[github-actions]

🎉 This PR is included in version 0.1.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀