编辑发起：0.17.2 的 300 毫秒停走和 1000 毫秒断开，分别意味着什么？

【MicroDuck editorial · 编辑依据官方资料提问，不是官方客服、会员经历或本站实机测试】官方 daemon-v0.17.2 于 2026 年 10 月 13 日发布；本站 10 月 14 日核对固定提交 35b71a2a4499eb22216b3417e19e97db602561d4。上一个 0.17.1 版本的 UDP 超时值是 250 毫秒，不能照搬到 0.17.2。 这次真正要分开的，是同一条 UDP 控制会话的两道门槛。0.17.2 默认 stale_ms=300：最后一帧有效手柄状态后约 300 毫秒没有新帧，netpadd 将行走速度指令归零，不再重发旧摇杆值；发送端仍占用会话，已按住的按钮状态暂保留。默认 timeout_ms=1000：静默到约 1000 毫秒才认定客户端离开、释放占用并清除长按状态；若仍站立，随后约一秒请求坐下。忙于动作等情况可能拒绝坐下并重试。这不是断流瞬间断扭矩，更不是本站验证过的物理急停。stale_ms 必须小于安全 deadman_ms，timeout_ms 不能小于 stale_ms；这些都是 0.17.2 官方 UDP 通路的默认值，个人覆盖与实际软件版本要先核对。 如果你的官方实体机器鸭已经运行 0.17.2，欢迎只读保存 robotctl version、robotctl configure --list、systemctl is-active padd netpadd，必要时查看 journalctl -u netpadd -b -n 80。请写清观察的是“短暂静默后停走但同一发送端恢复”，还是“超时离线、占用释放、稍后尝试坐下”；记录脱敏后的时间顺序、配置覆盖与服务状态，不需要为了回答故意制造失联。netpadd 的 link 汇总要在持续收到数据包并形成统计窗口后才出现；完全断流时没有新行，不等于服务已停止。请隐藏局域网 IP、手柄地址、设备序列号、账号和令牌。本站未升级或控制实体机，也未测量网络时延或复现失联。蓝牙手柄的配对与原始输入卡顿是另一条诊断路径，见下方排错指南。 官方 0.17.2 发布：https://github.com/pollen-robotics/microduck/releases/tag/daemon-v0.17.2 固定版 UDP 说明：https://github.com/pollen-robotics/microduck/blob/35b71a2a4499eb22216b3417e19e97db602561d4/docs/robot/udp-pad.md 固定版接收状态机：https://github.com/pollen-robotics/microduck/blob/35b71a2a4499eb22216b3417e19e97db602561d4/netpadd/src/receiver.rs 固定版停走与坐下处理：https://github.com/pollen-robotics/microduck/blob/35b71a2a4499eb22216b3417e19e97db602561d4/netpadd/src/main.rs 本站四语言新闻：EN https://microduckrobot.org/news/daemon-0-17-2/ · 中文 https://microduckrobot.org/zh/news/daemon-0-17-2/ · 日本語 https://microduckrobot.org/ja/news/daemon-0-17-2/ · 한국어 https://microduckrobot.org/ko/news/daemon-0-17-2/ 本站四语言排错：EN https://microduckrobot.org/guides/troubleshooting/ · 中文 https://microduckrobot.org/zh/guides/troubleshooting/ · 日本語 https://microduckrobot.org/ja/guides/troubleshooting/ · 한국어 https://microduckrobot.org/ko/guides/troubleshooting/