企业官网建设流程全解析

1. 从一个驱动库说起：为什么 ROS 里跑全向底盘要先搞懂 omni

做机器人开发这几年，我见过太多人在 ROS 里拿到一台全向底盘，第一件事就是急着发/cmd_vel，结果小车不是原地打转，就是斜着飘出去，还有人把麦轮装反了还查了半天。问题几乎都出在同一个地方：只把 omni 当成一个普通的驱动包，却没有真正理解它在整个 ROS 控制链路里承担的角色。

omni 本质上是一个面向全向底盘（Omnidirectional Mobile Robot）的运动学驱动库，最常见的载体就是麦克纳姆轮（Mecanum Wheel）和全向轮（Omni Wheel）底盘。它做的事情可以概括成三件：接收上位机发来的速度指令（通常是geometry_msgs/Twist），根据底盘的实际轮距、轮径、安装角度等参数做逆运动学解算，再把解算出的每个轮子的转速通过串口或 CAN 发给电机驱动板。反过来，它也负责把电机编码器反馈读回来，做正运动学解算，发布出机器人当前的实际速度，喂给 ROS 里的odom和 TF。

简单说，omni 就是底盘硬件和 ROS 上层决策之间的“翻译官”。没有它，你发的cmd_vel只是空中楼阁；有了它，你才能让底盘按照你期望的速度向量走直线、横移、原地转圈，甚至斜着任意角度漂移。

这篇文章写给谁？刚从 gazebo、URDF 或者仿真走向真车的 ROS 新手，以及已经在用现成底盘但想彻底搞懂底层原理的开发者。我会从运动学公式讲起，一步步拆解 omni 的代码结构、参数配置、坐标系转换、里程计标定，再到真车调试中那些最隐蔽的坑——比如轮子转速方向反了、odom 漂移、TF 延迟。最后还会分享一套完整的验证流程，帮助你确认整条链路是否真的打通了。

提示：如果你用的是某厂商定制的全向底盘，驱动代码可能是基于 omni 的二次开发。即便如此，本文的运动学推导和调试思路依然适用，只是参数名称和通信协议会有差异。我这里讲的是最通用的底层逻辑。

2. 全向底盘的运动学，一句话讲透

全向底盘最大的魅力在于它拥有三个可控自由度：前后（x 方向）、左右（y 方向）、旋转（绕 z 轴，也就是 yaw 角）。普通差速底盘只有前后和旋转两个自由度，所以它没法横着走。全向底盘正是因为车轮的特殊结构——麦轮或全向轮——使得每个轮子既能沿滚动方向产生驱动力，也能在垂直于滚动方向被动滑移，这才让“平移 + 旋转”的解耦成为可能。

2.1 麦轮和全向轮：两种实现路径

麦轮的外观很有辨识度，主轮周围斜向分布了一圈纺锤形的小辊子。辊子的轴线与主轮轴线之间有 45 度夹角，这个 45 度是运动学解耦的关键。

全向球轮造价低，适合轻载、低速的场景，常用于教育机器人和小型服务机器人。

选择哪种轮子取决于你的场景。如果负载重、用得多，麦轮是第一选择；如果只是做个桌面级 Demo，全向轮性价比更高。要注意的是，全向轮在过沟坎时振动和打滑比麦轮严重，里程计更容易出偏差。

2.2 逆运动学：从Twist到四个轮子转速

写代码之前，先把手算公式放在这。假设底盘的四轮布局为前排左轮 FL、前排右轮 FR、后排左轮 RL、后排右轮 RR，轮距（左右轮间距）为 L，轴距（前后轮间距）为 W，轮子半径为 R，麦轮辊子相对于轮轴的夹角为 45°，那么逆运动学公式为：

v_fl = (vx - vy - ω * (L + W) / 2) / R v_fr = (vx + vy + ω * (L + W) / 2) / R v_rl = (vx + vy - ω * (L + W) / 2) / R v_rr = (vx - vy + ω * (L + W) / 2) / R

注意，这里 vx、vy 是底盘坐标系下的线速度（m/s），ω 是角速度（rad/s）。四个速度的符号约定与轮子安装方向相关，如果某个轮子的速度算出来是负数，代表该轮反转。

