宇树机器狗编程开发第 24 期：开机自启动

本次配置主要分为三个步骤：首先创建一个用于启动后端程序的脚本，其次将该脚本交给 systemd 管理，最后启用并测试 systemd 服务。这样做的好处是，启动逻辑和系统服务配置可以分开维护，后续如果后端启动命令发生变化，只需要调整启动脚本即可。

首先在后端程序目录中创建启动脚本 `start_server.sh`。这个脚本的作用是进入后端项目目录，并以后台方式启动 Python 后端程序。为了便于后续排查问题，脚本中还将程序运行日志输出到 `go2-server.log` 文件中。这样即使服务在开机时自动启动，我们也可以通过日志文件查看后端是否正常运行。 脚本内容如下： ```bash # 新增 go2-server 路径与 PID 文件 GO2_DIR="/home/unitree/fgai/go2-server/backend" cd "${GO2_DIR}" nohup python3 main.py > go2-server.log 2>&1 & ``` 创建完成后，需要为脚本添加可执行权限。否则 systemd 在调用脚本时可能会因为权限不足而无法执行。 ```bash chmod +x /home/unitree/fgai/go2-server/backend/start_server.sh ``` 这里需要注意，脚本中的 `GO2_DIR` 必须与实际后端项目路径保持一致。如果你的后端目录不是 `/home/unitree/fgai/go2-server/backend`，需要根据自己的项目位置进行修改。否则脚本虽然能够被执行，但会因为找不到 `main.py` 或依赖文件而启动失败。

启动脚本准备好之后，接下来需要创建 systemd 服务文件，让系统在启动过程中自动执行这个脚本。服务文件可以放在 `/etc/systemd/system/` 目录下，例如命名为 `start-go2-server.service`。 可以使用下面的命令打开编辑器并创建服务文件： ```bash sudo nano /etc/systemd/system/start-go2-server.service ``` 服务文件内容如下： ```ini [Unit] Description=Start MediaMTX and RTSP main at boot (one-shot) After=local-fs.target network-online.target Wants=network-online.target [Service] Type=oneshot User=unitree WorkingDirectory=/home/unitree/fgai/go2-server/backend ExecStart=/bin/bash /home/unitree/fgai/go2-server/backend/start_server.sh start Environment="CYCLONEDDS_HOME=/home/unitree/project/cyclonedds/install" RemainAfterExit=yes [Install] WantedBy=multi-user.target ``` 这份配置中，`After=local-fs.target network-online.target` 表示服务会在本地文件系统和网络就绪之后再启动，避免后端程序过早运行时找不到文件或网络资源。`User=unitree` 表示服务会以 `unitree` 用户身份执行，这与我们平时登录机器狗系统后运行后端程序的用户保持一致。`WorkingDirectory` 指定后端程序的工作目录，`ExecStart` 则指定实际执行的启动脚本。 另外，`Environment="CYCLONEDDS_HOME=/home/unitree/project/cyclonedds/install"` 用于设置运行环境变量。如果后端程序依赖 CycloneDDS 相关配置，这个环境变量就需要保留。`RemainAfterExit=yes` 表示即使 `oneshot` 类型的启动命令执行结束，systemd 仍然会把该服务视为处于已激活状态，这对于后台启动脚本比较常见。

服务文件保存完成后，需要让 systemd 重新加载配置，然后启用该服务。启用之后，系统会在后续开机时自动执行这个服务。为了不等到下一次重启再验证，我们也可以立即启动服务并查看运行状态。 完整命令如下： ```bash # 重新加载 systemd 配置 sudo systemctl daemon-reload # 设置开机自启动 sudo systemctl enable start-go2-server.service # 立即启动服务进行测试 sudo systemctl start start-go2-server.service # 查看服务状态 sudo systemctl status start-go2-server.service ``` 如果服务状态显示为正常启动，说明 systemd 已经成功执行了启动脚本。若状态中出现报错，可以重点检查三个位置：服务文件中的路径是否正确、脚本是否具有执行权限、后端程序依赖的环境变量是否完整。一般来说，开机自启动失败多半与路径、权限或环境变量有关。

完成配置后，建议进行一次完整的重启测试。具体做法是关闭机器狗，然后重新开机。待系统启动完成后，不再手动 SSH 启动后端，而是直接打开前端控制程序，验证前端是否能够正常连接后端，并进一步测试机器狗是否可以响应控制指令。 这个验证过程很重要，因为手动执行 `systemctl start` 成功，并不完全等同于开机自启动一定成功。开机时系统服务的启动顺序、网络状态和环境变量加载情况都可能与手动测试时有所不同。因此，最终仍然要以重启后的实际表现为准。 本项目中，机器狗后端服务使用的是 `19000` 端口。重新开机后，可以通过 SSH 登录机器狗系统，然后使用 `lsof` 命令检查该端口是否已经被后端进程占用。 ```bash lsof -i:19000 ``` 如果命令输出了对应的进程信息，说明后端服务已经成功启动，并且正在监听 `19000` 端口。此时前端程序通常就可以通过该端口连接到后端。如果命令没有任何输出，则说明后端服务没有正常启动，需要继续查看 systemd 状态或后端日志。 启动成功后的端口输出如下图所示： 

端口验证通过后，可以继续运行前端程序，并在浏览器中打开控制界面。刚进入控制界面时，前端通常会显示未连接状态，这表示当前还没有与机器狗后端建立通信连接。  点击前端界面中的连接按钮后，如果网络地址、端口和后端服务都正常，页面会提示连接成功，并显示已连接状态。此时说明前端已经能够访问机器狗上的后端服务，开机自启动配置也通过了连接层面的验证。  连接成功后，可以进一步测试控制指令。例如点击前端界面上的站立按钮，机器狗应当能够正常切换到站立状态。如果机器狗能够按预期完成动作，说明前端指令已经能够通过后端正确下发到机器狗控制系统。  随后点击前端界面上的卧倒按钮，机器狗应当能够正常卧倒。站立和卧倒两个动作都能正常执行，说明后端服务不仅启动成功，而且与前端、控制接口之间的通信链路也处于正常状态。  至此，宇树 Go2 机器狗后端服务的开机自启动配置完成。以后每次启动机器狗后，后端都会自动运行，前端可以直接连接并进行控制。相比每次手动登录系统启动服务，这种方式更适合日常调试、现场演示以及需要快速进入控制状态的使用场景。 汇总一下！大家自启动配置都踩过哪些坑？一起来留言分享经验！