第一次把整套“智能交互仿生人头”完整摆在展台上的时候，我坐在旁边看了它差不多十分钟没说话。通电瞬间，眼皮位置的圆形屏幕从黑屏里亮起来，眼珠缓慢转动，然后整个头部朝路过的人偏了过去——那一刻你会觉得它不像在执行程序，而是在“确认”你是谁。

这个作品的核心是一块 RK3588 主控板，加上两颗 MIPI 圆形屏幕做眼睛、一组舵机云台做颈部运动、麦克风阵列做语音采集、扬声器做语音回复，再把 YOLOv8 人脸检测和离线语音链路一起塞进边缘端。整套系统不依赖云服务器就能完成从“看到人”到“打招呼”的完整交互闭环。这篇文章不打算只晒效果图，我想把从芯片选型、模型部署、屏幕适配到电源设计的完整过程拆开讲清楚，尤其是那些资料里查不到、只有实际跑起来才会碰到的坑。如果你也准备用 RK3588 做边缘交互设备，或者想复现一个类似仿生人头，这篇应该能帮你少走不少弯路。

1. 项目形态与交互链路拆解

1.1 通电之后它先“看”你，再“答”你

做仿生交互设备，最容易犯的错是把所有精力放在“外观像人”上，结果里面只是几颗灯珠加一个蓝牙音箱。我这个作品在设计时定了条原则：外观可以简化，但交互链路必须完整。所以最终呈现的头部是 3D 打印外壳配半透硅胶面皮，真正的重点在五官对应的传感器和执行器上。

眼睛用的是两块 1.54 寸圆形 LCD 屏幕，分辨率 240×240，MIPI-DSI 接口，用来动态渲染眼珠和眼皮状态。额头位置装了一颗 1080p USB 广角摄像头，负责捕捉视野内的人脸；左右耳位置各有一颗驻极体麦克风，和底座的 ReSpeaker 4-Mic 阵列配合做声源定位与拾音。嘴部区域藏了一块小尺寸 HDMI 屏幕，平时显示嘴唇和牙齿的动画，说话时按语音能量驱动口型开合。颈部是一台两自由度舵机云台，负责偏航和俯仰，让头部能转向说话的人；眉毛处还有两颗微型舵机，用来做挑眉、皱眉这类微表情。

这套硬件组合看起来零散，但每个部分都对应交互链路里的一环：摄像头负责“看”，麦克风负责“听”，RK3588 负责“想”，两路屏幕和舵机负责“表达”。整台设备从外观上更像一颗“头”，但从系统角度看，它是一个典型的边缘多模态交互终端。

1.2 交互主链路：视觉、音频、表情、运动的闭环

我设计的交互流程是纯离线的，不订阅任何云服务，这也是 RK3588 这类边缘板能扛下整条链路的原因。完整闭环分三条支线：

第一条是视觉支线。摄像头以 30fps 采集画面，YOLOv8n 模型在 NPU 上做目标检测，识别人脸和上半身；检测到人脸后，算法会算出目标在画面中的水平偏移量，脖子云台转头对准他，同时眼睛屏幕上的瞳孔也会朝对应方向偏转，形成“注视”效果。如果特征库里已经有这个人，系统会调用 ArcFace 模型做身份比对，用语音说出对应的欢迎语。

第二条是语音支线。底座麦克风阵列持续做唤醒监听，识别到唤醒词后开始采集一段语音，离线 ASR 模型把音频转成文字，经过本地规则引擎或者 FAQ 知识库匹配出回答，再交给离线 TTS 引擎合成语音，从扬声器播放出来。播报的同时嘴部屏幕会根据音频能量实时开合，避免“面无表情念台词”的僵尸感。

第三条是表情和运动支线。这部分由一条独立的状态机控制：头部随机扫视、目标锁定时注视、对话中点头、识别失败时摇头。所有运动都带缓启动插值，不会突然猛转。三条支线通过多线程汇到一个主循环里，用共享内存传递目标坐标和文本结果，实测从“看到人进画面”到“转头并说出第一句话”的端到端延迟大约 600ms，现场演示时观众感知不到明显卡顿。

1.3 硬件清单与成本：这桌子上的东西都从哪来

很多人问这套东西贵不贵，我直接把项目初版物料列出来，方便想复刻的人做预算。主控用的是野火鲁班猫 5 开发板，RK3588 芯片，16GB 内存版本；为什么选这块板子，下一节展开说。两颗圆形 MIPI 屏幕花了约 200 元，麦克风阵列是 ReSpeaker USB 版本，舵机云台用的国产大扭力舵机加金属支架，外壳是自己建模后 3D 打印的，加上电源模块、散热风扇、功放小喇叭，总计不到 4000 元。

