企业官网建设流程全解析

别让你的URDF模型在Gazebo里“躺平”：手把手教你配置libgazebo_ros_diff_drive插件让两轮小车动起来

做机器人仿真最烦的一件事，就是模型加载进Gazebo之后，电机指令发过去了，轮子却纹丝不动。小车就那么“躺平”在仿真世界里，看着又气又好笑。我的第一台两轮差速小车也是这样——URDF文件检查了三遍没问题，TF树能正常输出，但一发送cmd_vel，轮子就是死活不转。后来才明白，问题根本不在URDF本身，而是我压根没给Gazebo里的驱动轮装上“动力心脏”——libgazebo_ros_diff_drive插件。

如果你现在也卡在这一步，那这篇内容就是为你准备的。我会把两轮差速小车在Gazebo里跑起来的完整配置过程拆开揉碎，从URDF里轮子joint该注意什么，到libgazebo_ros_diff_drive插件每个参数是干什么用的、怎么填才能让odom、TF、轮速反馈全都正常，再到实际启动和调试的完整流程，一步步带你把小车从“躺平”变成“狂奔”。无论你是刚入门ROS和Gazebo的新手，还是已经会写URDF但总卡在仿真这一步的开发者，这篇内容都能给你一个可以直接抄作业的答案。

1. 整体思路与插件选型：为什么是libgazebo_ros_diff_drive

1.1 先搞清楚一件事：URDF只是“身体”，插件才是“肌肉”

很多刚接触Gazebo仿真的朋友都有一个误区，觉得URDF里把轮子、车身、关节都建模好了，Gazebo自然就能让它动起来。实际上，URDF在Gazebo里只是构建了一个刚体物理模型，它定义了每个link的质量、惯性、碰撞形状，以及joint的连接关系。但物理引擎不会主动去转动你的轮子——你必须通过某种方式告诉它“这个关节需要施加多大的力矩”。

这就是<gazebo>扩展标签和插件存在的意义。插件是连接ROS话题和Gazebo物理引擎之间的桥梁，它订阅ROS里发的速度指令，换算成力矩，再施加到指定的joint上，同时还能从joint上读取状态，换算成里程计信息发布出来。没有插件，你的模型再精细，在Gazebo眼里也只是一堆“死物”。

libgazebo_ros_diff_drive就是专门为差速驱动底盘设计的这类桥梁插件。它订阅cmd_vel话题，根据左右轮的速度差分别控制两个驱动轮joint，同时计算并发布里程计（odom）、TF变换，非常省事。

1.2 为什么不用自己写控制器或者用其他插件

有的朋友可能会问，我能不能自己写一个ROS节点，给joint_state_controller发位置指令模拟轮子转动？当然可以，但问题很多。手动给joint发状态指令走的是joint_state_controller，它本质上是在“摆pose”，并没有让物理引擎真正根据驱动力矩去积分计算轮子与地面的摩擦。这样出来的轮子转动和车辆运动，在地面摩擦、打滑、越障等场景下完全不真实，而且里程计还得你自己另算。

如果换用gazebo自带的libgazebo_ros_p3d（发布三维位姿）倒是能拿到模型位置，但它是针对模型整体的，不是针对轮子joint的，无法精确控制差速驱动。相比之下，libgazebo_ros_diff_drive就是Gazebo官方为差速轮式机器人准备的专用插件，直接耦合了“速度指令→轮子joint力矩→里程计/TF”这条完整链路。从ROS 1的gazebo_ros包到ROS 2的gazebo_ros2_control生态里，它都是最成熟、文档最全、踩坑资料最多的方案，没有之一。

1.3 差速驱动的基本原理：左右轮速差决定一切

两轮差速小车的运动逻辑其实一句话就能讲明白：想让车往前走，左右轮同速同向转；想让车转弯，左右轮速度不同；想让车原地转圈，左右轮大小相等方向相反。

插件内部拿到cmd_vel上的线速度v和角速度ω后，会根据轮距（wheel separation）拆解出左右轮的期望速度：

• 左轮速度：v_left = (2v - ω * L) / (2r)
• 右轮速度：v_right = (2v + ω * L) / (2r)

