1. 产品介绍

Odin1 是留形科技推出的一款面向机器人定位与环境感知的工业产品。在我们的项目中，Odin1 主要承担两类任务：一是为机器人提供里程计信息，二是输出点云数据供上层感知和环境建模模块使用。

稳定且高频的里程计为导航提供了强有力的支持。机器人导航系统需要持续获得自身的位置、姿态和运动状态，而Odin1 可以直接提供较为完整的运动估计结果，因此能够减少自行搭建里程计系统的工作量。

除此之外，我们也会使用 Odin1 输出的点云。虽然点云并不是我们选择 Odin1 的唯一原因，但在机器人实际运行过程中，这部分数据同样具有较高的使用价值，可以用于环境观察、障碍物感知、地图构建以及后续的点云处理。

因此，在我们的机器人系统中，可以将 Odin1 简单理解为同时提供：

机器人自身运动信息；
周围环境的点云信息。

我们的上位机运行 Ubuntu 22.04 和 ROS2 Humble，上层使用 ROS2 相关组件完成导航、感知和数据处理。Odin1 的里程计会接入导航系统，而点云数据则可以提供给地图、障碍物检测或其他点云处理模块使用。

基本信息

产品：留形科技 Odin1
使用系统：Ubuntu 22.04
ROS 版本：ROS2 Humble
主要用途：机器人里程计、点云数据获取
应用场景：移动机器人导航与环境感知
数据传输方式：USB3.0
ROS2数据交互方式：话题通信
里程计输出频率：大约300Hz
点云输出频率：大约10Hz

2. 安装与使用方法

2.1 硬件安装

Odin1 的硬件安装整体并不复杂。首先需要将设备固定在机器人机体上，同时保证传感器具有合适的视野，同时避免机器人自身结构对点云造成过多遮挡即可。

2.2 软件配置

我们的上位机使用 Ubuntu 22.04 和 ROS2 Humble。

安装官方提供的软件和 ROS2 驱动后，可以启动 Odin1 对应节点，并通过 ROS2 获取设备输出的数据。

（驱动链接： https://github.com/manifoldsdk/odin_ros_d

实际使用过程中，我们主要关注两类信息：

第一类是机器人运动信息：

里程计；
位姿；
速度；
TF。

第二类是环境信息：

点云数据；
点云对应坐标系；
点云发布时间和频率。

设备启动后，可以先使用：

ros2 topic list

查看 Odin1 发布的话题。

对于里程计等数据，可以使用：

ros2 topic echo <topic_name>

查看具体内容。

同时可以通过：

ros2 topic hz <topic_name>

检查数据发布频率。

对于点云，最直观的检查方式一般是在 RViz2 中添加 PointCloud2，观察点云是否能够正常显示，以及机器人运动时点云是否与 TF 正确对应。

因此，每次设备启动后，我们通常都会检查：

Odin1 节点是否正常运行；
里程计是否正常输出；
点云是否正常输出；
TF 是否正常；
各话题频率是否稳定；
点云是否存在明显错位或异常。

2.3 接入机器人系统

在我们的项目中，Odin1 的数据会进入两个主要的数据链路。

第一条是导航链路：

Odin1 → Odometry / TF → Nav2 → 机器人运动控制

Odin1 提供机器人的实时运动状态，上层导航系统根据这些信息确定机器人当前的位置和运动情况。

第二条是点云链路：

Odin1 → PointCloud2 → 点云处理 / 地图 / 障碍物感知

点云可以经过滤波、裁剪、坐标变换等处理，再交给其他模块使用。

因此相比于只输出里程计的设备，Odin1 在我们的系统中不仅参与机器人“知道自己在哪里”的过程，也参与机器人“看到周围环境”的过程。

3. 实际使用体验

从整体使用体验来看，Odin1 比较明显的优势是集成度高，能够同时提供里程计和点云数据，而且接入 ROS2 后的使用方式比较直接。