这个成本在桌面级机器人里算很克制了，而且 RK3588 的算力冗余很大，后续加麦克风阵列升级、加激光雷达、甚至接底盘移动，都不用换主控。

2. 主控为什么选 RK3588：算力、接口和生态的三重平衡

2.1 先列需求，再选芯片，而不是反过来

我做选型时先列了一张需求清单：第一，要同时跑目标检测、人脸特征提取、ASR、TTS 四个模型，必须要有 NPU 或者强劲 GPU；第二，要驱动两路显示输出，眼睛屏走 MIPI-DSI，嘴部屏走 HDMI；第三，要接 USB 摄像头、USB 麦克风阵列、I2C 舵机驱动板，外设接口要丰富；第四，设备要在展台连续开机，散热和稳定性要可控；第五，整套方案不能太贵，而且芯片要能稳定买到。

按这张清单去筛，RK3588 几乎是唯一一个所有条件都满足的选项。它内部是 4 颗 A76 大核加 4 颗 A55 小核的八核架构，CPU 性能足够跑复杂的后处理和逻辑代码；NPU 算力标称 6 TOPS，INT8 精度下处理 YOLOv8n 单帧只需十几毫秒；自带的 VPU 支持 H.264/H.265 硬解码，接 RTSP 网络摄像头时能把解码压力从 CPU 卸掉，这点在跑长时间视频流时特别重要。

接口方面 RK3588 给了两个 MIPI-DSI 控制器、两个 MIPI-CSI 控制器、双 HDMI、双 USB 3.0、多路 I2C/UART/SPI/PWM，几乎是为这种“头部机器人”量身准备的。我的方案里眼睛屏走 DSI、嘴部屏走 HDMI、摄像头走 USB、舵机板走 I2C，所有外设都有原生接口，不需要昂贵的转接芯片。

2.2 对比树莓派5、Jetson Orin Nano和Intel N100的结论

选型过程中我实际接触过三款替代方案：树莓派 5、NVIDIA Jetson Orin Nano 8G、Intel N100 小主机。它们各有优势，但在这个项目里都被 PK 掉了。

树莓派 5 的痛点是没有专用 NPU，YOLOv8n 跑在 CPU 上单帧推理大约需要 800ms 以上，根本做不到实时交互；而且它对 MIPI-DSI 屏幕的支持比较弱，官方 7 寸屏适配尚可，第三方面板就要自己折腾驱动。Jetson Orin Nano 的 GPU/NPU 性能确实强，生态也成熟，问题出在价格和接口：8GB 版本空板单价上了 3000 元，且只有一个 MIPI-CSI 通道，圆形 DSI 屏幕适配资料少，长期供货也不太稳定。Intel N100 小主机用 x86 生态跑 OpenVINO 很顺，但 CPU 推理实时性依然不如 NPU，整机功耗偏高，放在一个会转动的头部里对供电和散热都不友好。

最终结论很明确：RK3588 是在“实时 AI 推理能力、外设覆盖度、成本、供货稳定性”这四个维度上综合得分最高的选择。它可能不是单项冠军，但它是唯一一个没有短板的选项。

2.3 鲁班猫5开发板在项目里的角色

用 RK3588 芯片有两种路子：自己画板，或者买现成开发板。自己画板的好处是尺寸和接口完全可控，缺点是 RK3588 的布局布线门槛很高，DDR 走线要做等长和阻抗控制，普通工作室第一次打板基本都会翻车。所以我项目的定位是“快速做出一台能稳定演示的交互设备”，直接选了野火鲁班猫 5。

这块板子把 RK3588 的接口基本都引出来了，还带官方 Ubuntu 镜像和预编译好的 NPU/GPU 驱动。最关键的是它提供了 MIPI 屏幕的适配例程，我在它基础上改设备树，比自己从零写面板驱动省了一半时间。板载接口的分配也要提前确认：鲁班猫 5 的 40pin 排针带 I2C 和 PWM，屏幕接口和摄像头接口是分开排布，电源输入支持 12V，省掉一路转压。

如果后续要量产，我可以拿着鲁班猫 5 验证过的软件栈，再基于 RK3588 参考设计画精简版底板，软件层面基本不用改。这也是我推荐大家用“开发板起步”的原因——先用成熟硬件跑通算法和交互，再考虑硬件定制。