其中L是左右轮之间的轮距，r是轮子半径。公式本身不重要，重要的是插件必须知道你的轮距和轮径才做换算，否则它只能给你输出一堆错误的转速，体现在模型上就是原地乱转或者越跑越偏。

2. 准备工作：让URDF模型满足插件的最低要求

2.1 轮子link与joint的标准写法

在配置插件之前，先检查你的URDF里两个驱动轮的joint是否满足差速驱动的基本要求。每个驱动轮至少要有两个要素：一个对应link，几何上通常是一个圆柱体；一个连接车身和轮子的continuous joint。

一份最基本的驱动轮URDF结构如下：

<link name="left_wheel"> <visual> <geometry> <cylinder radius="0.1" length="0.04"/> </geometry> <origin xyz="0 0 0" rpy="0 0 0"/> </visual> <collision> <geometry> <cylinder radius="0.1" length="0.04"/> </geometry> <origin xyz="0 0 0" rpy="0 0 0"/> </collision> <inertial> <mass value="0.5"/> <inertia ixx="0.001" ixy="0.0" ixz="0.0" iyy="0.001" iyz="0.0" izz="0.001"/> </inertial> </link> <joint name="left_wheel_joint" type="continuous"> <parent link="base_link"/> <child link="left_wheel"/> <origin xyz="0 0.15 0" rpy="0 0 0"/> <axis xyz="0 0 1"/> </joint>

这里有几个细节要特别注意。

第一，continuous类型是必须的，它表示关节可以无限旋转。如果你用了revolute，即使设置了很大的limit，转几圈也会被限位挡住，插件控制起来会非常别扭。

第二，坐标轴方向。<axis xyz="0 0 1"/>表示轮子绕Z轴旋转，这在中国大陆习惯的机器人坐标系（车头朝前为X，左侧为Y，Z向上）里，意味着轮子是“横着”安装的，相当于一个侧立的滚筒。如果你的轮子模型是圆柱体并且轴线沿着Y方向，那是“竖着”滚动的麦克纳姆轮或全向轮结构，两者传动逻辑完全不同。我建议你先想清楚自己的轮子朝向，再决定axis怎么写，常见前驱小车通常选xyz="0 0 1"。

第三，惯性参数别偷懒。Gazebo物理引擎需要每个link的惯性张量。如果你只写了<mass value="0.5"/>而没有写<inertia>，Gazebo启动时会疯狂刷警告，甚至轮子直接不受控制。对于圆柱体，绕轴线Z的转动惯量约是0.5 * m * r²，绕另外两个轴的是(1/12) * m * (3r² + h²)，计算出来填进去，仿真会更稳定。

2.2 transmission标签：插件控制joint的前提

在Gazebo 11 + ROS Noetic这套经典组合里，很多资料都说URDF只需定义好joint就能控制，但实际经验告诉我，加上<transmission>会让整个链路更清晰，而且在迁移到ROS 2或ros_control体系时也能少踩很多坑。

<transmission name="left_wheel_trans"> <type>transmission_interface/SimpleTransmission</type> <joint name="left_wheel_joint"> <hardwareInterface>hardware_interface/VelocityJointInterface</hardwareInterface> </joint> <actuator name="left_wheel_motor"> <hardwareInterface>hardware_interface/VelocityJointInterface</hardwareInterface> <mechanicalReduction>1</mechanicalReduction> </actuator> </transmission>

这里mechanicalReduction是减速比，如果你仿真真实电机，可以设为10或20，插件会让轮子的转速按比例下降。日常仿真图省事，设为1就行。要注意<hardwareInterface>在ROS 1里通常写成hardware_interface/VelocityJointInterface，这个字符串在不同版本可能略有差异，但Noetic里这样写是稳定可用的。

2.3 给URDF加上gazebo材质与摩擦参数

很多URDF在RViz里显示得很好，但一进Gazebo就出现各种奇怪问题，比如轮子陷入地面、车身乱抖、速度上不去。这通常是因为没有为link添加Gazebo需要的<gazebo>标签。