一句话理解：vx 让四个轮子同向转动产生前后运动；vy 让左右两侧轮子反向转动产生横移；ω 让对角轮同向、相邻轮反向转动产生自转。这三者线性叠加，就是全向底盘能“任意方向 + 旋转”同时进行的原因。

2.3 正运动学：从轮子转速回到odom

正运动学是逆运算，从四个轮子的实际转速反推底盘速度：

vx = (v_fl + v_fr - v_rl - v_rr) * R / 4 vy = (-v_fl + v_fr + v_rl - v_rr) * R / 4 ω = (-v_fl + v_fr - v_rl + v_rr) * R / (L + W)

这里有个很容易被忽略的细节：用正运动学推算的 vy 通常不如 vx 准。因为麦轮横移时依赖辊子被动滑动，摩擦损耗比滚动方向大得多，所以 odom 中 y 方向容易累计漂移。后面讲里程计标定时我还会提到这一点。

正运动学算出来的速度通过积分可以得到位置增量，这就是/odom话题的根源。ROS 的robot_localization或者base_footprint到odom的 TF，都是基于这个推算结果发布的。公式本身不复杂，难的是让这个推算和真车实际位移对得上，这就涉及参数标定和轮子滑移补偿。

3. ROS 命令行上的 omni 实操拆解

知道公式之后，剩下的事情就是把公式映射到 ROS 节点上。标准 omni 驱动包的结构如下：

omni_base/ ├── include/omni_base/ │ └── omni_kinematics.h ├── src/ │ ├── omni_node.cpp │ ├── omni_serial.cpp │ └── omni_kinematics.cpp ├── config/ │ └── omni_params.yaml ├── launch/ │ └── omni_base.launch └── CMakeLists.txt

每个文件的核心职责：

• omni_node.cpp：主节点，订阅/cmd_vel，发布/odom，读写底盘串口数据。
• omni_kinematics.cpp：提供逆运动学和正运动学解算函数。
• omni_serial.cpp：封装串口通信协议，包括校验、超时、重发逻辑。
• omni_params.yaml：底盘参数配置文件，轮距、轮径、串口端口、轮子方向等全部在这里声明。

这种分层结构是有道理的。把运动学代码和串口通信隔离，后续换通信总线（比如从 USB 转串口换成 CAN）时，只需要重写omni_serial.cpp，运动学部分完全不动。很多二次开发厂商也是这么设计的，只不过把串口协议换成了自己的私有协议格式。

3.1 安装与编译：别跳过参数检查

拿到 omni 源码后，把它放进你的工作空间，比如catkin_ws/src，然后编译：

cd ~/catkin_ws catkin_make source devel/setup.bash

编译通常不会出问题，真正容易翻车的是参数文件。打开omni_params.yaml，你会看到类似这样的一组参数：

omni_base: wheel_radius: 0.076 # 轮子半径（米） wheel_track: 0.36 # 左右轮间距（米） wheel_base: 0.34 # 前后轮间距（米） max_speed: 1.5 # 最大线速度 max_omega: 3.0 # 最大角速度 serial_port: /dev/ttyUSB0 baud_rate: 115200 encoder_ticks_per_rev: 1600 # 编码器每圈脉冲数 wheel_direction: [1, -1, -1, 1] # 四个轮的转向修正系数

这里wheel_direction很关键。它是四个轮的旋转方向符号修正，因为不同底盘布线方式会导致电机正转方向不统一，所以需要你根据实际测试来设。默认[1, -1, -1, 1]对应常见的 H 型麦轮底盘，但如果你车子的电机安装方向不同，这个数组得现场调。

我第一次用 omni 时就因为照搬默认参数，导致底盘前冲时右前轮和左后轮反转，车子直接原地画圈。后来一个个轮子单独测试才定位到方向系数问题。

3.2 启动节点：一条 launch 文件全搞定

写一个 launch 文件是很自然的选择：

<launch> <node name="omni_base_node" pkg="omni_base" type="omni_node" output="screen"> <rosparam file="$(find omni_base)/config/omni_params.yaml" command="load"/> </node> </launch>

启动之后，用工具检查话题和节点状态：

roslaunch omni_base omni_base.launch rostopic list rostopic echo /odom

如果一切正常，/odom会持续输出位姿数据。此时可以试着发一条速度指令：

rostopic pub -r 10 /cmd_vel geometry_msgs/Twist "{linear: {x: 0.2, y: 0.0, z: 0.0}, angular: {z: 0.0}}"