3. 视觉子系统：YOLOv8落到RK3588 NPU上的完整链路

3.1 模型分工：一个检测，一个识别，一条都不能少

视觉子系统拆成两个模型，避免用一个大模型强行完成所有任务。第一个是 YOLOv8n 检测模型，负责在每一帧画面里找“人”和“人脸”，输出目标框和置信度。第二个是 ArcFace 风格的人脸特征提取模型，只在检测到人脸存在时才启动，把 112×112 的人脸区域映射成 512 维特征向量，再和本地特征库做余弦相似度比对。

模型拆开的直接好处是算力分配灵活：检测模型每帧都跑，必须足够快，所以用最小的 n 版本；特征提取模型不是每帧都需要，只在“判断来的是谁”时才调用，稍微慢一点没关系，精度反而可以选大模型。有些项目想用一个模型包打天下，最后要么速度跟不上，要么识别精度不满足演示效果，不如分开处理。

另外提一句，现在 Ultralytics 已经出了 YOLO11 甚至更新版本的检测模型，转换流程和 YOLOv8 一脉相承，如果你是新项目可以直接用新版。我这边继续用 YOLOv8 是因为鲁班猫 5 官方例程和 RKNN 模型库里对它的支持最成熟，踩过的坑也最少。

3.2 从YOLOv8到RKNN：转换、量化、算子兼容

RK3588 的 NPU 不认识 PyTorch 的 .pt 文件，需要先把模型转换为 RKNN 格式。完整链路是：PyTorch 权重 -> ONNX -> RKNN（带量化校准）。这一步初看简单，实际上 80% 的部署报错都发生在这里。

第一步在 PC 上导出 ONNX 文件。用 ultralytics 自带的导出命令，固定输入尺寸为 640×640，opset 尽量选 12 或更高，导出后最好用 onnxsim 做一次简化，把多余的形状算子清掉。我当时的命令是：

yolo export model=yolov8n.pt format=onnx opset=12 imgsz=640 python -m onnxsim yolov8n.onnx yolov8n_sim.onnx

第二步在 PC 上安装 rknn-toolkit2，这是瑞芯微官方提供的模型转换工具。转换脚本的核心逻辑是先初始化 RKNN 对象，配置 target_platform 为 rk3588，再加载 ONNX 模型做量化构建。这里有个非常关键的细节：量化校准要提供一份贴近真实场景的图片列表 dataset.txt，每行一张图，图片要覆盖不同光照、不同距离、不同背景。很多人直接拿 COCO 验证集里的图去做校准，部署到现场后发现检测率下降，就是因为校准集和真实场景差异太大。

第三步把转换好的 .rknn 文件拷贝到开发板上，之后板端运行时就完全不需要 PyTorch 环境了。

3.3 板端推理与后处理：模型只做80%，剩下20%在CPU

RKNN 模型最终只输出各个检测头的特征图，YOLOv8 的 DFL（Distribution Focal Loss）解码和 NMS（非极大值抑制）必须在 CPU 上完成。转换时如果把后处理也写进模型里，RKNN 工具链大概率会因为算子不兼容直接报错。

板端推理的代码结构其实很固定：初始化 NPU 运行时、加载模型、每帧设置输入图像、执行推理、取输出做后处理。输入图像要先做 letterbox 缩放并转成 RGB，归一化方式和训练时保持一致。我这里在归一化上踩过一次很深的坑：RKNN 可以在配置层就做归一化，mean 和 std 参数填 0 和 255 就等效于输入前除以 255；如果模型预处理里又除了一次，等于做了两遍归一化，推理结果直接变成乱框。

后处理部分的要点是把 (1, 4+80, 8400) 这样的输出张量重新组织：80 是类别数，8400 是 640×640 输入下三个尺度特征图上的总锚点数，4 是边界框的 DFL 参数。每个位置先用 DFL 公式解码出 cx、cy、w、h，再过滤低置信度框，最后做一次类别无关的 NMS。纯 CPU 跑 NMS 大概耗时 5ms 左右，整体单帧延迟控制在 20ms 到 30ms 之间，对这个交互场景完全足够。

3.4 精度与速度调优：混合量化、输入归一化和VPU硬解码