每个轮子至少要配置mu1、mu2两个摩擦系数。mu1是沿运动方向的摩擦系数，mu2是侧向的。差速小车转弯靠的是轮子与地面的侧向摩擦，如果你把mu2设得太小，转弯时车身会像溜冰一样侧滑，看起来很假。我习惯把轮子的值设为mu1="1.0" mu2="1.0"，车身link的摩擦系数设成mu1="0.1" mu2="0.1"，这样车身不会因为意外接触产生太多阻力，轮子则能稳定抓地。

<gazebo reference="left_wheel"> <mu1>1.0</mu1> <mu2>1.0</mu2> <kp>1000000.0</kp> <kd>100.0</kd> <material>Gazebo/White</material> </gazebo>

kp和kd是接触刚度与阻尼，数值太大容易引发数值振荡，太小会导致模型穿透地面。默认值其实可以用，但由于差速小车全身重量压在轮子上，我调过很多次之后发现kp在1000000、kd在100附近比较舒服，车身也不会跳。

2.4 推荐用Xacro组织模型文件

当小车包含两个驱动轮、两个万向轮、一个车身、若干传感器时，手写URDF会变得非常啰嗦。强烈建议直接用Xacro（XML宏）来组织，把轮子定义成宏，传参复用。后面加第三方传感器模型时，改一个宏比改十个重复片段省心得多。我的xacro文件通常这样组织：

<xacro:macro name="wheel" params="name parent origin_xyz origin_rpy"> <link name="${name}"> ... </link> <joint name="${name}_joint" type="continuous"> <parent link="${parent}"/> <child link="${name}"/> ... </joint> </xacro:macro>

使用时一行搞定：

<xacro:wheel name="left_wheel" parent="base_link" origin_xyz="0 0.15 0" origin_rpy="0 0 0"/>

至于URDF里还要不要加<gazebo>的plugin标签，那是下一章的重点，先不在这里展开。

3. libgazebo_ros_diff_drive插件配置详解

3.1 插件标签的完整结构

URDF物理模型准备好了，接下来就是让libgazebo_ros_diff_drive接管两个驱动轮关节。在URDF文件的末尾，通常会在</robot>之前加入这样一段：

<gazebo> <plugin name="differential_drive_controller" filename="libgazebo_ros_diff_drive.so"> <leftJoint>left_wheel_joint</leftJoint> <rightJoint>right_wheel_joint</rightJoint> <wheelSeparation>0.3</wheelSeparation> <wheelDiameter>0.2</wheelDiameter> <maxWheelTorque>20</maxWheelTorque> <maxWheelAcceleration>1.0</maxWheelAcceleration> <commandTopic>cmd_vel</commandTopic> <odometryFrame>odom</odometryFrame> <robotBaseFrame>base_footprint</robotBaseFrame> <odometrySource>world</odometrySource> <publishOdomTF>true</publishOdomTF> <publishWheelTF>true</publishWheelTF> <updateRate>50.0</updateRate> <rosDebugLevel>na</rosDebugLevel> </plugin> </gazebo>

当你打开一个现有项目时，最常看到的插件名就是differential_drive_controller，文件名则是libgazebo_ros_diff_drive.so。这两个字符串分别决定了ROS节点名称和加载的动态库，尽量不要随意改动，否则有的启动脚本会找不到对应节点。

3.2 轮子参数：leftJoint、rightJoint、wheelSeparation、wheelDiameter

这一组参数是插件的“物理标定”信息。leftJoint和rightJoint必须和URDF里定义的joint名称完全一致，连大小写都要一致。Gazebo加载插件时不会因为名字不匹配直接崩溃，但会在日志里静默忽略状态更新，表现就是节点存在、话题存在，轮子却一动不动。

wheelSeparation是左右驱动轮中心之间的直线距离，单位m。这个值必须和URDF里两个轮子joint的origin xyz的Y坐标差一致。比如左轮Y为0.15、右轮Y为-0.15，那么wheelSeparation="0.3"。

wheelDiameter是轮子直径，单位m。这里特别容易出错，因为很多人在URDF里定义的是radius，如果直接拿半径填进来，会发现模型原地不动，或者线速度比预期小一半、角速度大两倍。如果你在URDF里写的是radius="0.1"，填插件参数时务必写wheelDiameter="0.2"。这一步我从没见谁一遍就填对过，包括我自己。