底盘如果向前走 0.2m/s，说明逆运动学没问题。如果没反应，先查串口通没通：ls -l /dev/ttyUSB0、dmesg | grep tty。要是串口权限不够，会出现Permission denied，解决办法是把当前用户加入dialout组：

sudo usermod -a -G dialout $USER

重启终端后重新插拔串口设备，一般就能解决。

3.3 通讯协议：串口帧格式的经典设计

很多使用 omni 的底盘采用一种非常经典的串口帧协议。读码器通常接在底盘控制板上，控制板通过串口与上位机通信。协议的典型格式为：

帧头(0xAA) + 帧类型 + 数据长度 + 数据区 + 校验和

以发送速度指令为例，数据区包含四个轮子的目标转速（int16，单位 RPM），每个轮子两个字节，数据区一共 8 字节。帧类型标记这条指令是“速度控制”。接收的帧通常是编码器反馈，数据区六个字节：x 速度、y 速度、角速度（float 或 int16）。

写omni_serial.cpp时，要注意以下几个细节：

1. 帧头校验。不要只在开头判断一个字节，要连续确认两个字节的帧头，避免串口噪声误触发。
2. 超时重发。3 秒内没有收到底盘反馈，需要重发当前指令，或者丢出警告。
3. 大端小端对齐。不同控制板对多字节数据的字节序有差异，解析前必须明确协议是小端还是大端，否则速度值会翻车。

这些看起来琐碎，但实际调试时，都可能导致底盘“不动”“抖动”“乱跑”等疑难杂症。

4. 移植与二次开发：把 omni 用在自定义底盘上

很多人以为 omni 只能驱动原厂配套的底盘，其实它的核心运动学模块完全可以移植到自己的底盘上。只要你能拿到四个轮的轮径、轮距、轴距以及编码器反馈，你就可以在 ROS 中实现自己的全向底盘驱动。

4.1 从现成库中复用运动学代码

如果你不想从零开始定义运动学公式，可以直接把 omni 中omni_kinematics.cpp的源码抽出来，放到你自定义的驱动节点中。核心只需要保留两个函数：inverseKinematics()和forwardKinematics()。

以下是一个简化版本的逆运动学函数，你可以直接参考：

// 逆运动学：输入底盘速度，输出四轮转速 void inverseKinematics(double vx, double vy, double omega, double wheel_radius, double half_track, double half_base, double *v_fl, double *v_fr, double *v_rl, double *v_rr) { double k = (half_track + half_base) * omega; *v_fl = ( vx - vy - k) / wheel_radius; *v_fr = ( vx + vy + k) / wheel_radius; *v_rl = ( vx + vy - k) / wheel_radius; *v_rr = ( vx - vy + k) / wheel_radius; }

这里half_track = wheel_track / 2，half_base = wheel_base / 2。如果你的轮子不是 45 度麦轮，而是 90 度全向轮，公式中k的正负号和vy的作用会有细微差异，要根据全向轮的安装方向调整。但结构是一样的：vx驱动四个轮子同方向、vy驱动左右两侧反方向、omega驱动对角轮同向相邻轮反向。理解这个结构，比死记公式重要得多。

正运动学同理，把编码器反馈的四个轮子转速代入：

void forwardKinematics(double v_fl, double v_fr, double v_rl, double v_rr, double wheel_radius, double half_track, double half_base, double *vx, double *vy, double *omega) { *vx = ( v_fl + v_fr - v_rl - v_rr) * wheel_radius / 4.0; *vy = (-v_fl + v_fr + v_rl - v_rr) * wheel_radius / 4.0; *omega = (-v_fl + v_fr - v_rl + v_rr) * wheel_radius / (4.0 * (half_track + half_base)); }

封装之后，你的自定义驱动节点只需要维护四个轮子的转速状态，持续发布/odom，然后不断把cmd_vel换算成四轮速度，再发给自己的底层控制板即可。

4.2 改造成 CAN 总线底盘

omni 原本是面向串口的，但如果你的底盘是 CAN 通信，移植思路依然清晰。只需要替换omni_serial.cpp为omni_can.cpp，利用 Linux 的SocketCAN接口收发 CAN 帧。

改造时，你只需要实现两个函数：

• sendSpeedToMotors()把四轮速度打包成多个 CAN 帧发送。
• parseMotorFeedback()从 CAN 帧中解析出四轮编码器值。

