Skip to main content

8.1 硬件、系统与环境配置

认证配件及购买链接请参考RDK X3 认证配件清单

Q1: 什么是D-Robotics RDK套件？​

A: D-Robotics Developer Kits，简称D-Robotics RDK套件，是基于D-Robotics智能芯片打造的机器人开发者套件，目前主要包括RDK X3（旭日X3派）、RDK X3 Module（旭日X3模组）、RDK X5、RDK Ultra、RDK S100等系列。

Q2: 如何查看RDK板卡的系统版本号？​

A: 登录到RDK板卡的系统后，您可以使用以下命令：

  1. 查看系统大版本号：

    cat /etc/version

    例如，输出可能是 2.0.0 或 x3_ubuntu_v1.1.6。

  2. 查看已安装的地瓜核心功能包版本：

    apt list --installed | grep hobot

    或者使用 rdkos_info 命令（适用于较新的系统版本，如2.1.0及以后）：

    rdkos_info

    示例输出 (RDK OS 2.x 版本，如2.0.0):

    root@ubuntu:~# apt list --installed | grep hobot
    hobot-boot/unknown,now 2.0.0-20230530181103 arm64 [installed]
    hobot-bpu-drivers/unknown,now 2.0.0-20230530181103 arm64 [installed]
    # ... 其他 hobot-* 包
    root@ubuntu:~# cat /etc/version
    2.0.0

    示例输出 (RDK OS 1.x 版本，如1.1.6):

    root@ubuntu:~# apt list --installed | grep hobot
    hobot-arm64-boot/unknown,now 1.1.6 arm64 [installed]
    # ... 其他 hobot-arm64-* 包
    root@ubuntu:~# cat /etc/version
    x3_ubuntu_v1.1.6

Q3: 不同RDK OS系统版本和硬件平台之间有什么对应关系？​

A:

  • RDK OS 2.x 及更新版本系统 (如2.0.0, 2.1.0, 3.0.x)：
    • 基于D-Robotics Linux开源代码包制作。
    • 通常支持对应芯片的RDK系列硬件，例如RDK X3的2.x/3.x系统支持RDK X3、RDK X3 Module。
  • RDK OS 1.x 版本系统：
    • 基于闭源Linux系统制作，属于历史版本。
    • 主要支持早期的RDK X3硬件。

重要注意事项：

  • 版本升级： 1.x版本系统无法通过apt命令直接升级到2.x或更新版本的系统。如需升级，必须通过烧录新版本系统镜像的方式重新安装操作系统。
  • TROS兼容性： 不同大版本的TROS（如基于Foxy的TROS和基于Humble的TROS）通常与特定的RDK OS大版本绑定。例如，RDK OS 2.x 通常搭载基于ROS2 Foxy的TROS，而RDK OS 3.x 通常搭载基于ROS2 Humble的TROS。

Q4: 摄像头插拔有什么注意事项？​

A: 严禁在开发板未断电的情况下插拔摄像头，否则非常容易烧坏摄像头模组或主板接口。 请务必在断开开发板所有电源后，再进行摄像头的连接或移除操作。

Q5: RDK X3 的调试串口线如何正确连接?​

A: RDK X3的调试串口线一端（通常是白色XH连接器或对应排针）连接到RDK X3板上的DEBUG串口接口。由于接口通常有防呆设计（如凹槽或特定引脚顺序），正反面一般不易接错。另一端连接到USB转串口模块（如CH340、CP210x等），串口模块再通过USB连接到电脑。 连接示意图： RDK X3串口连接示意图 重点关注： 确保串口模块的TX连接到RDK的RX，RX连接到RDK的TX，GND连接到GND。

Q6: F37和GC4663 MIPI摄像头如何连接到RDK X3? 连接后如何验证？​

A: F37和GC4663这类MIPI摄像头模组通常通过24pin FPC（柔性扁平电缆）与开发板连接。 连接注意： FPC排线的两端通常有蓝色加强筋，请确保蓝色加强筋的一面朝上（或朝向连接器卡扣的扳手面，具体取决于连接器类型）插入到开发板和摄像头模组的连接器中，并锁紧卡扣。 F37摄像头连接示意图： F37摄像头连接到RDK X3示意图

连接后验证：

  1. 确保摄像头已正确连接且开发板已上电。

  2. 运行MIPI摄像头示例程序 (以RDK X3为例)：

    cd /app/ai_inference/03_mipi_camera_sample # 路径可能因系统版本而异
    sudo python3 mipi_camera.py

    如果一切正常，您应该能通过HDMI输出或其他指定方式看到摄像头捕捉的画面以及可能的AI算法处理结果。 示例算法渲染结果HDMI输出（检测到teddy bear、cup和vase）： MIPI摄像头算法渲染结果示例

  3. 通过 i2cdetect 命令检查I2C通信： MIPI摄像头通常通过I2C总线与主控芯片通信以进行配置。您可以使用 i2cdetect 命令来扫描连接到特定I2C总线上的设备。RDK X3上MIPI摄像头常用的I2C总线可能是 i2c-1 或 i2c-2 (具体请查阅板卡硬件手册或设备树配置)。

    sudo i2cdetect -y -r 1  # 扫描 i2c-1 总线
    # 或 sudo i2cdetect -y -r 2 # 扫描 i2c-2 总线

    预期输出示例：

    • F37 (通常地址为 0x40): 
            0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
      00:
      ...
      30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --  (UU可能表示内核驱动已占用)
      40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  (0x40为F37地址)
      ...
    • GC4663 (通常地址为 0x29): 
            0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
      00:
      ...
      20: -- -- -- -- -- -- -- -- -- 29 -- -- -- -- -- --  (0x29为GC4663地址)
      30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
      ...

    如果i2cdetect能够扫描到摄像头的I2C地址，说明摄像头至少在I2C通信层面被识别了。

Q7: 开发板启动异常、上电后无任何显示或反复重启，可能是什么原因？如何排查？​

A: 这类问题通常与供电、启动介质（SD卡/eMMC）或硬件连接有关。

  • 供电不足或不稳定：

    • 现象： 系统在U-Boot加载内核时或内核启动初期无明显错误日志就直接重启；绿灯状态异常（如RDK X3绿灯不闪烁或常亮）；HDMI完全黑屏。 Uboot引导内核时因供电不足重启日志示例 内核启动数秒后因供电不足重启日志示例
    • 排查与解决：
      • 确保使用符合开发板要求的电源适配器（RDK X3推荐至少5V/2A，建议使用支持QC/PD的5V/3A或更高规格适配器）。
      • 禁止使用PC的USB接口为开发板供电。
      • 使用质量可靠的USB Type-C供电线。
      • 参考官方推荐的基础配件清单中的电源适配器型号。

  • 启动介质问题 (Micro SD卡/eMMC)：

    • 现象： 串口日志提示无法挂载文件系统、找不到分区、MMC/SD卡初始化错误或超时。 SD卡镜像格式错误日志示例 SD卡物理损坏或接触不良日志示例1 SD卡物理损坏或接触不良日志示例2
    • 排查与解决：
      • 确认SD卡镜像是否已正确、完整地烧录。
      • 尝试重新烧录系统镜像。
      • 更换一张新的、质量可靠的高速Micro SD卡。
      • 清洁SD卡槽和SD卡金手指。

  • 串口误触进入U-Boot：

    • 现象： 系统启动后停留在U-Boot命令行界面（如 hobot>）。
    • 排查与解决： 可能是上电时调试串口有非预期输入。尝试拔掉串口线后重新给设备上电。如果在U-Boot命令行，可以尝试输入 boot 命令并回车。

  • 其他硬件问题或外设冲突：

    • 如果以上都已排除，移除所有非必要外设（USB设备、扩展板等）再尝试启动。
    • 极端情况下可能存在板卡本身硬件故障。

  • 详细排查指南： 请参考官方论坛的板卡无法启动问题定位指南。连接调试串口并记录完整的启动日志对于问题定位至关重要。

Q8: RDK X3对供电有什么具体要求？​

A: RDK X3通过USB Type-C接口供电，并兼容QC (Quick Charge) 和 PD (Power Delivery) 快充协议。

  • 推荐： 使用支持QC或PD快充协议的电源适配器。
  • 最低要求： 至少搭配 5V 直流 2A 的电源适配器。为保证稳定运行，尤其是在连接外设或运行高负载应用时，建议使用 5V/3A 或更高规格的适配器。
  • 警告： 强烈不建议使用PC的USB接口为开发板供电，因为其输出电流往往不足，容易导致开发板工作异常（如无法启动、HDMI无输出、绿灯状态异常、系统反复重启等）。