里程计是我们使用 Odin1 最主要的原因。在正常工作状态下，Odin1 输出的里程计整体比较稳定，能够连续提供机器人的位置、姿态和运动信息。机器人在直线运动、转弯以及正常导航过程中，位姿输出具有较好的连续性，没有明显的高频跳变。

从实际项目角度来看，这一点比较重要。因为如果完全自行搭建里程计系统，还需要额外处理传感器驱动、数据同步、状态估计、坐标变换以及参数调试等问题，而 Odin1 可以直接提供已经处理好的运动估计结果，能够减少不少前期开发工作。

除了里程计之外，我们也会使用 Odin1 输出的点云数据。

点云可以直接通过 ROS2 话题通信获取，并在 RViz2 中做可视化进行观察，也可以进一步提供给地图、障碍物感知和点云处理模块。实际使用中，我们主要会关注点云是否完整、发布频率是否稳定、是否存在明显噪声，以及机器人运动过程中点云是否出现明显错位或拖影。

在机器人系统调试过程中，点云也比较有帮助。例如当导航或定位出现异常时，可以同时观察里程计、TF 和点云，从而判断问题究竟来自位姿估计、坐标变换，还是点云数据本身。

（下图是赛场上的实际使用，可见点云清晰、里程计频率高且稳定）

Screenshot from 2026-09-12 17-39-18.png

在 ROS2 接入方面，Odin1 的整体使用方式比较符合常规 ROS2 设备的使用习惯。里程计、点云和 TF 都能够通过 ROS2 的标准消息体系进行传输，因此比较容易与 Nav2框架、RViz2 以及其他 ROS2 模块结合。

实际调试过程中，我们一般会通过 RViz2 查看机器人位置和点云，同时配合 TF、高频里程计话题/odin1/odometry_highfreq、点云话题/odin1/cloud_slam等以及ros2 topic <. . .> 等工具进行检查。如果遇到比较难定位的问题，也可以录制 rosbag，之后进行离线分析。

总体来看，Odin1 在正常状态下的使用体验是比较方便的。里程计可以直接服务于导航，点云可以提供给环境感知模块，而 ROS2 接入也没有额外增加太多复杂度。

不过，在实际使用过程中，我们也遇到过一个比较明显的问题：Odin1 会出现近处点云畸变的情况。这对后续的点云处理会造成不可避免的干扰。而我们目前的解决方案是把近处点云滤除（）。

与此同时，由于我们的搭载 Odin1 的哨兵采用的是轮腿的构型，自然就无法避免跳跃、飞坡等运动。而在这种剧烈运动中常会发生机体加速度超出 Odin1 内置 imu 量程的情况，造成odom->base_link飘飞，里程计的严重发散。（这个能算不足之处吗？...）

4. 总结与个人感受

综合使用体验来看，Odin1 对我们项目最大的价值在于它能够同时提供里程计和点云数据。

其中，里程计是我们最主要的使用需求。

正常情况下，Odin1 能够提供比较稳定、连续的机器人运动估计，可以比较方便地直接接入 ROS2 和 Nav2，大幅减少自行开发里程计系统所需要的工作量。

与此同时，Odin1 输出的点云也给机器人提供了周围环境信息。

虽然我们没有完全依赖 Odin1 点云完成所有感知任务，但这些数据仍然可以用于障碍物检测、环境观察、地图构建、地形分析以及各种后续点云处理。

因此，从系统角度来看，Odin1 并不是单纯的“里程计设备”，而是同时承担了一部分状态估计和环境感知工作。

对于机器人项目来说，这种较高的集成度是比较明显的优势。

总体来说，目前我对 Odin1 的评价是：

集成度高，稳定的高频里程计和清晰密集的点云具有极高的价值。Odin1展现出的较强的工程实用性，使其成为一款值得推荐和信赖的机器人定位与感知设备。