基于RDX X5的3D桌宠

让角色、歌词与一句鼓励，成为办公桌上可以触碰的陪伴。

项目报告 · 2026 年 11 月修订

办公桌上的屏幕可以承载更多轻松的体验：一个安静活动的小角色，一段随音乐展开的歌词，或一句提醒自己放松的标语。本项目把这些内容放进三维场景，让用户用手势改变它们的位置与大小，给日常办公增加一点新意。

硬件采用 RDK X5 Module + MB，通过 MIPI 摄像头感知手部动作，BPU 完成手掌与关键点识别，raylib 负责呈现三维内容。角色、歌词和标语是三个独立场景，共享一套捏合、挥手和双手缩放的交互方式。

图 1｜X5 实际运行画面。手部骨架来自实时摄像头与 BPU 输出，图中记录了双手交互。画面为板端 GPU 帧回读。

当前原型已经接通摄像头、识别与三维显示，真实输入触发过抓取和缩放。项目定位是具有手势交互的桌宠原型，尚未加入语音对话与大语言模型。

01 / 让操作接近日常动作

桌宠适合轻量、直观的操作。用户不需要记住菜单位置，手伸入画面，就能通过可见的骨架了解系统是否正在识别自己。

图 2｜交互图示与图标方案。圆点强调指尖位置，箭头表示运动方向；图示用于表达操作逻辑。

交互的重点是连续感与确定感。镜像映射让画面中的移动方向接近用户直觉；坐标平滑减少细小抖动；短暂漏检得到有限容错；摄像头断流时释放内容，避免物体一直停留在被抓取的状态。

图标设计围绕“抓取、切换、缩放”三个动作展开，采用统一线宽、圆角和少量强调色。金色承担抓取反馈，方向箭头表达切换，向外与向内的箭头表达缩放。图标作为骨架和内容反馈的补充，帮助用户直观理解操作。

目前捏合连续性仍会受手掌角度和遮挡影响。挥手切换通过了模拟输入检查，真人触发还不够稳定；后续挥手改动尚需完成板端验证。真实抓取与缩放已有事件记录，尚未形成完整的真人手势成功率统计。

02 / 三种场景，三种桌边情绪

角色负责陪伴。 机器人以轻量的待机动画维持存在感，用户可以把它拖到喜欢的位置，也可以调整大小。角色选用 Quaternius 的 CC0 机器人资产，保留骨骼动画；简洁造型和纯色材质有利于控制绘制负担，也符合桌面摆件的视觉定位。

歌词负责节奏。 歌词进入三维空间，当前句成为视觉中心，前后句形成层次，逐字高亮和轻微波动让文字跟随音乐展开。界面把注意力留给文字，避免复杂控件抢走画面的情绪。

图 3｜X5 上的歌词场景，1920×1080。图中骨架来自基准测试使用的模拟输入。

歌词采用适合动态文字的距离场字形，在清晰度和绘制成本之间取得平衡。每个字可以独立排列、运动和高亮，播放进度由音频时钟驱动，减少画面与音乐脱节的感觉。

当前示例使用原创合成器乐与示例歌词，逐字高亮按行时长分配，尚未实现真实演唱的逐字时间对齐。这里的重点是空间排布、节奏反馈与手势控制所形成的观看体验。

03 / 让一句标语拥有体积

标语负责表达。 相比持续变化的歌词，短句适合成为一个可以摆放、移动和放大的三维对象。“今天也辛苦了”这类内容，不只是一条通知，也可以是桌边温和的情绪提示。

图 4｜X5 上的立体标语。字形具有正面、侧面和厚度，图中骨架来自模拟输入。

标语使用字体轮廓生成三维网格，侧面的明暗变化让文字具有实体感。复杂的字形处理在开发端完成，X5 负责加载、绘制与交互，减少设备运行时的额外负担。

三个场景使用同一套操作习惯，让用户切换内容时不必重新学习。当前抓取与缩放针对整组内容，新增标语需要重新生成资产；逐字抓取和任意长文实时建模不属于当前原型范围。

04 / X5 把感知与显示连接起来

最终方案采用 MIPI 摄像头 + BPU 手部识别 + raylib 三维显示。视觉识别与画面绘制独立运行，识别结果更新手部状态，显示端持续绘制角色、文字和骨架，让识别节奏与显示节奏相互解耦。

图 5｜最终方案的主线。摄像头提供图像，BPU 提取关键点，交互层理解动作，GPU 呈现反馈。

平台适配集中在三个方面：让应用使用厂商 GPU 加速路径，让相机输出正确进入模型，让关键点稳定映射到屏幕空间。画面比例、镜像方向和抓取反馈共同决定“手能否自然地控制内容”，它们与模型识别同样重要。

开发端使用 WSL 处理资产、整理记录与模拟关键点；X5 承担相机、BPU 和实际显示验证。相同的交互入口也支持历史数据回放，便于复现不连续的动作。

双目硬件已接入，立体测距尚未使用。 左右两路采集已经跑通，当前交互只选择一路图像，在同一画面中识别最多两只手。骨架的相对深度来自模型估计，交互仍基于图像平面，尚不能测量手到屏幕的真实距离。

05 / 技术取舍服务于观看体验

项目选择 raylib，是因为三种场景的规模明确，轻量的绘制与内容管理更适合当前原型。角色网格与材质提交经过整理，歌词与标语也分别采用适合自身特点的表现方式，使 X5 的资源更多用于画面与交互。

原生 1920×1080、保留动画与模拟手骨架的 30 秒显示基准中，角色平均 58.33 FPS，歌词 55.50 FPS，标语 54.63 FPS。这些结果接近流畅展示的目标，但仍存在较长帧，不能写成稳定锁定 60 FPS。

显示基准未并行运行相机与 BPU；并行数据来自角色场景，两组结果的条件不同。与历史 Godot 原型相比，raylib 方案的画面流畅度明显改善，但场景实现也经过优化，不能将差异完全归因于引擎。

06 / 对 X5 平台的评价

这次实践中，X5 值得肯定的地方，是能够在一块板上完成从手部感知到三维反馈的完整交互闭环。摄像头获取画面，BPU 提取手部关键点，GPU 呈现角色与文字，用户的动作因此能够在桌边得到直接回应。

历史路线也说明了平台的可拓展性。Godot 与 Qt Quick 都曾实现硬件输出，最终选择 raylib 是针对本项目内容规模和帧率目标的取舍。X5 为多种应用组织方式提供了基础；厂商相机链路与模型移植资源，也让项目能够把更多精力投入交互与视觉表达。

与此同时，图形驱动与应用的匹配仍需要工程适配，复杂场景的提交开销、手势连续性和高温下的持续表现也不能忽略。这些边界决定了它更适合从目标清晰的轻量应用切入，通过内容设计与负载优化形成稳定体验。

对于一款强调陪伴感、空间文字和自然手势的桌面原型，X5 已展现出有说服力的综合能力：它既能承担实际的视觉识别，也能驱动原生 1080p 三维画面，让“桌宠”从屏幕动画走向能够感知用户动作的交互装置。

项目后续的重点是提升捏合与挥手的稳定性、完善状态图标与视觉反馈，以及验证散热改善后的持续运行表现。真实双目深度则面向更进一步的空间交互：让用户不仅能拖动内容，也能通过前后伸手改变内容的距离。

项目资料： raylib 显示实测、相机与 raylib 联动、手势验证记录、图形平台验证。

开源与资产： 显示采用 raylib，视觉采用 D-Robotics 移植的 MediaPipe 系列模型；机器人资产为 CC0，字体采用文泉驿。相应许可与模型来源保留在项目中。