Q9: RDK X3是否有推荐的SD卡品牌或规格？​

A:

  • 规格： 建议使用高速 C10 (Class 10) 或更高级别 (例如 UHS Speed Class 1 (U1) 或 UHS Speed Class 3 (U3), Application Performance Class A1 或 A2) 的Micro SD卡。容量建议 16GB或以上。
  • 兼容性： 一些较老、非品牌或低速的SD卡可能会存在烧录镜像后无法启动、系统运行缓慢或数据读写不稳定的问题。
  • 推荐品牌 (仅供参考，请以实际测试和官方最新推荐为准)： 金士顿 (Kingston)、闪迪 (SanDisk)、三星 (Samsung) 等知名品牌的高速Micro SD卡通常具有较好的兼容性和稳定性。
    • 金士顿示例链接 (来自原始文档): https://item.jd.com/25263496192.html
    • 闪迪示例链接 (来自原始文档): https://item.jd.com/1875992.html#crumb-wrap (请注意，链接仅为原始文档提供，具体购买时请仔细甄别产品型号和渠道。)

Q10: apt update 命令执行失败或报错（如密钥错误、无法更新、锁文件被占用）如何处理？​

A:

(1) 地瓜源域名变更或GPG密钥问题​

  • 原因： 地瓜机器人官方的apt软件源域名或GPG签名密钥可能发生过变更。
  • 报错示例：
    • Clearsigned file isn't valid, got 'NOSPLIT'
    • The repository '...' is no longer signed.
    • Could not resolve 'archive.sunrisepi.tech' (或其他旧域名)
    • The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ...
  • 解决方法：
    1. 更新域名： 编辑 /etc/apt/sources.list.d/sunrise.list (或其他地瓜源配置文件)，将其中旧的域名 (如 archive.sunrisepi.tech, sunrise.horizon.cc) 替换为最新的官方域名 (当前通常是 archive.d-robotics.cc)。 
      # 示例，请将“旧域名”替换为实际在您配置文件中看到的旧域名
      sudo sed -i 's/旧域名/archive.d-robotics.cc/g' /etc/apt/sources.list.d/sunrise.list
    2. 更新GPG密钥： 下载并安装最新的地瓜源GPG密钥。 
      sudo wget -O /usr/share/keyrings/sunrise.gpg [http://archive.d-robotics.cc/keys/sunrise.gpg](http://archive.d-robotics.cc/keys/sunrise.gpg)
    3. 再次尝试 sudo apt update。

(2) apt锁文件被占用​

  • 报错示例： 
    E: Could not get lock /var/lib/apt/lists/lock. It is held by process XXXX (apt-get)
    N: Be aware that removing the lock file is not a solution and may break your system.
    E: Unable to lock directory /var/lib/apt/lists/
  • 原因： 系统可能正在后台自动运行更新检查或安装任务，或者上一次apt操作未正常结束导致锁文件未被释放。
  • 解决方法：
    1. 等待： 有时后台进程会自动完成，请稍等片刻再试。
    2. 杀死占用进程： 如果长时间被占用，可以尝试杀死持有锁的进程（报错信息中通常会提示进程ID，如示例中的 XXXX）： 
      sudo kill XXXX
    3. 清理锁文件（谨慎操作）： 在确认没有apt或dpkg进程正在运行后，可以尝试移除相关的锁文件。此操作有一定风险，可能破坏您的包管理系统，请务必谨慎。 
      sudo rm /var/lib/apt/lists/lock
      sudo rm /var/cache/apt/archives/lock
      sudo rm /var/lib/dpkg/lock
      sudo rm /var/lib/dpkg/lock-frontend
      sudo dpkg --configure -a  # 尝试修复任何未完成的包配置
    4. 再次尝试 sudo apt update。

Q11: 如何查看RDK X3的CPU、BPU等硬件单元的运行状态?​

A: 可以使用地瓜机器人提供的 hrut_somstatus 工具来查看实时的系统状态，包括CPU各个核心的占用率、BPU（AI计算单元）的使用率、内存使用情况、芯片温度等。 在板卡终端执行：

sudo hrut_somstatus

该命令通常会以一定的时间间隔持续刷新显示状态信息。按 Ctrl+C 可以退出。

Q12: 如何为RDK应用设置开机自启动?​

A: 主要有两种方式：

  1. 通过 /etc/rc.local 文件 (传统方式)： 编辑该文件 (如果不存在，可能需要手动创建或从模板配置并启用 rc-local.service)，在 exit 0 语句之前加入您要执行的命令。确保脚本具有可执行权限。

    #!/bin/bash -e
    #
    # rc.local
    #
    # This script is executed at the end of each multiuser runlevel.
    # Make sure that the script will "exit 0" on success or any other
    # value on error.
    #
    # In order to enable or disable this script just change the execution
    # bits.
    #
    # By default this script does nothing.

    # Example: Start your application in the background
    # /usr/bin/python3 /home/sunrise/my_app.py &

    # Insert what you need before this line
    exit 0

    参考：RDK文档 - rc.local自启动

  2. 通过 systemd 服务（现代、推荐方式）： 创建一个 .service 配置文件（例如 /etc/systemd/system/myapp.service），定义服务的启动命令、依赖关系、运行用户、重启策略等。 示例 myapp.service 文件：

    [Unit]
    Description=My Application Service
    After=network.target multi-user.target

    [Service]
    User=sunrise
    ExecStart=/usr/bin/python3 /home/sunrise/my_app.py
    Restart=on-failure
    # StandardOutput=append:/var/log/myapp_stdout.log
    # StandardError=append:/var/log/myapp_stderr.log

    [Install]
    WantedBy=multi-user.target

    然后使用以下命令启用并启动服务：

    sudo systemctl daemon-reload  # 如果新建或修改了service文件
    sudo systemctl enable myapp.service
    sudo systemctl start myapp.service
    # 查看服务状态: sudo systemctl status myapp.service
    # 查看服务日志 (如果配置了): journalctl -u myapp.service

    参考：RDK社区帖子 - systemd自启动

自启动注意事项：

  • 确保脚本或程序的路径正确，并且具有执行权限。
  • 处理好依赖项（如网络、特定硬件初始化完成）和环境变量。
  • 如果应用需要图形界面，确保 DISPLAY 环境变量已正确设置，并且X Server已运行。
  • 建议将应用的输出重定向到日志文件，以便排查自启动失败的原因。

Q13: 开发板的默认登录账户和密码是什么？​

A: 开发板通常默认支持以下两种账户：

  • 普通用户： 用户名 sunrise，密码 sunrise
  • 超级用户 (root)： 用户名 root，密码 root (请注意，具体默认账户和密码可能因您烧录的系统镜像版本和来源略有不同，建议查阅该镜像的发行说明。)

Q14: 如何在RDK板卡上挂载NTFS文件系统的U盘或硬盘并支持读写？​

A: Ubuntu系统默认对NTFS文件系统的写入支持可能不完整或仅为只读。为了获得完整的NTFS读写支持，需要安装 ntfs-3g 软件包：

  1. 安装 ntfs-3g： 
    sudo apt update
    sudo apt -y install ntfs-3g
  2. 挂载NTFS分区： 安装完成后，再使用 mount 命令挂载NTFS分区。通常，系统会自动使用 ntfs-3g 驱动进行挂载，从而支持读写。
    • 首先，创建一个挂载点目录（如果尚未创建）： 
      sudo mkdir /mnt/my_ntfs_disk
    • 然后挂载设备（假设NTFS分区是 /dev/sda1，请根据实际情况替换）： 
      sudo mount /dev/sda1 /mnt/my_ntfs_disk
      # 或者显式指定类型 (通常不需要，系统会自动识别)
      # sudo mount -t ntfs-3g /dev/sda1 /mnt/my_ntfs_disk
    现在，您应该可以在 /mnt/my_ntfs_disk 目录下对NTFS分区进行读写操作了。

Q15: RDK开发板是否支持本地安装VS Code？如何在PC上使用VS Code远程连接开发板？​

A:

  • 本地安装VS Code： RDK开发板作为嵌入式ARM架构设备，通常不直接支持在其上本地安装并运行完整版的VS Code桌面应用程序。VS Code官方主要提供x86_64架构的桌面版。
  • 远程开发 (推荐方式)： 强烈推荐在您的PC（Windows, macOS, 或Linux）上安装VS Code，并利用其强大的 Remote - SSH 扩展插件来远程连接到RDK开发板。通过这种方式，您可以在PC上享受完整的VS Code体验（包括代码编辑、智能提示、调试器前端等），而实际的代码编译、运行和调试则在RDK板卡上执行。 步骤概述：
    1. 在PC上的VS Code中安装 "Remote - SSH" 扩展。
    2. 确保您的PC和RDK板卡在同一局域网内，并且RDK板卡上的SSH服务已启动且网络可达。
    3. 在VS Code中配置SSH连接到RDK板卡（通常是 ssh 用户名@板卡IP地址）。
    4. 连接成功后，您可以直接在VS Code中打开RDK板卡上的文件夹进行开发。

Q16: RDK开发板如何启用和使用ADB (Android Debug Bridge) 调试功能？​

A: RDK的Ubuntu系统中通常默认已经编译并可能启动了 adbd (ADB守护进程) 服务，但其默认配置和USB接口的功能模式可能需要调整才能用于ADB连接。

  1. 确认adbd服务： 检查服务是否运行，或是否有启动脚本。
  2. USB接口模式： RDK板卡的USB Type-C口或特定的Micro USB口（通常标有OTG或Device功能）可能需要被配置为USB Device模式（而不是Host模式）才能被PC识别为ADB设备。这有时可以通过 srpi-config 工具或修改设备树/内核参数来配置。
  3. PC端准备： 在您的电脑上安装ADB工具包（通常作为Android SDK Platform Tools的一部分提供）。
  4. 连接： 使用USB线将PC与RDK板卡上配置为Device模式的USB口连接。
  5. 验证： 在PC的命令行/终端中执行 adb devices。如果一切配置正确，您应该能看到列出的RDK设备。
  6. 使用： 一旦连接成功，您就可以使用 adb shell 访问板卡终端，adb push <本地文件> <板卡路径> 上传文件，adb pull <板卡文件> <本地路径> 下载文件等。

注意： 具体的启用步骤可能因RDK型号和系统版本而异。请务必查阅对应板卡和系统版本的官方文档中关于ADB功能配置的详细说明。有时，官方提供的 bootloader 更新教程中也可能包含ADB的配置或使用前提。 参考 (来自原始文档，可能主要关于bootloader更新，但可间接涉及ADB环境)：bootloader镜像更新 (建议查找更专注于ADB配置的官方文档或社区帖子)。

Q17: 开发板和电脑之间的文件传输有哪些常用方式？​

A: 有多种方式可以在RDK开发板和电脑之间传输文件：

  1. SCP (Secure Copy Protocol) - 基于SSH：

    • 从电脑拷贝文件到开发板： 
      # 拷贝单个文件
      scp /path/to/local_file sunrise@<开发板IP地址>:/path/on/rdk/
      # 拷贝整个文件夹 (使用 -r 选项)
      scp -r /path/to/local_folder sunrise@<开发板IP地址>:/path/on/rdk/
    • 从开发板拷贝文件到电脑： 
      scp sunrise@<开发板IP地址>:/path/on/rdk/remote_file /path/to/local_destination/
      scp -r sunrise@<开发板IP地址>:/path/on/rdk/remote_folder /path/to/local_destination/

    需要电脑端有SCP客户端（Linux/macOS自带，Windows可用WinSCP、MobaXterm或Git Bash中的scp）。

  2. SFTP (SSH File Transfer Protocol) - 基于SSH： 许多FTP客户端软件（如FileZilla, WinSCP）支持SFTP协议，可以提供图形化的文件传输界面。连接时选择SFTP协议，并使用SSH的用户名、密码和IP地址。

  3. USB存储设备 (U盘/移动硬盘)：

    • 将U盘等格式化为开发板支持的文件系统（如FAT32, exFAT, 或安装了ntfs-3g后的NTFS）。
    • 在电脑上存入文件，然后将U盘插入开发板的USB Host口。
    • 在开发板上挂载U盘 (sudo mount /dev/sda1 /mnt/usb_disk - 设备节点可能变化)，然后进行文件操作。

  4. ADB (Android Debug Bridge) - 如果已配置并连接：

    • 从电脑推送文件到开发板： 
      adb push C:\local\path\file.txt /remote/path/on/rdk/
    • 从开发板拉取文件到电脑： 
      adb pull /remote/path/on/rdk/file.txt C:\local\path\

  5. 网络共享服务 (如Samba, NFS)： 可以在开发板上配置Samba或NFS服务，将特定目录共享到局域网，然后在电脑上像访问网络驱动器一样访问这些文件。配置相对复杂一些。

  6. Python HTTP服务器 (临时小文件共享)： 如果在开发板的某个目录下有想让电脑下载的文件，可以在该目录下快速启动一个HTTP服务器：

    # 在开发板上，进入要共享的目录
    cd /path/to/share
    python3 -m http.server 8000

    然后在电脑的浏览器中访问 http://<开发板IP地址>:8000 即可看到文件列表并下载。

选择哪种方式取决于文件大小、传输频率、网络环境以及个人偏好。对于开发过程中的代码和配置文件同步，SCP/SFTP或VS Code的Remote-SSH内置的文件同步功能通常最为便捷。

Q18: RDK X3不同系统版本的有线网口的IP是什么？​

A:

  • RDK X3 2.0.0 (包括2.0.0) 以下版本的RDK OS系统镜像，有线网口默认IP：192.168.1.10/24
  • RDK X3 2.1.0 (包括2.1.0) 以上版本的RDK OS系统镜像，有线网口默认IP：192.168.127.10/24

Q19: RDK X5 不同系统版本的网口的IP是什么？​

A: (以RDK OS 3.0.0版本为例)

  • RDK X5 3.0.0 版本的RDK OS系统镜像，有线网口默认IP：192.168.127.10/24
  • RDK X5 3.0.0 版本的RDK OS系统镜像，闪连口（USB Device口），为虚拟USB网卡，默认IP：192.168.128.10/24

Q20: 系统执行 apt upgrade 时桌面环境黑屏怎么办？​

A: 建议通过串口终端或SSH远程登录后，在纯字符界面的终端中执行系统更新命令（如 sudo apt update && sudo apt upgrade）。直接在图形桌面的终端中更新，有时在升级桌面自身相关的包时可能会导致显示中断或X Server重启，从而造成黑屏现象。

Q21: 我将X3板卡的HDMI输出接口和电脑的HDMI输入/输出接口相连，为什么电脑没有出现画面？​

A: RDK X3板卡的HDMI接口是输出接口，用于将板卡的图形界面或视频信号输出到显示设备（如HDMI显示器、电视机）。 电脑上的HDMI接口通常也都是输出接口（用于连接外接显示器）或者在特定情况下（如带有视频采集卡的台式机、部分一体机或笔记本）可能有HDMI输入接口。

  • 如果将RDK X3的HDMI输出连接到电脑的HDMI输出接口，两者都是输出设备，自然无法显示。
  • 如果您的电脑确实有HDMI输入接口（例如，显示器模式或采集卡输入），请确保电脑已切换到正确的HDMI输入源，并且该输入接口支持RDK X3输出的分辨率和信号格式。 对于希望在电脑上看到RDK X3画面的场景，更常见和推荐的做法是：
  • VNC远程桌面： 如果RDK X3烧录的是Desktop版本的系统并开启了VNC服务，您可以通过网络在电脑上使用VNC客户端远程访问其桌面。
  • 视频推流： 将RDK X3的摄像头画面或处理结果通过网络推流（如RTSP、WebRTC），然后在电脑上使用播放器或浏览器接收观看。

Q22: 为什么SD卡插上去能启动，但是拔下来后下次就启动不了了？​

A: 这取决于您的RDK板卡型号和启动方式：

  • 对于RDK X3（标准版，通常从SD卡启动）和设置为SD卡启动模式的RDK X3 Module： 在这种情况下，Micro SD卡是作为操作系统和用户数据的唯一存储介质。系统运行时所有文件都存储在SD卡上。因此，SD卡必须始终插入板卡才能正常启动和运行。如果拔下SD卡，系统自然无法找到引导文件和操作系统，下次将无法启动。
  • 对于配置为从eMMC启动模式的RDK X3 Module： 这种板卡板载了eMMC存储芯片，操作系统可以烧录并运行在eMMC中。在这种模式下，启动时不需要插入SD卡（除非您希望从SD卡临时引导）。如果eMMC中的系统完好，板卡应该能从eMMC正常启动。此时插入的SD卡可以用作额外的外部存储设备，例如挂载到某个目录下存放数据。如果您拔下了作为外部存储的SD卡，并不会影响从eMMC启动的系统。

请确认您的板卡型号和当前的启动介质设置。

Q23: RDK OS的Server版能直接升级为Desktop版吗？​

A: RDK OS的Server版和Desktop版在预装的软件包上存在显著差异，最主要的是Desktop版包含了图形用户界面（如XFCE桌面环境）及其相关组件，而Server版通常不包含这些，以节省资源。

  • 理论上： 您可以通过在Server版系统上手动安装所有Desktop版所需的软件包（如xserver-xorg, xfce4, lightdm等以及它们的依赖）来将其“升级”为一个具有图形界面的系统。
  • 官方支持与稳定性： 官方通常不提供或不推荐这种手动升级路径，并且不对通过此方式构建的Desktop系统的稳定性和完整性进行保证或测试。手动安装过程复杂，容易遗漏依赖或产生配置冲突。
  • 推荐做法： 如果您需要Desktop版的完整功能和最佳体验，强烈建议直接下载并烧录官方发布的Desktop版本系统镜像。这是确保系统稳定性和功能完整的最佳途径。

Q24: 为什么连接HDMI显示器后没有画面显示，或者显示异常？​

A: HDMI显示问题可能由多种原因造成：

  1. 显示器兼容性：
    • 部分显示器可能与RDK板卡输出的特定分辨率或刷新率不完全兼容。
    • RDK OS 2.1.0及以上版本引入了更多的HDMI分辨率支持，但也可能导致与某些旧显示器的兼容性问题。
    • 通常情况下，标准的1080p (1920x1080) 分辨率的显示器在板卡启动时直接连接，兼容性会比较好。
  2. 线缆问题： 确保使用的HDMI线缆质量良好且连接牢固。尝试更换一条HDMI线。
  3. RDK系统配置：
    • 对于Desktop版本的系统，确保图形界面服务（如LightDM）正常启动。
    • 对于Server版本的系统，默认情况下HDMI可能只输出启动LOGO或控制台信息，不会有图形桌面。
    • 在RDK OS 2.1.0及以上版本，如果遇到显示不兼容，可以尝试先通过VNC连接到板卡（如果已开启），然后在系统中手动调整HDMI的输出分辨率。参考：HDMI显示问题及分辨率调整
  4. 供电问题： 虽然不直接，但严重的供电不足可能导致系统无法正常初始化显示子系统。
  5. 硬件问题： 极少数情况下，可能是板卡的HDMI接口或显示器本身的硬件故障。

Q25: 连接的HDMI显示器不被支持，如何抓取EDID信息以供技术支持分析？​

A: 如果您的HDMI显示器无法正常显示或显示异常，技术支持人员可能需要您提供该显示器的EDID (Extended Display Identification Data) 信息来帮助诊断问题或添加兼容性支持。EDID包含了显示器的特性、支持的分辨率和时序等信息。 获取EDID信息的方法通常有：

  1. 通过Linux命令行工具（如果板卡能部分启动或通过其他方式访问）：
    • 可以使用如 read-edid 包中的 get-edid 和 parse-edid 工具。首先需要安装这些工具：sudo apt install read-edid。
    • 然后尝试读取连接的显示器的EDID。
  2. 使用专门的EDID读取硬件/软件： 有些显示器测试工具或专用的EDID编程器可以直接读取和保存EDID信息。
  3. 在PC上读取： 如果该显示器连接到一台装有Linux或Windows的PC上可以正常工作，也可以尝试在PC上读取其EDID信息。
    • Linux下可以使用 xrandr --props 查看连接显示器的属性，其中可能包含EDID信息，或使用 get-edid | parse-edid。
    • Windows下可以使用如MonitorInfoView (NirSoft) 或 Phoenix EDID Designer 等工具。

获取到EDID数据（通常是一个二进制文件或十六进制文本）后，可以将其提供给技术支持。 具体在地瓜机器人RDK平台抓取EDID的方法，请参考官方论坛的指导帖子：如何提供不支持显示器的EDID信息

Q26: SD卡有时不识别或识别不稳定怎么办？​

A: SD卡不识别或识别不稳定的问题，可以从以下几个方面排查：

  1. SD卡本身质量：
    • 使用劣质、老化或损坏的SD卡是常见原因。请尝试更换一张新的、质量可靠的品牌高速Micro SD卡（如Class 10, U1/U3级别）。
  2. SD卡与卡槽接触：
    • 确保SD卡已完全插入卡槽且接触良好。可以尝试取出SD卡，用橡皮擦清洁金手指，并检查卡槽内是否有异物。
  3. SD卡兼容性：
    • 虽然RDK X3对SD卡的兼容性在新版系统中已较好，但极少数SD卡仍可能存在兼容性问题。
    • 对于旭日X3派，如果遇到SD卡兼容性问题，官方建议可以尝试手动烧录最新的miniboot镜像来改善。此方法也适用于RDK X3。 参考教程：SD卡兼容性问题及miniboot更新
  4. 系统镜像或烧录问题：
    • 确保系统镜像文件本身没有损坏，并且烧录过程正确无误。可以尝试重新下载镜像并使用推荐的烧录工具（如balenaEtcher, Rufus）重新烧录。
  5. 供电问题：
    • 不稳定的供电有时也可能间接影响SD卡的识别和读写稳定性。
  6. 板卡硬件问题：
    • 极少数情况下，可能是板卡的SD卡控制器或卡槽硬件故障。

如果在串口日志中看到类似 "mmc0: error -110 whilst initialising SD card" 或 "Card did not respond to voltage select" 等信息，通常指向SD卡识别或初始化失败。

Q27: 系统启动的时候卡在 hobot> U-Boot命令行界面怎么办？​

A: 当系统启动时停留在 hobot> 提示符，这表示板卡已进入U-Boot (Universal Boot Loader) 的命令行模式，而没有继续引导加载Linux内核。可能的原因有：

  1. 串口干扰： 在板卡上电启动的最初几秒内，如果调试串口接收到了某些非预期的字符或电平信号（例如，键盘误触、串口终端软件自动发送的某些控制字符），可能会中断U-Boot的自动引导流程，使其停在命令行。
  2. 引导顺序配置： U-Boot内部有引导顺序的配置（如先尝试SD卡，再尝试eMMC或网络引导）。如果配置被意外更改，或者首选的引导介质上没有有效的系统，也可能停在命令行。
  3. 引导脚本问题： U-Boot执行的引导脚本（boot script）如果存在错误或被中断。
  4. 按键中断： 某些板卡设计中，如果在启动时按下了特定的按键，也可能进入U-Boot命令行。

解决方法：

  • 简单尝试： 在 hobot> 提示符下，直接输入 boot 命令并按回车。这会尝试执行默认的引导命令，通常能继续引导进入Linux系统。
  • 检查串口连接： 确保调试串口连接稳定，没有不必要的信号干扰。可以尝试断开串口线后重新给板卡上电，看是否能正常启动。
  • 检查启动介质： 确认SD卡或eMMC中的系统镜像是否完好且可引导。
  • 复位U-Boot环境变量（谨慎操作）： 如果怀疑U-Boot环境变量被错误修改，可以尝试恢复到默认设置（具体命令需查阅对应U-Boot版本的文档，如 env default -a; saveenv; reset）。此操作会清除所有自定义环境变量，请谨慎。

Q28: 旭日X3派如何从40pin GPIO给板卡供电？RDK X3呢？​

A:

  • 旭日X3派 (Sunrise X3 Pi)： 根据官方说明，旭日X3派不可以通过40pin GPIO进行供电。其电源设计可能未包含从GPIO获取主电源的路径或保护。
  • RDK X3 (标准版/核心板)： RDK X3（非特指旭日X3派）的某些版本可以通过40pin GPIO中的5V引脚进行供电。但即使可以，这通常也不是推荐的主要供电方式，其稳定性和电流承载能力可能不如专用的Type-C电源接口。

通用强烈建议： 官方始终只建议使用符合规格的电源适配器通过板卡的Type-C（或其他专用电源）接口进行供电。任何通过非推荐方式（如直接从GPIO引脚、不适配的电源模块等）供电，都可能存在电流不足、电压不稳、缺乏保护电路等风险，由此造成的硬件损坏或系统不稳定，后果通常需要用户自行承担。

如何区分RDK X3和旭日X3派，请参考本FAQ中相关问题的解答。

Q29: 镜像烧录失败的常见原因有哪些？​

A: 使用烧录工具（如balenaEtcher, Rufus）向SD卡烧录系统镜像时失败，可能的原因包括：

  1. 镜像文件问题：
    • 未完全解压： 确保您烧录的是从压缩包（如 .zip, .gz, .xz）中完全解压出来的 .img 后缀的原始镜像文件，而不是直接烧录压缩包。
    • 镜像下载不完整或损坏： 尝试重新下载镜像文件，并校验其MD5/SHA256值（如果官方提供）以确保文件完整性。
  2. SD卡问题：
    • SD卡损坏或质量差： 尝试更换一张新的、质量可靠的SD卡。
    • SD卡写保护： 确保SD卡的物理写保护开关（如果有）未开启。
    • SD卡容量不足： 确保SD卡容量大于镜像文件解压后的大小。
  3. 读卡器问题：
    • 读卡器损坏或与SD卡/电脑不兼容。尝试更换读卡器。
    • 部分高速SD卡在老旧或质量不佳的读卡器上可能出现问题。
  4. 烧录工具或电脑环境问题：
    • 烧录软件版本： 尝试更新或更换其他版本的烧录软件。
    • USB接口或驱动： 尝试更换电脑的USB接口；确保USB驱动正常。
    • 操作系统权限： 在Windows下，以管理员权限运行烧录工具。
    • 杀毒软件或防火墙干扰： 临时禁用可能干扰磁盘写入操作的安全软件。
    • Windows弹出格式化提示： 在烧录过程中，Windows系统可能会因为无法识别SD卡上的Linux分区而弹出“是否需要格式化”的对话框。请务必选择“否”或直接关闭该对话框，不要进行格式化操作，否则会中断烧录。
  5. 交叉验证： 如果条件允许，尝试在另一台电脑上使用同一个SD卡和读卡器进行烧录，或者在同一台电脑上使用不同的SD卡/读卡器组合，以帮助定位问题环节。

Q30: 连接不上RDK X3的VNC远程桌面怎么办？​

A: 如果无法通过VNC客户端连接到RDK X3的远程桌面，请按以下步骤检查：

  1. 确认系统版本与VNC服务状态：
    • Desktop版本镜像： 确保您为RDK X3烧录的是Desktop版本的系统镜像。Server版本的系统默认不包含图形桌面环境和VNC服务。
    • VNC服务已开启：
      • 对于RDK OS 2.1.0及以上版本（或由2.0.0升级而来的系统），VNC服务需要在 srpi-config 工具中手动开启。请SSH登录到板卡，执行 sudo srpi-config，找到VNC相关选项并启用。
      • 对于更早期的系统版本，VNC服务可能是默认开启的。
    • VNC服务是否正常运行： 可以尝试在板卡上查看VNC服务进程（如 tightvncserver, x11vnc 等，具体服务名可能因系统而异）是否在运行。
  2. 网络连接：
    • 确保您的电脑和RDK X3板卡在同一个局域网内。
    • 确保您能从电脑 ping 通RDK X3的IP地址。
    • 检查防火墙设置（电脑端或网络设备），确保没有阻止VNC端口（默认为5900 + DisplayNumber，如5901对应显示:1）。
  3. VNC客户端配置：
    • IP地址和端口： 在VNC客户端中输入的IP地址应为RDK X3的IP地址。端口号通常是 5900 + N，其中 N 是VNC服务器启动的显示号（Display Number），通常是 1 (即端口5901)。部分VNC服务器或客户端可能直接使用IP地址加显示号（如 192.168.1.10:1）。
    • 密码： VNC连接通常需要密码。RDK系统默认的VNC密码可能是 sunrise 或您在 srpi-config 中设置的密码。
  4. SSH连接验证： 在排查VNC问题前，先确保您可以通过SSH正常连接到RDK X3。如果SSH也无法连接，则应首先解决网络或SSH服务本身的问题。
  5. 资源占用： RDK X3（尤其是不带独立GPU的型号）在运行图形桌面和VNC服务时，CPU和内存资源消耗较大。如果板卡负载过高，VNC服务可能会响应缓慢或连接失败。

Q31: 使用RDK X5的 /app/pydev_demo/02_camera_hdmi_output 和 03_yolov5_camera_hdmi_output 示例时，没有画面显示，只有一个黑色窗口，是什么原因？​

A:

  1. 更新软件包： 首先，请确保您的RDK X5系统上的所有hobot*开头的软件包都已更新到最新版本。在确保地瓜机器人官方APT源配置正确后，执行： 
    sudo apt update && sudo apt upgrade
    然后重启板卡。
  2. 示例目的理解： 这两个示例（尤其是 02_camera_hdmi_output）的核心目的是演示如何将摄像头获取的NV12格式图像数据，通过硬件BT1120接口直接从HDMI物理端口输出。这种方式是硬件直出，并不是在XFCE桌面环境中通过cv2.imshow()等方式渲染一个窗口来显示画面。因此，您在桌面上看到的那个黑色或灰色窗口，可能只是一个空的占位窗口或者根本不是图像显示窗口。真正的图像是直接输出到连接的HDMI显示器上的。
  3. 关闭桌面环境 (针对HDMI硬件直出)： 如果您运行的是Desktop版本的RDK X5系统，并且希望通过这些示例实现HDMI硬件直出预览画面的效果，您必须先关闭XFCE图形桌面环境，否则可能会产生冲突或报错，HDMI也不会显示预期的图像。执行以下命令关闭桌面： 
    sudo systemctl stop lightdm
    关闭桌面后，您需要通过SSH或串口登录来运行这些示例程序。
  4. Sensor分辨率选择： 部分新版本的示例在启动时会提示用户选择Sensor的分辨率（例如输入0-4之间的数字）。请按照程序运行时的提示进行操作。

Q32: 运行RDK X5的 /app/pydev_demo/02_camera_hdmi_output 或 03_yolov5_camera_hdmi_output 示例时，HDMI输出的图像是倒向的，或者不显示YOLOv5的检测框，是什么情况？​

A:

  • 图像倒向/无检测框 (在XFCE桌面环境下运行)： 如果您是在XFCE图形桌面环境下直接运行这些Python示例，并且通过cv2.imshow()看到了一个窗口，那么这个窗口显示的图像可能确实是倒向的（这取决于OpenCV获取图像的方式和原始Sensor的朝向），并且不会显示通过HDMI硬件OSD叠加的检测框。因为cv2.imshow()是在CPU上渲染，而示例中YOLOv5的检测框等信息可能是设计为通过硬件OSD（Overlay Screen Display）直接叠加到HDMI输出信号上的。
  • 正确的HDMI硬件直出预览方式：
    1. 如Q31所述，必须先执行 sudo systemctl stop lightdm 关闭图形桌面环境。
    2. 通过SSH或串口登录到RDK X5。
    3. 运行示例程序。此时，摄像头画面以及由硬件OSD叠加的检测框（对于03_yolov5_camera_hdmi_output示例）会直接输出到连接的HDMI显示器上。

简而言之，这些特定示例的预期效果（包括正确的图像朝向和硬件OSD）需要在关闭桌面环境后，通过HDMI物理端口直接观察。

Q33: TF卡（Micro SD卡）接触不良或损坏时，可能会在内核日志中看到哪些典型错误信息？​

A: 如果Micro SD卡接触不良、损坏或不兼容，您可能会在系统启动的串口日志或通过dmesg命令查看到的内核日志中观察到类似以下的错误信息，这些信息通常与MMC (MultiMediaCard) 控制器无法正确初始化或与SD卡通信有关：

mmc0: card never left busy state
mmc0: error -110 whilst initialising SD card
mmc_rescan_try_freq: send_status error -110
Card did not respond to voltage select! : -110
mmc0: unrecognised CSD structure version x
mmc0: error -22 whilst initialising SD card
eMMC or SD Card not detected on mmchost 0  (mmchost X 可能指代不同的MMC控制器)
MMC Device X not found
no mmc device at slot X

出现这类日志通常意味着需要检查SD卡是否插好、更换SD卡或检查SD卡槽。

Q34: RDK X5是否支持实时Linux内核（RT-Linux）？如何获取和使用？​

A: 是的，RDK X5支持Preempt-RT（实时抢占）内核，这对于需要低延迟和确定性响应的机器人应用非常重要。

  • 获取方式：
    1. 系统镜像： 通常需要您的RDK X5系统版本支持（例如，官方文档中提到的RDK OS 3.0.1或更新版本）。 官方镜像下载地址参考：https://archive.d-robotics.cc/downloads/os_images/rdk_x5/ (请查找对应系统版本下的Preempt-RT相关资源，例如 rdk_os_3.0.1-2024-10-18/Preempt-RT/ 目录，日期仅为示例)。
    2. Debian包： 在上述下载路径中，通常会提供预编译好的实时内核 .deb 包。
    3. 内核源码： 地瓜机器人也会在GitHub上提供RDK X5的Preempt-RT内核源码，供开发者自行编译和定制。 源码仓库参考：D-Robotics x5-kernel-rt on GitHub
  • 使用方法：
    1. 确保您的基础RDK X5系统已正确安装并运行。
    2. 下载对应系统版本的实时内核 .deb 包（通常包含内核镜像和头文件）。
    3. 将 .deb 包传输到RDK X5板卡上。
    4. 使用 sudo dpkg -i <kernel_image.deb> <kernel_headers.deb> 命令安装实时内核。
    5. 安装完成后，需要更新引导加载程序（如U-Boot）的配置，使其在下次启动时加载新的实时内核。具体步骤请严格参照官方文档或安装包中提供的说明。
    6. 重启板卡。
    7. 通过 uname -a 命令验证当前运行的是否为实时内核（通常版本号中会带有 -rt 标识）。

Q35: RDK X5使用VNC远程桌面时感觉显示卡顿，有什么优化或解决方法？​

A: VNC远程桌面是通过网络传输屏幕数据并在客户端渲染，其流畅度受多种因素影响，尤其是在没有独立GPU辅助渲染的嵌入式设备上。针对RDK X5 VNC卡顿问题，可以尝试以下方法：

  1. 连接HDMI显示器或HDMI欺骗器 (Dummy Plug)：
    • 有些嵌入式系统在未检测到物理显示器连接时，可能会限制图形渲染的性能或帧率。尝试连接一个真实的HDMI显示器，或者使用一个HDMI欺骗器（也叫HDMI虚拟显示器、假负载），让系统认为有显示器连接，有时可以改善VNC的性能。这与某些Raspberry Pi设备上的类似现象相似。
  2. 使用虚拟显示器软件方案：
    • 可以尝试在RDK X5的Linux系统中配置和使用虚拟显示器软件（如 Xvfb - X Virtual FrameBuffer，或结合 x11vnc 使用）。这样可以创建一个不依赖物理显示器的虚拟屏幕，VNC服务直接从此虚拟屏幕抓取内容。
    • 有社区用户分享过相关经验，例如此CSDN博客文章（链接仅供参考，请自行判断其适用性和安全性）：RDK X5 虚拟显示器配置参考
  3. 优化VNC服务器和客户端设置：
    • 色彩深度和质量： 在VNC服务器端（如果可配置）和客户端，尝试降低色彩深度（如16位色）、关闭或降低图像压缩质量、禁用一些视觉特效，以减少数据传输量和渲染负担。
    • 网络带宽： 确保RDK X5与VNC客户端之间的网络连接稳定且带宽充足。有线网络通常比无线网络更稳定。
  4. 降低桌面分辨率： 如果可能，在RDK X5的桌面环境中（或通过VNC连接后）降低屏幕分辨率，可以显著减少需要传输和渲染的数据量。
  5. 关闭不必要的图形应用： 在VNC会话中，关闭RDK X5桌面上不必要的、占用图形资源的应用程序。
  6. 检查系统负载： 使用 top 或 htop 命令检查RDK X5的CPU和内存占用情况。如果系统本身负载过高，VNC性能自然会受影响。

Q36: 板卡在高负载运行时感觉温度过高，应该如何处理？​

A: 板卡温度过高会影响性能稳定性，甚至可能损坏硬件。处理方法如下：

  1. 检查并改善散热方式：
    • 被动散热 vs. 主动散热： 确认板卡当前的散热方案。对于需要长时间高负载运行（如持续AI推理、视频处理）的场景，仅靠小面积的被动散热片可能不足。强烈建议使用主动散热方案，例如带有风扇的散热片，或者将板卡安装在有良好空气流通的机箱内。
    • 散热片安装： 确保散热片与芯片（CPU/SoC）接触良好，导热硅脂或导热垫片已正确涂抹/放置。
  2. 确保空气流通： 避免将板卡放置在密闭或通风不良的环境中。
  3. 监控温度：
    • 使用系统命令（如 cpu_status_monitor，或读取 /sys/class/thermal/thermal_zoneX/temp 文件内容）来实时监控芯片温度。
    • 了解板卡芯片的安全工作温度范围，避免长时间超出上限。
  4. 优化应用负载：
    • 如果可能，优化您的应用程序，减少不必要的计算，降低CPU/BPU的持续高负载。
    • 考虑是否可以通过算法优化、模型轻量化等方式降低功耗和发热。
  5. 检查供电： 虽然不直接导致发热，但不稳定的供电可能导致芯片工作异常，间接影响温度。

重要提示： “发热量小不代表温度会低”。即使芯片本身设计功耗不高，如果散热不良，热量积聚仍然会导致表面温度快速升高。良好的散热设计是保证嵌入式系统稳定运行的关键。

Q37: 如何在Conda虚拟环境中获取和使用地瓜机器人RDK特定的Python包（如 hobot.GPIO, hobot_dnn 等）？​

A: 地瓜机器人官方提供的 hobot.GPIO、hobot_dnn 等Python包通常是为RDK的系统Python环境预编译和优化的，它们可能依赖于系统底层的特定库文件和驱动程序。在Conda等Python虚拟环境中使用这些包可能会遇到一些挑战，因为虚拟环境旨在隔离依赖。

以下是一些可能的方法和注意事项：

  1. 官方是否提供Conda支持或 .whl 文件：
    • 首先，查阅最新的地瓜机器人官方文档、开发者社区或GitHub仓库，看官方是否提供了针对Conda环境的安装说明，或者是否直接发布了可以在Conda环境中通过 pip 安装的 .whl 格式的这些包。这是最理想的情况。
  2. 尝试在Conda环境中通过 pip 安装系统路径下的包（如果 .whl 不可用）：
    • 如果这些包已经安装在RDK的系统Python环境中（例如在 /usr/lib/python3/dist-packages/ 或类似路径下），并且您的Conda环境使用的Python版本与系统Python及这些包编译时所用的Python版本兼容，有时可以直接在激活Conda环境后，尝试用 pip 指向这些包的路径进行安装，但这通常不被推荐，且成功率不高，因为 pip 主要用于从PyPI或本地.whl/源码包安装。
  3. 修改 PYTHONPATH 或 sys.path (不推荐，易出错)：
    • 一种不规范的方法是，在激活Conda环境后，手动将系统Python环境中这些特定包的路径添加到Conda环境的 PYTHONPATH 环境变量中，或者在Python脚本中动态修改 sys.path。
    • 风险： 这种方法非常容易导致依赖冲突、版本不匹配以及难以追踪的运行时错误，因为Conda环境的隔离性被破坏了。强烈不推荐用于生产或复杂项目。
  4. 使用系统Python环境：
    • 如果您的项目对Python环境隔离的要求不是非常严格，或者主要就是围绕这些RDK特定包进行开发，最简单直接的方法可能就是直接使用RDK系统自带的Python环境，而不是Conda。这些包在系统环境中通常是配置好的。
  5. 容器化方案 (Docker)：
    • 如果地瓜机器人官方提供了包含这些包和完整依赖的Docker镜像，那么在Docker容器中使用这些功能是更可靠的隔离和部署方案。
  6. 从源码编译（如果官方提供源码且允许）：
    • 如果这些特定包的源码是开放的，并且有针对ARM架构的编译指南，理论上您可以尝试在您的Conda环境中从源码编译和安装这些包。但这通常需要较高的技术能力和时间投入。

总结： 优先查找官方对Conda环境的支持。如果官方不支持，直接使用系统Python环境可能是最稳妥的方案。避免通过修改PYTHONPATH等方式强行混合不同环境的包，除非您非常清楚潜在的风险和如何解决冲突。

Q38: 编译自己开发的Linux内核模块（.ko文件）后，加载时遇到“驱动签名报错”或“Required key not available”等问题怎么办？​

A: 较新版本的Linux内核，尤其是在启用了Secure Boot的系统上，或者某些发行版的默认安全策略，会要求加载到内核中的模块（.ko文件）必须具有有效的数字签名。如果您自行编译了一个内核模块但没有对其进行签名，在尝试使用 insmod 或 modprobe 加载时就可能遇到此类错误。

解决方法通常涉及以下步骤：

  1. 生成签名密钥对： 您需要一对公钥和私钥用于签名。可以使用 openssl 工具生成。

    openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=My Module Signing Key/"

    这会生成私钥 MOK.priv 和公钥 MOK.der。

  2. 对内核模块进行签名： Linux内核源码树中通常包含一个签名脚本 scripts/sign-file。您需要使用这个脚本、您的私钥以及刚生成的公钥（或者内核信任的某个公钥）来对编译好的 .ko 文件进行签名。

    # 假设您在内核源码目录下，并且 MOK.priv 和 MOK.der 在当前目录
    # KBUILD_SIGN_PIN 环境变量可能需要设置，用于自动签名过程中的密码交互（如果密钥有密码）
    sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /path/to/your/module.ko

    路径和具体参数可能需要根据您的内核版本和环境进行调整。

  3. 将签名公钥注册到系统的MOK (Machine Owner Key) 列表中： 为了让内核信任您的签名，需要将签名时使用的公钥（MOK.der）导入到系统的MOK列表中。这通常通过 mokutil 工具完成。

    sudo mokutil --import MOK.der

    执行此命令后，系统会提示您设置一个临时密码。请记住这个密码。

  4. 重启系统并在MOK Manager中确认导入： 重启计算机。在启动过程中（通常在UEFI/BIOS之后，操作系统加载之前），系统会进入一个蓝色的MOK Manager界面（Shim）。您需要选择 "Enroll MOK" 或类似选项，然后输入之前设置的临时密码，来确认导入新的公钥。

  5. 加载已签名的模块： 完成以上步骤后，您的内核模块应该已经被有效签名，并且内核会信任这个签名。此时再尝试加载 .ko 文件应该就不会再报签名错误了。

重要提示：

  • 上述步骤是一个通用流程，具体命令和细节可能因您的Linux发行版、内核版本以及Secure Boot的配置状态而有所不同。
  • 请务必参考您所使用的Linux发行版和内核版本的官方文档中关于“内核模块签名 (Kernel Module Signing)”的详细指南。
  • 地瓜机器人官方RDK文档中关于“Linux开发”或“驱动开发”的章节，也可能包含针对RDK平台的具体模块签名指导：RDK文档 - Linux开发 - 内核头文件与模块编译 (请查找此文档中关于模块签名的具体章节)。

Q39: 如何升级RDK X5的MiniBoot？​

A: 在RDK X5上，可以通过 srpi-config 工具来方便地升级MiniBoot（U-Boot的早期引导加载程序部分，负责更底层的硬件初始化和引导）。

步骤如下：

  1. 通过SSH或串口登录到RDK X5的系统终端。
  2. 执行 srpi-config 工具： 
    sudo srpi-config
  3. 导航到MiniBoot更新选项： 在 srpi-config 的菜单中，通常的路径是：
    • 选择 1 System Options (或类似名称的系统选项)
    • 然后选择 S7 Update MiniBoot (或类似名称的MiniBoot更新选项，具体编号和名称可能随 srpi-config 版本略有调整)
  4. 按照提示进行操作： 工具会引导您完成升级过程。这通常需要RDK X5能够连接到互联网，以便下载最新的MiniBoot固件包。
  5. 完成并重启： 升级完成后，按照提示退出 srpi-config 并重启RDK X5使新的MiniBoot生效。

验证升级： 您可以在RDK X5重启后的串口启动日志中，查看U-Boot的版本信息。更新后的MiniBoot通常会显示更新的编译日期和版本号。 例如，更新后的版本信息可能类似 (日期和具体版本号会变化)： U-Boot 2022.10+ (Dec 26 2024 - 16:58:41 +0800)

注意： 升级MiniBoot是一个底层固件操作，请确保在稳定的电源和网络环境下进行，并仔细阅读 srpi-config 工具的提示信息。

Q40: 在编译大型项目（如使用gcc/make/cmake/colcon构建ROS2工作空间）或运行内存消耗较大的工具（如hb_mapper模型转换）时，遇到内存不足的错误怎么办？​

A: 内存不足（Out of Memory, OOM）是嵌入式设备或资源受限的开发机上编译大型项目或运行内存密集型应用时常见的问题。以下是一些解决方法：

  1. 增加Swap交换空间： 当物理内存(RAM)不足时，系统可以使用硬盘上的一部分空间作为虚拟内存（Swap）。这可以缓解OOM问题，但性能会比物理内存慢很多。

    • 创建并启用Swap文件（示例为创建4GB Swap，大小可根据需求调整）： 
      # 1. 创建一个指定大小的空文件
      sudo fallocate -l 4G /swapfile
      # 2. 设置文件权限
      sudo chmod 600 /swapfile
      # 3. 将该文件设置为Swap区域
      sudo mkswap /swapfile
      # 4. 启用Swap文件
      sudo swapon /swapfile
      # 5. (可选) 验证Swap是否已激活
      swapon --show
      free -h
    • 使其开机自动挂载： 编辑 /etc/fstab 文件，在末尾添加一行： 
      /swapfile none swap sw 0 0
    • 关闭Swap（如果需要）： 
      sudo swapoff /swapfile
      sudo rm /swapfile # 如果不再需要，可以删除文件
      # 同时记得从 /etc/fstab 中移除对应行

  2. 减少编译并行度/线程数： 编译过程（尤其是C++项目）通常会启动多个并行的编译任务以加快速度，但这也会消耗大量内存。

    • make 命令： 使用 -j 参数指定并行任务数。例如，单线程编译： 
      make -j1
      可以尝试 -j2, -jN (N为CPU核心数的一半或更少)。
    • colcon build (ROS2)：
      • 限制并行包编译数量： 
        colcon build --parallel-workers 1
      • 禁用并行包编译，改为串行编译（更慢但内存占用更低）： 
        colcon build --executor sequential
      • 结合使用： 
        colcon build --executor sequential --parallel-workers 1
    • cmake： CMake本身不直接控制make的并行度，但最终还是通过make执行。可以在调用make时传递 -j 参数。
    • 设置 MAKEFLAGS 环境变量（临时）： 
      export MAKEFLAGS="-j1"
      # 然后执行 colcon build 或其他编译命令

  3. 针对 hb_mapper (地平线模型转换工具)：

    • 在模型转换的 yaml 配置文件中，查找是否有类似 compiler_parameters -> jobs: 1 的选项，用以限制模型编译（例如ONNX到BIN模型过程中某些阶段）的并行进程数。具体参数名请查阅最新的算法工具链文档。

  4. 关闭不必要的后台服务和应用程序： 在进行编译或运行内存密集型任务前，关闭其他占用内存的程序（如图形界面、浏览器、其他服务等），以释放更多物理内存。

  5. 使用更高配置的开发机/服务器进行编译： 如果是在x86开发机上为RDK进行交叉编译，而开发机本身内存也有限，可以考虑使用内存配置更高的机器。对于板端编译，如果资源实在不足，交叉编译是更好的选择。

  6. 分步编译/模块化编译： 对于非常大的项目，如果构建系统支持，可以尝试只编译项目的一部分，或者将项目分解为更小的模块独立编译。

选择哪种方法或组合取决于具体的错误信息、可用资源以及对编译时间的要求。增加Swap通常是比较通用的缓解方法。

Q41: RDK相关问题进行预排查的通用建议有哪些？​

A: 在遇到RDK相关问题并寻求帮助前，建议进行以下预排查：

  1. 查阅最新官方手册： 确保您参考的是官方最新版本的用户手册、开发文档和发行说明。官方文档通常会包含最新的信息和已知问题的解决方案。您可以从地瓜机器人开发者社区获取最新文档：RDK资料中心
  2. 更新系统及相关软件包： 许多问题可能在较新的软件版本中得到修复。请确保您的RDK板卡上的操作系统以及所有hobot-*、tros-*等关键软件包都已更新到最新稳定版本。通常可以通过以下命令进行更新： 
    sudo apt update && sudo apt upgrade
    在提问时，请一并提供通过 rdkos_info、apt list --installed | grep hobot 等命令获取的当前系统和软件包版本信息。
  3. 仔细检查硬件连接： 确保所有硬件连接都牢固可靠，包括电源线、SD卡、调试串口线、摄像头排线、网络线以及其他外设连接。接触不良是许多问题的根源。
  4. 提供完整的问题复现信息： 当您向社区或技术支持提问时，请尽可能提供以下信息：
    • 清晰的问题描述： 遇到了什么问题？期望的结果是什么？实际观察到的现象是什么？
    • RDK硬件型号和系统版本： 例如RDK X5, RDK OS 3.0.1。
    • 相关的软件包版本。
    • 详细的复现步骤： 一步一步说明如何操作才能触发问题。
    • 完整的错误日志或截图： 包括串口打印、dmesg信息、应用程序的报错输出等。
    • 您已尝试过的解决方法及其结果。 提供充分的信息有助于他人更快地理解和定位您的问题。

Q42: Docker镜像、OE包或嵌入式开发Samples包下载失败或速度慢怎么办？​

A:

  1. Docker镜像（例如用于算法工具链、交叉编译环境）：
    • 官方来源： Docker镜像通常首发于Docker Hub。地瓜机器人官方也可能在自己的服务器或特定的开发者社区资源帖中提供部分关键镜像的下载链接或拉取方式。
    • 网络问题： 如果从Docker Hub拉取速度慢或失败，可能是由于网络限制或国际带宽问题。可以尝试配置Docker使用国内的镜像加速器服务（如阿里云、DaoCloud、网易蜂巢等都提供此类服务）。
    • 社区资源： 关注地瓜机器人开发者社区的公告或资源下载区，有时会提供针对国内用户的镜像获取方案。例如，此帖曾提供过相关资源：地瓜机器人开发者社区论坛相关帖子 (请确认链接及内容的最新有效性)。
  2. OE (OpenEmbedded) 包 / BSP (Board Support Package)：
    • OE编译环境相关的包或完整的BSP（包含内核源码、驱动、文件系统构建脚本等）通常体积较大。如果官方提供直接下载，请确保您的网络连接稳定且具有足够的带宽。
    • 这些资源一般会在开发者社区的“资源中心”板块或对应RDK型号的产品文档页提供下载链接。
  3. 嵌入式开发Samples包（示例代码）：
    • 示例代码包可能作为BSP的一部分提供（例如在BSP解压后的 bsp/samples/ 或类似目录下）。
    • 也可能作为独立的SDK、代码仓库（如GitHub上的 D-Robotics 组织）或压缩包提供。
    • 请仔细查阅对应RDK型号和版本的官方文档或快速入门指南，以找到获取官方示例代码的正确途径。
  4. 通用下载建议：
    • 使用下载工具： 对于较大的文件，建议使用支持断点续传的下载工具。
    • 检查网络环境： 如果您在公司或机构网络下，确认是否有防火墙、代理服务器或网络策略限制了大文件的下载或访问特定域名。
    • 错峰下载： 尝试在网络负载较低的时段进行下载。
    • 官方渠道优先： 始终优先从地瓜机器人官方开发者社区、官方文档中提供的链接或官方GitHub仓库获取各类开发资源，以确保文件的正确性、完整性和安全性。

Q43: 为RDK进行交叉编译的环境应该如何配置？​

A: 为RDK板卡（通常是ARM架构）上的应用程序进行交叉编译，一般需要在x86架构的Linux开发主机（推荐使用Ubuntu LTS版本，如Ubuntu 20.04或22.04）上配置交叉编译工具链和相应的目标系统SDK（Sysroot）。具体配置步骤会因您要编译的程序类型（例如，普通的Linux C/C++程序、ROS/TROS功能包）以及目标RDK的型号和系统版本而有所不同。

  1. 编译普通Linux C/C++应用程序：

    • 获取交叉编译工具链： 地瓜机器人官方会为每个RDK系列（如X3、X5、Ultra）提供相应的交叉编译工具链（例如，包含aarch64-linux-gnu-gcc, aarch64-linux-gnu-g++等工具）。这个工具链可能作为SDK的一部分提供，或者需要从开发者社区单独下载。
    • 安装与配置工具链： 按照官方文档的指引，将下载的工具链压缩包解压到您开发主机上的一个合适路径（例如 /opt/toolchains/）。然后，需要将工具链的 bin 目录（包含编译器等可执行文件）添加到您开发主机的 PATH 环境变量中，这样系统才能找到这些交叉编译命令。
    • 准备Sysroot： 交叉编译不仅需要编译器，还需要目标板卡系统环境中的库文件（如glibc, libstdc++, 以及其他依赖库）和头文件。这部分内容集合称为Sysroot。Sysroot可以从官方提供的RDK SDK中提取，或者从一个已经烧录好系统的RDK板卡的根文件系统中复制得到。在编译时，需要通过编译器的 --sysroot=<path_to_sysroot> 参数来指定Sysroot的路径。
    • 使用CMake进行交叉编译： 如果您的项目使用CMake作为构建系统，推荐创建一个CMake工具链配置文件（toolchain file，例如 aarch64-rdk.cmake）。在这个文件中，您需要指定：
      • 目标系统名称 (CMAKE_SYSTEM_NAME 通常设为 Linux)。
      • 目标处理器架构 (CMAKE_SYSTEM_PROCESSOR 通常设为 aarch64)。
      • C交叉编译器 (CMAKE_C_COMPILER) 和 C++交叉编译器 (CMAKE_CXX_COMPILER) 的完整路径。
      • Sysroot路径 (CMAKE_SYSROOT)。
      • 查找库和头文件的相关路径设置 (CMAKE_FIND_ROOT_PATH)。 然后在运行CMake配置项目时，通过 -DCMAKE_TOOLCHAIN_FILE=/path/to/your/aarch64-rdk.cmake 参数来指定使用这个工具链文件。
    • 参考官方手册： 详细的交叉编译环境搭建步骤、工具链文件示例以及编译参数，请务必参考您所使用的RDK型号和版本的官方《用户手册》或《SDK开发指南》中关于“Linux应用开发”或“交叉编译环境搭建”的章节。

  2. 编译ROS/TROS功能包：

    • 使用官方提供的Docker交叉编译环境（强烈推荐）： 这是为TROS功能包进行交叉编译最推荐且最便捷的方式。地瓜机器人官方通常会提供预配置好的Docker镜像，这些镜像中已经集成了：
      • 特定TROS版本（如Foxy, Humble）所需的交叉编译工具链。
      • Ament/Colcon等ROS构建工具。
      • 目标板卡TROS环境对应的所有基础ROS库和依赖项的交叉编译版本。
      • 操作流程：
        1. 从官方渠道（如Docker Hub或地瓜机器人官方服务器）拉取对应TROS版本的交叉编译Docker镜像。
        2. 按照官方文档的指引启动Docker容器，并将您的ROS工作区源代码目录挂载到容器内部。
        3. 在Docker容器的终端内，使用 colcon build 配合适当的交叉编译参数（通常Docker环境已预设好）来编译您的工作区。
      • 参考官方手册： TROS用户手册中关于“源码安装”、“开发者指南”或“交叉编译”的章节通常会有详细的Docker使用方法和命令示例。例如，此链接可能包含相关信息：TROS手册 - 交叉编译Docker参考 (请确认链接的有效性和相关性)。
    • 手动配置ROS/TROS交叉编译环境 (极不推荐，非常复杂且极易出错)： 如果不使用官方提供的Docker环境，手动从零开始搭建一个完整的ROS/TROS交叉编译环境是一项非常复杂和耗时的工作。您需要自行交叉编译ROS的所有核心组件、消息类型、依赖库，并为Colcon等构建工具配置大量的交叉编译参数和环境变量。这通常只适用于有深厚交叉编译和ROS构建系统经验的开发者。

通用交叉编译建议：

  • 仔细阅读官方文档： 针对您使用的RDK型号和目标系统版本，务必以官方最新发布的开发文档、SDK说明和移植指南为准。
  • 保持环境一致性： 交叉编译环境中所使用的库（尤其是系统库和核心依赖库）的版本，应尽可能与目标RDK板卡上实际运行的库版本保持一致或兼容，以避免运行时出现链接错误或行为不一致的问题。
  • Sysroot的正确配置至关重要： 无论是编译普通Linux程序还是ROS包，正确配置和使用Sysroot是交叉编译成功的关键环节。
Last updated on