3.3 里程计与TF：odometryFrame、robotBaseFrame

里程计是Gazebo插件最实用也最容易出问题的部分。odometryFrame通常固定为odom，robotBaseFrame通常填模型在TF树里真正的基座link名称，比如base_footprint或base_link。这两个名称必须和你的URDF/TF树完全对应。

插件会计算仿真模型相对于世界坐标系的位移和姿态变化，然后发布从odom到robotBaseFrame的TF变换。odometrySource这个参数需要注意，它决定插件用哪种方式推算里程计：

• world：基于物理引擎里模型在世界坐标系的位置来算，最准确，但你要注意它计算的是“真值”，和真实传感器里程计不完全一样。
• encoder：基于轮子joint的转角累加值来算，模拟真实编码器，有打滑、积分误差更真实。

日常仿真我推荐用world，因为调试算法时想要理想数据；想练导航算法对里程计噪声的鲁棒性，就换成encoder。

publishOdomTF设为true时，插件会自动发布odom到robotBaseFrame的TF；设为false时，需要你自己写节点发布，否则RViz里模型会“失踪”。新手阶段建议始终为true，少给自己找麻烦。publishWheelTF则是把每个轮子的坐标系也挂到TF树上，方便观察轮子是否真的转了角度。这个开启后会在joint_state_publisher和robot_state_publisher之间产生冗余TF，如果你在RViz里看到轮子坐标系不对，再关掉它排查。

3.4 速度指令：commandTopic与cmd_vel

插件默认从/cmd_vel话题订阅geometry_msgs/Twist消息，<commandTopic>cmd_vel</commandTopic>就是话题名。如果你希望多个机器人共用一个仿真环境，可以通过<ros><namespace>为每个机器人分配独立的命名空间，这个话题名就会自动带上namespace前缀。

关于话题类型，ROS 1里就是geometry_msgs/Twist，ROS 2里变成geometry_msgs/msg/Twist，不需要在插件里显式声明类型，Gazebo会根据配置自动对接。

3.5 力矩、加速度与更新频率

maxWheelTorque是插件能施加到轮子joint的最大力矩，单位N·m。你给轮子设定的目标速度要求一个对应力矩，如果力矩上限太小，轮子根本转不动；如果太大会让电机“过冲”，车身抖动。两轮小车总重约5kg、轮径0.2m、轮距0.3m时，maxWheelTorque取20左右通常没问题。

maxWheelAcceleration是最大轮子角加速度，单位rad/s²，值越大速度响应越快，但过大会让物理引擎不稳定。一般设1.0~5.0之间，起步和刹车都很稳。

updateRate是插件更新频率，单位Hz。默认值在10~50之间都有。仿真精度要求高、地面很复杂时，建议设50；跑路径规划算法时20也够用。如果设得太低（比如5），轮子转动会一卡一卡，车身行走像抽搐。

这些参数构成了插件的“PD控制器”感觉，并不是真正意义上的电机控制器，但通过限制最大力矩和最大加速度，可以获得类似真实电机的输出平滑度。我实测过一组对比：不设maxWheelTorque，点击小车突然满速窜出去；设了20，起步才从容很多。

3.6 ROS 2版本与ROS 1的配置差异

如果你用的是ROS 2 Foxy/Humble和Gazebo 11，插件的filename同样是libgazebo_ros_diff_drive.so，但参数结构稍有不同。ROS 2里强调用<ros><namespace>声明命名空间，并且把参数包在<ros>里，最典型的写法是：

<gazebo> <plugin filename="libgazebo_ros_diff_drive.so" name="diff_drive"> <ros> <namespace>/demo</namespace> <remapping>cmd_vel:=cmd_vel</remapping> </ros> <left_joint>left_wheel_joint</left_joint> <right_joint>right_wheel_joint</right_joint> <wheel_separation>0.3</wheel_separation> <wheel_diameter>0.2</wheel_diameter> <command_topic>cmd_vel</command_topic> <odom_topic>odom</odom_topic> <odom_frame>odom</odom_frame> <robot_base_frame>base_footprint</robot_base_frame> <publish_odom_tf>true</publish_odom_tf> <publish_wheel_tf>true</publish_wheel_tf> <update_rate>50</update_rate> </plugin> </gazebo>

