开发板速查

这一页只放在开发板上才有意义的命令。日常用的都在 robotctl 命令速查。

dev 通道

装某个分支在 CI 上最后一次构建的结果：

sudo robotctl update apply --ref <branch> daemon
sudo robotctl update apply --ref main daemon

--version 则是固定到某个确切版本。两者给一个，除非你真的是想“回到稳定版”。

不带 --ref 的 apply 是个陷阱

apply daemon 不带 --ref 会安装最新的稳定发布版，这在开发板上通常是降级。

它的语义不是“装最新的东西”，而是“装稳定通道提供的东西”。

一个分支刚合并之后，那个稳定发布版仍然比你一直在测的所有东西都旧。更麻烦的是：如果它早于某个现在已经在板子上有 unit 文件的守护进程，那个 unit 的 ExecStart 会指向一个旧发布版里根本不存在的二进制，重启失败，更新回滚。

这是门禁在正常工作——但触发它的那条命令看起来才是最显然的那条。

分支标签的行为

标签 daemon-dev-<branch> 会跟着分支移动，所以没有版本号需要你复制。而版本号内部保持每次构建唯一——0.1.0-dev.42.c719ec8——所以同一分支的两次构建永远不会混淆。

--ref main 是让板子回到主线同时留在 dev 通道的方法。普通的 apply daemon 会离开 dev 通道，因为预发布版本排序低于正式发布，而且没有单独的退出步骤。

合并不会立刻发布：CI 得先构建完 main，--ref main 才解析得到它。

gh run list --branch main

候选发布版

release.yml 发布到 staging、还没人提升的那些——金丝雀机器人在提升之前该跑的东西：

sudo robotctl update apply --staging daemon
sudo robotctl update apply --staging --version 0.3.0 daemon

候选版和任何发布版一样用发布密钥签名，并带着它将被提升成的那个版本号。让它在不加参数时够不着的，是它被标记为预发布——普通 apply 会跳过这些，这样就没有机器人会漂移到一个没人验证过的构建上。

--staging 是这个过滤器唯一的显式开关，只作用于这一条命令，执行完不会留下任何被打开的状态。

更新之后：会咬人的那部分

这一节值得单独记住，因为它制造的假象是“修复明明装上了、就是不生效”。

这两个的重启没发生时：下一次 updaterd 启动会修好—— 除了 updaterd 自己，它只报告不一致。重跑 apply，它会回答 already_current 并点名 stale。

重启是分两批发生的

• robotd、configd、padd 在更新过程中重启。
• updaterd 和 btd 在更新应答之后 5 秒才重启——前者不能在更新中途重启自己，后者可能正拿着那个应答。

所以一个 btd 的修复会在几秒之后生效，不需要手动做任何事。重连就有了。

如果那两个重启没发生

下一次 updaterd 启动会修好它——除了 updaterd 自己，它会报告这个不一致而不是重启自己。

对这一个，重跑一次 apply：它会回答 already_current，点名那个没在跑新版本的守护进程，并安排重启。手动做也一样：

sudo systemctl restart updaterd

老版本没有这套机制

跑着低于 0.4.0 的 updaterd 的板子完全没有上面这些行为，会一直让两者停在旧二进制上，直到你手动重启。一次更新修好它，而再下一次更新才开始表现正常。

already_current 不再是“什么都不做”

robotctl update apply 在你请求板子已有的版本时会报 already_current 并且不安装任何东西——但它不再是惰性的。

它会检查哪些守护进程在跑那个发布版，并重启那些没在跑的，在 stale 里点名。

所以当一个修复看起来不生效时，它正是该用的命令：要么它把问题修好，要么 stale 是空的——说明那个修复从来就不在这个发布版里。

怎么查是哪个守护进程落后了

robotctl health

units 块每个守护进程一行，标出它的进程是从哪个发布版启动的，并在这与已安装版本不一致时给出点名警告。

build unknown (old) 表示这个守护进程早于“教会它回答这个问题”的那个发布版——重启它就能回答了。

如果某个守护进程确实落后了，重启它。但这本来不该发生，所以值得读一下 journal 看看为什么：

sudo systemctl restart configd

不需要编辑板子的 updater.toml——重启集合来自发布版自带的 unit 文件。

从笔记本用手柄驱动

手柄在你手上、机器人在台架上，两边都不用装任何东西：padd 是个普通客户端，可以从克隆里跑，连一个转发过来的 socket。

先停掉机器人上那个，否则两个进程会抢摇杆：

sudo systemctl stop padd

转发 socket 并保持开着：

ssh -L /tmp/robotd.sock:/run/robotd.sock radxa@192.168.1.42

另一个终端，在克隆里：

cargo run -p padd -- --socket /tmp/robotd.sock

systemctl start padd 把机器人自己那个放回去。

这也是 padd 那些参数真正有用的场合：--max-linear（m/s）、--max-angular（rad/s）、--max-head（弧度），以及 --deadzone——它存在是因为模拟摇杆很少正好停在零点，没有死区机器人会自己缓慢移动。

systemd unit 用的是默认值，所以想试别的值就得自己跑这个二进制，在笔记本上或在板子上：

sudo -u padd /opt/robot/daemon/current/bin/padd --max-linear 0.25

相关

• 配置一块开发板
• 本机构建，一分钟装上板子
• duckctl——不用网络和 ssh 触达机器人