运动学代码原封不动。从而 CAN 总线的实时性更高，在高速和重载场景下比串口更可靠。很多 AGV 厂商都偏好 CAN 方案，所以你如果打算把 omni 的原理迁移到更大的机器人上，CAN 改造是值得提前练手的方向。

提示：SocketCAN 基本操作是can0网卡 +candump抓包，丢包排查的第一步永远是先确认 CAN 总线物理层有没有错误帧，而不是先怀疑 ROS 代码。

4.3 从单节点到多节点：基于 omni 的完整架构

在实际项目中，只用 omni 一个节点往往不够。一个典型项目可能需要：

• sensor_fusion_node：融合 IMU 和轮式里程计，输出更稳定的位姿。
• navigation_node：接收 2D 地图和定位信息，发布/cmd_vel给 omni。
• remote_control_node：手柄或者手机 App 遥控底盘。
• tf_tree：发布odom->base_footprint的坐标变换。

这时 omni 节点扮演的角色变成了一个纯粹的“底层驱动库”。上层所有逻辑都通过/cmd_vel和/odom与它交互。这种分层设计的好处是，上层不关心底盘硬件细节，底层不关心导航规划算法。谁都能独立替换，非常适合团队协作开发。

5. 坐标系与 TF：odom 到底在哪里

全向底盘调通之后，你会发现另一个头疼的话题：TF。ROS 系统里，odom坐标系怎么发布，base_footprint和base_link怎么设置，直接影响导航和建图能否正常工作。

5.1 常见坐标系的设置

底盘驱动节点通常负责发布odom->base_footprint的变换，因为只有驱动层才知道轮子走了多少距离，这是最底层的里程计来源。导航层会在此基础上继续发布map->odom的变换。

在 omni 源码中，发布 TF 的部分通常长这样：

tf::Transform odom_to_base; odom_to_base.setOrigin(tf::Vector3(x, y, 0.0)); odom_to_base.setRotation(tf::createQuaternionFromYaw(theta)); tf_broadcaster_.sendTransform(tf::StampedTransform(odom_to_base, ros::Time::now(), "odom", "base_footprint"));

注意x、y和theta是通过正运动学算出的速度做积分得到的。如果你只是做简单测试，直接发布也可以；但如果长期运行，积分漂移会越滚越大。这也是为什么很多方案中 IMU 会被引入进来，用 IMU 修正 yaw 角，用轮式里程计修正 x、y 位置。

5.2base_link与base_footprint的选择

很多初学者容易把这两个坐标系的用途搞混。简单区分：

• base_link是底盘中心点，通常在轮轴高度，用来描述机器人本体的姿态。
• base_footprint是base_link在地面的投影，z 坐标为 0，用来简化导航和速度控制。

如果 omni 发布的 TF 是odom->base_footprint，那么在你的robot_state_publisher中，base_footprint应该是根节点，base_link是它的子节点，偏移量就是底盘的高度。不要搞反，否则整个 TF 树会断。

5.3 频率问题：odom 发布节奏不能太慢

全向底盘的位置估计依赖 odom 发布的频率。常见底盘驱动发布频率是 50Hz 或 100Hz，具体取决于控制板反馈的数据率。

如果发布频率太低，比如 10Hz，那么导航模块拿到的速度信息就会严重滞后，表现出来就是小车到位后停不住，来回振荡。你可以这样检查：

rostopic hz /odom

如果输出显示 average rate 明显低于你设定的频率，优先排查串口数据读取是否阻塞、节点是否有 sleep 过久、或者下游话题订阅是否绑定了耗时操作。

6. 里程计标定：没有标定，一切都是估算

里程计标定是使用 omni 后绕不开的一环。不管公式推导得多漂亮，实际轮子的滑移、轮子磨损、负载差异都会导致估算误差。常见标定策略有两种：离线标定和在线校准。

6.1 直线标定：测量实际行走距离

给底盘一条直行的速度指令，比如 0.2m/s，运行 5 秒，理论上应该走 1 米。实际测量地面上的位移，如果只有 0.95 米，说明轮径参数偏大，需要把wheel_radius乘以 0.95 修正。

具体操作：