注意ROS 2版参数名几乎都是下划线风格，leftJoint变成left_joint,wheelSeparation变成wheel_separation，别把两个版本混着抄，否则插件加载后参数全都没生效，日志还不报错。

如果你的环境是ROS 2 + Gazebo Fortress/Ignition，那你需要的就不是libgazebo_ros_diff_drive，而是gazebo_ros2_control和diff_drive_controller这套新生态。这属于另一套完全不同的配置思路，本文不展开，但建议先确认你的组合再动手。

4. 实操验证：让小车动起来的完整流程

4.1 启动Gazebo世界并加载机器人模型

我把URDF（推荐直接用xacro）放在my_robot_description/urdf目录下，启动文件放在my_robot_gazebo/launch目录下。一个最基础的启动流程是：

source devel/setup.bash roscore rosrun gazebo_ros spawn_model -file ~/catkin_ws/src/my_robot_description/urdf/my_robot.urdf -urdf -x 0 -y 0 -z 0.05 -model my_robot rosrun gazebo_ros gzserver

更常见的做法是写launch文件一次性搞定：

<launch> <include file="$(find gazebo_ros)/launch/empty_world.launch"> <arg name="paused" value="false"/> </include> <param name="robot_description" command="$(find xacro)/xacro '$(find my_robot_description)/urdf/my_robot.urdf.xacro'"/> <node name="spawn_model" pkg="gazebo_ros" type="spawn_model" args="-urdf -param robot_description -model my_robot -x 0 -y 0 -z 0.1"/> </launch>

启动后第一件事，看终端有没有插件加载成功的关键日志。如果一切正常，你会看到类似这样的一行输出：

[ INFO] [GazeboRosDiffDrivePlugin]: Plugin <differential_drive_controller> initialized

如果没看到这行，就说明插件没加载或URDF里的<gazebo>标签有问题，后面发任何速度指令都不会动。

4.2 用teleop_twist_keyboard控制小车

确认插件加载成功，再用键盘控制验证。装好teleop_twist_keyboard包后：

rosrun teleop_twist_keyboard teleop_twist_keyboard.py

这个脚本默认发布到/cmd_vel话题，正好是插件默认订阅的话题。按i键小车向前、u/o键左右转向、k键停车。如果小车没动，第一件事是打开另一个终端查看话题：

rostopic echo /cmd_vel

如果cmd_vel有数据但轮子不动，再检查：

rostopic list | grep -E "odom|joint"

看有没有/odom和/joint_states。有/odom说明插件的主逻辑运行正常，问题大概率出在joint名称不匹配或轮子摩擦参数上。没有/odom则说明插件根本没初始化成功，需要检查URDF里的plugin配置和库文件路径。

4.3 检查odom与TF变换

小车一旦动起来，立刻检查里程计数据：

rostopic echo /odom

你会看到pose.pose.position.x和y随运动变化，twist.twist.linear.x和angular.z对应期望速度。同时：

rosrun tf2_tools view_frames

会自动生成frames.pdf，打开后确认TF树里有odom → base_footprint → left_wheel和right_wheel的完整链路。如果只有odom但下面没有轮子，说明插件没发布wheel TF，有可能是publishWheelTF设了false，或者是joint名称没匹配上。

我在实际调试时遇到过一种情况：TF树的odom和base_footprint之间出现跳变，小车在RViz里疯狂闪烁。这通常是因为同时有robot_state_publisher、joint_state_publisher和插件在抢同一个TF的发布权。解决办法是把robot_state_publisher里和插件冲突的frame，比如轮子的那部分，通过显式关闭来避免重复发布。

4.4 在RViz中观察小车是否真的在运动

Gazebo里看到的运动，是物理引擎渲染的结果；RViz里看到的运动，则是TF和URDF的可视化叠加。两者都正常，你的连杆和轮子配置才算真正健康。