模型部署到 RK3588 后，我最先遇到的性能问题不是速度，而是精度。YOLOv8n 全模型 INT8 量化后，在远距离小目标上的召回率明显变差，人脸在画面里只有几十个像素时经常漏检。解决办法不是放弃量化，而是做混合量化：把模型后半部分（尤其是检测头）保持 FP16 精度，前半部分主干继续用 INT8 加速。

具体操作是在转换脚本里指定量化层范围，我试下来“主干全量 INT8 + 检测头 FP16”的配置性价比最高，精度只掉了 3% 左右，推理速度从全 FP16 的 35ms 降到 22ms。如果目标更小，还能进一步把后三个 CSP 层都保留为 FP16，代价是速度多 5ms，但几乎没有漏检了。

输入源方面还有一条升级路径：如果你的摄像头是 RTSP 网络摄像头，RK3588 的 VPU 可以直接硬解码 H.264/H.265 流。我最初用 USB 摄像头只是图省事，后来测试接入 IP 摄像头时发现 VPU 硬解 1080p 视频只占 CPU 的 5% 不到，整机 CPU 余量立刻大了一圈，做语音识别时不会有明显卡顿。建议这个项目后续版本直接换 MIPI-CSI 摄像头加 IP 摄像头双路视觉输入，VPU 的资源别浪费。

4. 眼睛和表情：MIPI屏幕适配与仿生外观

4.1 眼睛屏幕方案：为什么选MIPI-DSI圆形屏

仿生人头的表情核心在眼睛。第一版我试过 OLED 和普通 SPI 小屏，像素低、刷新慢、观感像电子表；最后换成 1.54 寸 MIPI-DSI 圆形 LCD，240×240 分辨率，圆形面板本身就像人的眼白轮廓。MIPI-DSI 是高带宽差分信号接口，刷新率和色彩表现远超 SPI，动态显示眼珠时不会拖影，这是仿生观感的基础。

两块眼睛屏分别接到 RK3588 的 DSI 通道上，软件层面把左右眼当作两个独立 framebuffer 来绘制。眼睛的显示内容不是简单一张图片，而是一个实时渲染程序：瞳孔位置由目标人脸在画面中的坐标换算而来，眨眼由定时器驱动眼皮遮罩插值，RGB 通道可以微调眼白颜色避免惨白。渲染用 SDL 或 GTK 都能实现，关键是要保证两个屏幕的帧同步，可以用双线程各写一个 framebuffer，再通过主循环同步刷新。

嘴部屏幕我用了更省事的 HDMI 小屏，理由很简单：HDMI 是即插即现的，Linux 下直接识别为第二显示器，不需要像 MIPI 面板那样改设备树。唯一麻烦的是 5 寸屏刷新率和分辨率偏常规，驱动口型动画时需要在窗口层做过边界裁剪，但整体工作量比再调一块 DSI 屏小得多。

4.2 鲁班猫5 Linux设备树的屏幕适配

在 Linux 下用非官方 MIPI 屏幕，最大的工作量是设备树适配。鲁班猫 5 的 Ubuntu 系统启动时，内核通过设备树描述硬件拓扑；屏幕上电、复位信号、背光、DSI 数据通道的初始化序列全部藏在设备树节点里。官方例程提供的是一块固定型号面板的节点，换面板必须改节点。

一个典型的 DSI 面板节点包括：compatible 字符串（对应驱动源码里匹配的名字）、reset-gpio 和 enable-gpio 引脚（控制面板电源和复位）、backlight 属性（关联 PWM 背光）、以及 port 节点下的 remote-endpoint（把面板挂到 DSI 控制器的输出端口上）。改完设备树后编译成 dtb 文件，替换 /boot 下对应文件再重启。

我适配圆形屏时遇到的最典型问题是白屏和花屏。白屏基本是初始化序列没被执行，检查 reset 引脚的电平时序和 GPIO 编号是否正确；花屏则是 DSI 数据格式不匹配，面板是 RGB888 而我配成了 RGB666，或者 DSI 差分时钟频率偏低导致传输带宽不足。调试的时候先加串口日志确认驱动 probe 成功，再用纯色测试图逐项验证，不要一上来就指望直接显示动画。

这里也要说句实话：从淘宝上随便买一块没有文档的裸屏，适配周期可能高达两三周，不值得。建议直接选有 Linux 驱动源码或历史适配案例的面板型号，哪怕贵几十块钱，省下的是串联调试时间。

4.3 表情动效：眼珠跟随、口型联动、眉毛微调

屏幕只是载体，表情动效才是仿生感的来源。我做了一个简单的表情管理器，负责三件事。