1. 在地面标记起点和终点，让底盘直行 5 秒。
2. 测量实际距离，记为actual_dist。
3. 计算修正系数：scale_factor = actual_dist / theoretical_dist。
4. 在omni_params.yaml中更新wheel_radius = old_radius * scale_factor。
5. 重新启动节点，重复测试直到误差小于 1%。

6.2 旋转标定：校正 yaw 角

原地旋转测试的目标是让底盘转过某个精确角度，例如 360 度，实际可能只转了 340 度或转过了 380 度。修正方法和直线类似：根据实际旋转角度按比例调整wheel_base或wheel_track参数，因为这两者直接决定旋转角速度解算。

6.3 动态校正：摩擦补偿

直线和旋转标定完成后，你还会发现一个有意思的现象：底盘在横移的时候误差会比直行大。原因是麦轮辊子横移时存在滑动摩擦，实际输出速度比理论值偏小。有些人会在vy的换算上乘一个补偿因子，比如 0.98。这个因子没有统一标准，完全取决于你的地面材质、轮子状态和底盘负载，需要实测调整。

我个人的经验是：把标定过程自动化，写一个 Python 脚本订阅/odom，同时记录真车实际位移，用最小二乘拟合出最优补偿因子。这比手动一个个试要高效得多。

7. 实战问题排查：omni 调试避坑记录

调试过程中，我整理了一份问题速查表，几乎每个用全向底盘的人都会遇到：

除此之外，还有几个不容易发现的坑：

1. 轮子抬空测试 vs 着地测试结果不一致。这是正常的，因为轮子悬空时没有摩擦阻力，编码器反馈非常理想；着地后滑移和摩擦会让 odom 偏差增大。标定务必在着地状态做。
2. 麦轮辊子上沾了异物、头发、线头，速度反馈会剧烈跳动。不要小看这个问题，它往往比任何代码 bug 都隐蔽。
3. 串口线过长或者供电不足，特别是在大电流驱动电机时，会导致底盘偶发丢帧，表现就是“偶尔抽动一下”。

注意：不要在电机的 PWM 输出通道上直接并联其他大功率设备。全向底盘四电机同时启动时的瞬时电流很大，电源模块必须留有至少 30% 的余量，否则重启、死机、乱跑各种问题都能找上你。

还有一个我反复强调的排查技巧：最小化验证。把导航、建图、避障全部关掉，只留一个 ROS 节点发cmd_vel和 omni 驱动节点，输入固定速度，观察轮子实际转向是否正确。确认底层没问题，再逐步加上层模块。绝大多数疑难杂症，都能在最小化系统中暴露出真相。

8. 从 omni 出发，构建一个完整的全向机器人

实践出真知。分享一个我自己的项目经验：一个基于 omni 驱动的全向底盘，加上一个 2D 激光雷达和 IMU，最终构建了一套可以自主导航和避障的机器人。

8.1 系统架构

整个系统分三层：

底层是电机驱动和编码器，是 omni 和硬件交互的对象。中间层是 omni 驱动节点，负责提供/odom和接收/cmd_vel。上层是导航和感知，包含激光雷达驱动、SLAM 建图、move_base导航规划。

这样的架构让开发可以并行推进：底层调底层，上层调上层。如果导航有问题，不用怀疑驱动；如果驱动有问题，上层再花哨也没用。

8.2 建图测试：全向底盘的优势

SLAM 建图时，全向底盘的优势非常明显。差速底盘在建图时需要通过频繁的旋转来覆盖环境，全向底盘可以一边平移一边扫描，效率高得多。尤其是在狭窄走廊里，横移模式几乎是为这种场景量身定做的。

建图用的命令通常是：

roslaunch omni_base omni_base.launch roslaunch laser_slam laser_slam.launch rosrun teleop_twist_keyboard teleop_twist_keyboard.py

在操控机器人移动时，我发现一个体验上的特点：全向底盘横移时要特别注意给上层规划器足够的空间余量。因为它可以瞬间朝任何方向移动，如果导航规划的目标点过于贴近障碍物，底盘容易在转向与平移的组合动作中刮擦障碍物边缘。

8.3 导航测试：全向底盘的速度规划

move_base是 ROS 导航栈的核心。它通过代价地图和路径规划算法输出cmd_vel。全向底盘配置move_base时，需要在参数文件中声明机器人的几何尺寸，通常是长方体或者圆柱体，半径不要超过底盘的实际外接圆半径，否则路径规划会把机器人卡在安全区域外。