打开RViz：

rviz

Fixed Frame设为odom，Add一个RobotModel显示URDF模型，Add一个TF显示坐标系。如果你在键盘控制小车前进，RViz中的模型也会跟着移动，同时每个轮子绕自身轴线旋转。

这里有个常见问题：RViz里看到车身移动，但轮子不转。这种情况几乎都是因为TF树里轮子坐标系被某个节点固定住了，最常见的是robot_state_publisher发布了轮子的静态TF。常规做法是让publishWheelTF接管轮子TF，同时在robot_state_publisher的launch文件中设置tf_prefix或者干脆让插件发布轮子坐标系时不要和URDF里的重复。调试时最简单粗暴的方案是先把publishWheelTF关掉，用robot_state_publisher统一管理TF，缺点是轮子旋转角度看不出来。

5. 常见问题排查与避坑实录

5.1 启动日志里没有插件初始化信息

这是最“安静”的失败，因为Gazebo不会报错，插件却压根没被加载。排查顺序如下：

• 确认URDF文件里<plugin ... filename="libgazebo_ros_diff_drive.so">写在<gazebo>标签内，而不是<robot>直接子节点。
• 确认文件名带.so后缀且拼写正确。ROS 1中常见写法是libgazebo_ros_diff_drive.so，如果你写成libgazebo_ros_diff_drive少了后缀，Gazebo依然不报错，但插件不加载。
• 检查动态库是否存在：

roscd gazebo_ros find . -name "*diff_drive*"

如果找不到这个.so，说明你的Gazebo版本或gazebo_ros包没装全，需要安装ros-noetic-gazebo-ros-pkgs一整套。

还有一种隐蔽情况：同时装了多个ROS发行版，环境变量错乱导致加载失败。这时用echo $LD_LIBRARY_PATH和echo $GAZEBO_PLUGIN_PATH确认路径是否都指向你正在用的发行版。

5.2 插件加载了，按键盘没反应

插件初始化日志有了，但cmd_vel发了，小车就是不动。这时优先检查命名空间问题。如果你的launch文件或URDF里写了<ros><namespace>my_robot</namespace></ros>，插件订阅的话题就不是/cmd_vel，而是/my_robot/cmd_vel。teleop_twist_keyboard默认发布的还是/cmd_vel，自然两边对不上。

处理方式两种：要么删掉namespace让话题保持全局，要么把键盘teleop节点放进同一命名空间：

<node name="teleop_twist_keyboard" pkg="teleop_twist_keyboard" type="teleop_twist_keyboard.py" output="screen"> <remap from="cmd_vel" to="/my_robot/cmd_vel"/> </node>

确认话题对接无误后，再检查力矩上限。maxWheelTorque设得特别小，比如0.01，那么轮子几乎不可能转起来。可以先调到50再观察，如果能动了说明力矩不够，再往下慢慢逼近一个合适的值。

5.3 轮子原地打滑，跑不起来

这是Gazebo仿真里一个极度常见的现象：插件在正常工作，电机指令也在发布，轮子也一直在转，但车子就是原地不动，像在冰面上空转。

问题几乎一定出在摩擦参数上。URDF里如果没给轮子和地面设置mu1、mu2，Gazebo默认的摩擦系数接近0，轮子在物理引擎里就像踩在冰上。我给每个驱动轮加上了：

<gazebo reference="left_wheel"> <mu1>1.0</mu1> <mu2>1.0</mu2> </gazebo>

问题立刻消失。如果你希望模拟冰面、泥地等场景，反而应该调低这个值，这样模型的打滑行为更真实。

地面本身也要注意。很多人直接在empty_world里跑，默认地面和模型的接触计算是可靠的。但如果你自己导入了一个STL或DAE格式的地形文件，它的摩擦参数往往没设置好，会出现整车陷进地面或者剧烈抖动。建议先从默认地面开始跑通整条链路，再换复杂地图。

5.4 两个轮子只有一个转

如果左轮转右轮不转，或者反过来，通常是joint名称写错了。插件里的leftJoint和URDF里的名称有细微差别，比如left_wheel_joint和leftwheeljoint。因为插件不会对错误名称报硬错误，只会在日志里打出一条不显眼的警告，不细看根本发现不了。

