平板上显示一团跟着机器人走的三维点云，看起来只是个展示效果，背后却是一条完整的数据链：机器狗上装的雷达每秒都产生大量点，要经过网络送到浏览器，再在一块性能有限的平板上流畅渲染。官网展厅导览机器狗项目的平板访客界面就包含“点云三维跟随”。官网没有公开它的实现，本文讨论的是这类功能的通用做法，未经实机验证，具体数字要在自己的硬件上测。 先说一个前提：给观众看的点云和给算法用的点云不是一回事。算法需要完整、精确；界面只需要“看起来对”，并且不卡。所以浏览器这一路应该单独出一个话题，不去碰导航用的原始数据。
【在机器人端抽稀和裁剪】 官网导览方案推荐的雷达是 Livox Mid-360，这类雷达点数多，原样发往平板既占带宽，又会让渲染吃力。发出去之前可以做几件事。 体素降采样：按固定体素大小合并点，界面上几乎看不出区别，点数能明显下降。 范围裁剪：只保留机器人周围一定半径和高度内的点，天花板通常也可以去掉，免得遮挡视线。 累积与刷新：单帧点云比较稀，可以在局部地图坐标系里累积几帧，再按固定频率推送，画面更连贯。 去除自身：腿和外壳打到的点要先滤掉，不然画面中央会一直有一团杂点。
【编码和传输】 ROS 2 的点云消息字段多、带填充，直接转 JSON 发给浏览器，体积会膨胀很多倍。常见做法是： 只保留 x、y、z，必要时加一个字节的强度，用于着色； 坐标量化成 16 位整数，以机器人当前位置为原点，在局部范围内精度足够； 打包成二进制，通过 WebSocket 发送，浏览器端直接用 TypedArray 读取，不经过 JSON 解析； 网络紧张时降低推送频率，而不是每帧丢掉一半的点。 位姿单独发一个小消息，频率可以高于点云，界面里的机器人模型靠它平滑移动。点云和位姿要带同一套时间戳，否则画面会出现拖影。
【浏览器里怎么画】 WebGL 渲染点云，关键是减少每帧的工作量。 用一个固定大小的缓冲区存放点，新数据来了就覆盖写入，而不是每次新建几何体； 点的颜色在着色器里按高度计算，不在 CPU 上逐点赋值； 相机跟随机器人位姿做插值，画面不会一跳一跳； 在平板上限制设备像素比，高分屏按原始分辨率渲染很费电。 如果用 Three.js 这类库，要注意及时释放旧缓冲。展厅界面往往一开就是一整天，最怕内存慢慢上涨。
【服务放在机器人上】 官网的巡检无人机地面站强调同一套界面可以在网页和安卓平板上离线运行，导览项目也已部署在机器人板上运行。放到点云界面上，就是服务端在机器人上，平板通过本地网络访问，不依赖外网。好处是延迟低、稳定；代价是抽稀、打包都在板上做，要和导航、识别一起算账，给这部分留出算力余量。
【小结】 点云上网页，要在三个地方省：机器人端少发，传输时压紧，浏览器里少算。做好了，它就是机器狗上装能力最直观的展示窗口；做不好，卡顿和拖影会让观众对整台机器的印象打折。
展厅与文旅导览机器人：www.yuanzhirobot.com/zh/scene/to… 本文部分内容由 AI 辅助生成。