一次典型的导航测试指令：

rostopic pub /move_base/goal move_base_msgs/MoveBaseActionGoal "..."

或者用 RViz 里的 2D Nav Goal 按钮直接点选目标点。全向底盘的路径规划结果会显示出斜向移动轨迹，这其实是它在同时解算 x、y 和 yaw 三个自由度的速度，非常正常。

8.4 性能对比：全向底盘 vs 差速底盘

我同时用差速底盘跑过同样的建图和导航任务。差速底盘在建图时效率明显偏低，因为它必须靠旋转改变朝向，做 90 度转弯需要的路径半径比全向底盘大得多。导航时差速底盘更容易出现“原地拐弯”的过程中撞到墙，全向底盘则可以贴着墙边平移修正误差。

当然，全向底盘也有它的短处。麦轮在非平整地面上的抓地力和通过性都弱于普通橡胶轮，横移时辊子磨损也比较快。如果你做户外机器人，或者需要在砂石路面运行，全向底盘并不是最佳选择。室内仓储、竞赛场地、光滑地坪才是它的主战场。

9. 一些通用的调参心得与建议

最后聊点实操中总结的经验，希望对你有帮助。

9.1 参数文件里的注释，一定要写清楚

我看到太多工程里的omni_params.yaml没有任何注释，只有一堆数值。几个月之后你再回来，根本分不清这些数值是怎么标定的。我的建议是每一行都写清参数来源和标定日期：

# 轮径：2024-05-12 用直行 1m 测试标定，实际走 0.98m，从 0.078 修正为 0.076 wheel_radius: 0.076

这样后续任何人接手，都能快速知道这些参数是怎么来的，而不是靠猜。

9.2 记录日志，复现问题

调试 omni 时，把/odom、/cmd_vel、四个轮子的反馈转速全部录成 rosbag：

rosbag record -O omni_debug /odom /cmd_vel /wheel_speeds

如果底盘出现问题，可以离线回放数据，对比指令和实际响应之间的差异。有一次我调试一个偶发的抖动问题，就是靠回放 rosbag 发现某个轮子在特定速度区间存在机械共振，而不是驱动代码的问题。

9.3 仿真先行

如果你暂时没有真车，可以在 Gazebo 里搭建一个全向底盘模型来验证运动学公式和 omni 算法。Gazebo 有专门的全向轮插件，模型配置好后，同样可以用 omni 的算法解算四个轮速，再通过 Gazebo 的控制器驱动仿真模型移动。仿真验证速度比真车快得多，尤其是在测试恼人的坐标系关系和 TF 树结构时，价值巨大。

9.4 保持模块化思维

最后一点：不要把 omni 当作一个黑盒。把它当作一个可以拆解、修改、替换的运动学基础组件。你越了解它的底层逻辑，就越能应对各种定制需求。以后你使用任何其他底盘驱动包，哪怕不是 omni，你会发现万变不离其宗——运动学公式、坐标系关系、串口通信协议，这三样永远是底盘驱动的核心。

10. 写在最后的个人经验

我接触全向底盘驱动很多年，踩过最多的坑其实不在运动学公式上，而在“以为公式写对了就万事大吉”的心态上。imu 方向和车轮方向不匹配、串口线松动导致的偶发丢帧、麦轮辊子磨损不均引发的里程计漂移，这些实际问题往往比代码本身更耗时间。

如果你现在正要开始调一个 omni 底盘，我的建议非常具体：先花半小时把每个轮子单独转到固定方向并标记正负，再花半小时跑直行和原地旋转标定，最后再上导航。这套流程看起来慢，其实是最快的路。很多工程师上来就发cmd_vel发现跑偏，再用各种绕弯的手段去改代码，结果浪费的时间是标定的好几倍。

另外，我强烈推荐从一开始就做好参数文件的版本管理。每调整一次wheel_radius或wheel_base，记录下测试数据、修改理由和日期。这会让你的标定工作可追溯，也方便换硬件后重新调整参数。

ROS 驱动底盘这件事，本没有太多秘密。omni 是一个入口，真正重要的是你理解全向底盘的运动学本质，理解速度指令到轮子转速的换算过程，理解里程计误差从何而来。搞懂这些之后，换任何底盘、任何驱动包，你都游刃有余。至少我可以确定，当你再遇到一台陌生底盘时，绝不会手足无措。