排查方法是在Gazebo启动后：

rosservice call /gazebo/get_joint_properties "joint_name: 'left_wheel_joint'"

能返回success: True就说明joint存在，否则说明名称对不上。对比两个驱动轮joint名，确保插件配置里写的是完全一致的那一份。

还要检查轮子的joint是否正确地作为URDF结构的一部分加载了。如果你用xacro生成URDF，确认宏展开后的名字和你填进插件的一样。我踩过最蠢的坑是宏内部用${name}_joint生成名称，调用时传的name是left_wheel，结果URDF里是left_wheel_joint，没错。但后来改代码把宏的name参数改成left_wheel_link，整个join名称全变了，光排查这个问题就耗掉一下午。

5.5 车身抖动、漂移、过弯不自然

车身抖动多半跟物理引擎迭代精度和刚体参数有关。首先是惯性参数是否正确。车身link的<inertia>如果全填了很小的值，总质量却设得很大，会让物理引擎对转动加速度的估计乱掉。我给车身用了一个简单的长方体惯性近似：质量2kg，长0.4m、宽0.3m、高0.1m，则ixx约为(1/12)*2*(0.3²+0.1²)=0.0167，iyy约为(1/12)*2*(0.4²+0.1²)=0.0283，izz约为(1/12)*2*(0.4²+0.3²)=0.0417。数值填进URDF后，车身明显稳了很多。

其次是maxWheelAcceleration。过大的角加速度会让轮子速度剧烈变化，物理引擎为匹配这个加速度会不断施加更大的力，形成高频抖动。把它降到1.0~2.0之间，启动和停止都柔和很多。

过弯不自然还有可能是wheelSeparation和URDF实体尺寸不一致。举例来说，你的轮子joint的origin Y坐标是0.15和-0.15，但车身宽度只有0.2，那么轮子实际在车身外面很多，转弯时物理引擎计算出的转向半径和预期不同。这类结构性错误只能通过反复对照URDF数值来排除。

最后提一个容易忽略的点：updateRate。插件更新频率太低会让力矩施加跟不上物理引擎的步长，出现“一顿一顿”的漂移感。把updateRate提高到50，同时确认gzserver本身的<physics><max_step_size>0.001</max_step_size></physics>没设得太大，一般就能解决。

5.6 常见问题速查表

6. 一个额外的经验：从配置插件到写算法的衔接

当插件配置好、键盘能控制小车跑动之后，你会发现整个仿真栈已经变得非常顺手。后续接上SLAM建图或者navigation导航时，cmd_vel和odom这两个话题就是小车与算法之间的“标准接口”。move_base会发布cmd_vel给插件，插件把速度变成轮子力矩，里程计再通过odom和TF反馈给导航栈，形成一个完整闭环。

这时候如果你发现自己拿到的话题数据不对，比如odom里的速度方向和cmd_vel方向相反，可以通过给commandTopic重映射或者调整URDF里轮子的转向来修正，而不是在代码里强转方向。我从实际项目里得到的经验是：保持“URDF模型 → 插件配置 → 算法输入”三者方向一致，比在后面的算法里硬找补要省事十倍。

另外，插件的<odometrySource>参数在接导航时很有讲究。导航算法对里程计的平滑性有要求，world模式下真值噪声极小，在tuning时你会觉得算法表现极好；但放到真实机器人上，数据不可能这么干净。如果你想提前验证算法的鲁棒性，我建议把odometrySource切到encoder模式，给里程计增加一点合理的噪声与漂移，再观察导航表现。这一条非常实用，但很多仿真教程压根不会提。

从个人体会来说，libgazebo_ros_diff_drive插件把仿真里最繁琐的“关节控制+里程计推算”变成了几个参数的事，但它同时也是最容易因为一个参数填错而让整辆车“躺平”的环节。记住三个最核心的检查点：URDF关节名和插件joint名一致、轮径轮距和URDF几何一致、摩擦系数足够让轮子抓地。做到这三点，你的两轮小车就基本告别“躺平”，随叫随走了。