眼珠跟随的核心是把摄像头图像里的目标位置映射成瞳孔偏移。当 YOLOv8 检测到人脸时，我会算出人脸中心相对画面中心的归一化坐标，乘上一个增益系数，再限制在瞳孔活动范围内。这个偏移量同时喂给两个眼睛屏和颈部云台，头部转向的同时眼珠也会先动，视觉上就形成了自然的“先看过去”过程。如果画面里没有目标，眼珠会做缓慢的随机扫视，每 3 到 5 秒换一个方向。

口型联动直接挂钩音频输出能量。TTS 播放语音时，我通过 PulseAudio 的监控源拿到实时音量分贝值，映射成嘴巴张开幅度，再用三阶贝塞尔曲线让张开和闭合过程更圆润。实测下来口型和语音基本同步，观众第一反应通常是“它在真的说话”，而不是看到一块屏幕在闪。

眉毛位置用了两颗微型舵机，执行点头、摇头、挑眉动作。这部分不要追求太高的机械精度，反而有点机械感会让整个头部看起来更“活”。我把舵机动作也做成带位置插值的状态机，避免 5ms 内从 0 到 90 度的大跳变，那不只是难看，对舵机齿轮也是暴力磨损。

5. 语音交互和运动控制：把“点头”和“开口”串起来

5.1 离线ASR/TTS链路：唤醒、识别、合成、回声消除

语音链路我坚持全离线方案。原因有三：一是现场演示时网络不稳定会直接翻车；二是人声数据不出本地，隐私上更说得过去；三是离线链路的延迟更可预测，交互体验更顺。

唤醒阶段用的是 openWakeWord 的本地模型，在 ReSpeaker 4-Mic 阵列上跑 24kHz 音频流，识别到“你好小智”之类的唤醒词才进入录音状态。ASR 部分用了 sherpa-onnx 运行时加载中文 Paraformer 模型，一句话识别大约 0.8 到 1.5 秒，在可接受范围内。TTS 部分用的也是 sherpa-onnx 生态里的离线中文语音合成，每个字合成时间约 0.2 秒，念完一句十来个字的欢迎语完全没有机械感。

这条链路里最容易忽略的是回声消除。刚开始测试时，设备一播放 TTS，自己的 ASR 模块马上把扬声器声音也识别成用户指令，反复自问自答。解决办法有两个方向：一是改用带硬件 AEC 的麦克风阵列，二是在音频处理链路里加 WebRTC AEC3。我最终是“硬件阵列硬件回采”加“软件降噪”双管齐下，播放 TTS 时再对 ASR 模块做静音抑制，彻底解决自激问题。如果你用的是普通 USB 麦克风，这块一定要规划好，否则语音交互会变成灾难。

5.2 颈部云台和微表情舵机的控制策略

颈部运动是整个头部交互里最容易被低估的部分。要是只用“检测到人就直接转过去”的粗暴逻辑，头部会像受惊的鸟一样乱晃，而且舵机电流冲击很可能导致主控掉电。我实现的是一套带缓启动和死区的控制策略。

硬件上颈部两轴舵机挂在 PCA9685 十六路 PWM 驱动板上，通过 I2C 和 RK3588 通信。PCA9685 的好处是它可以同时产生 16 路独立 PWM，颈部两轴加眉毛两轴只用四个通道，剩下一堆通道还能预留做耳朵、眼睑甚至下颚开合。软件上先设置 50Hz 的 PWM 频率，再把角度映射成 150 到 600 的脉冲宽度范围，按舵机实际行程纠正线性度。

运动策略分两级。检测到目标时，系统根据人脸横向偏移量乘以比例系数生成目标角度，再加一段指数平滑滤波，让转头的角速度先快后慢，符合人的自然动作；没目标时，头部自动回到待机角度，做缓慢巡回扫描。眉毛舵机则固定在表情状态机里，根据对话情绪触发：问句尾音上扬时挑一下眉，识别失败时连续皱眉两次。所有动作在进入舵机驱动前都必须经过位置插值，我封装了一个 ease-out 函数，每 10ms 更新一次目标，从源头杜绝抖动。

5.3 电源与散热：为什么仿生人头最容易在这里翻车

很多作品死因不在代码，在电源。我第一版原型机电源方案是“一个 5V/3A 适配器给所有东西供电”，结果演示时一转头，屏幕立刻花屏，半小时后直接重启。原因很清楚：两个舵机动作瞬间电流叠加超过 2A，把系统电压拖到边缘板欠压阈值以下。

电源重构后的方案是分级供电。12V/5A 适配器进整机，前端直接给 RK3588 鲁班猫 5 板载供电；同时引出一路 12V 到 DC-DC 降压模块，单独降压到 5V/5A 给舵机总线和 PCA9685 供电。开发板、舵机电源之间只共地，不在同一路电流上叠加。关键位置并了两颗 2200μF 电解电容，吸收舵机瞬间堵转电流产生的电压跌落。改造之后，即使颈部同时全速旋转加眉毛快速抖动，系统电压纹波也在可控范围内。

散热同样不能将就。RK3588 满载时 NPU 部分发热明显，我用原装主动散热器再加一颗 5V 无刷风扇，由 PWM 做温控：低于 55 度时风扇停转，高于 65 度时全速，中间线性过渡。这样待机时静音，演示时也不会因为风扇啸叫把语音交互毁掉。实测连续开机 7 天，核心温度最高 65 度，没出现一次因过热降频导致的掉帧。

6. 实测数据、踩坑记录和后续扩展方向

6.1 从“能跑通”到“稳一周”：长稳与异常处理

跑通 Demo 和稳定运行是两个量级。最初整套系统能演示五分钟，但每半小时必出一次异常：要么屏幕闪黑，要么 NPU 推理失败，要么摄像头掉线。我花了两周时间做长稳优化，这里分享几条最有效的经验。

第一，内存泄漏要主动盯。多线程视觉和语音链路只要有一个环节在循环里申请了堆内存没释放，几小时后就可能 OOM。我用的是一个非常土但有效的办法：arena 统计线程打印进程 RSS，观察半小时，如果内存持续线性上涨，再用 valgrind 定位泄漏点。修复后系统 RSS 稳定在基准线，不再上涨。

第二，NPU 句柄要规范管理。板端推理时如果每次调用都重新初始化模型句柄而不释放，驱动内部资源会被耗尽，表现为运行一段时间后 rknn_run 返回错误。我把模型加载做成单例，推理句柄常驻，只在退出时释放，这个问题再没出现过。

第三，摄像头掉线要有自动恢复机制。USB 摄像头长时间运行时偶尔丢 URB，表现为拉流线程卡死。我在采集线程里加了帧间隔检测，超过 2 秒没有新帧就主动重置 UVC 设备和 v4l2 流，重新拉流，比让整个进程重启优雅得多。

6.2 性能实测数据

整套系统在最终配置下的实测性能如下表。测试环境是鲁班猫 5 开发板，Ubuntu 22.04 系统，室温 25 度，主动散热开启。

这个性能表现说明 RK3588 的算力余量依然很大。如果把检测模型换成更大的 s 或 m 版本，可以把识别精度继续往上提，性能仍然可接受。按这个资源配置，这台设备再做三五年边缘 AI 升级也不会过时。

6.3 后续方向：接底盘、接双视线、接入本地大模型

作品目前的状态是“桌面迎宾头部”，下一步有几个明确的技术方向可以扩展。

第一个方向是接入移动底盘。RK3588 完全有能力同时承担头部交互和底盘控制，我最近已经在联调 PX4 飞控和 ROS2 底盘，用串口走 MAVLink 协议，头部作为上位机，识别到人后引导底盘转到正面。这个方向把一台桌面设备升级成完整的服务机器人。

第二个方向是视觉升级。目前的摄像头方案是额头单目，下一步在眼睛位置改放两颗低分辨率广角相机，模拟双目视差，可以实现瞳孔级注视追踪，让交互对象能明显感觉到“它在看着我的眼睛”，体验会再上一个台阶。

第三个方向是接本地大模型。RK3588 跑量化后的 1B 到 3B 参数语言模型是可以做到的，配合本地知识库微调，回答质量会比当前关键词匹配高一个级别。难点在于模型常驻内存占用量接近 4GB，要重新规划内存和缓存策略，但以这块板子的余量完全值得尝试。

我现阶段的做法还是那句话：先把现有功能做稳，再一项一项往上加。鲁班猫 5 加上两块圆屏、一个舵机云台、一个 YOLOv8 检测链路，这四样东西已经能支撑起整套交互演示的 80% 效果。语音、底盘、大模型这些模块，本质上都是在同一个框架上挂新线程的问题，不用推翻重做。如果你也想做类似作品，我建议别一上来就追求全功能，先把这一条主链路跑通，剩下的交给时间和迭代。