1. 为什么要做一套ROS2+Arduino的机器人底盘

先说结论：这套方案是目前入门移动机器人性价比最高的路线，没有之一。

我见过太多人一上来就直接上树莓派。树莓派确实能跑Ubuntu、能装ROS2，但它的问题也很突出——它不是实时系统。电机控制这种活儿，要求的是微秒级的脉冲响应，树莓派跑着Linux内核，进程调度一抖，PWM波形就乱了。轻则小车跑偏，重则电机啸叫、驱动板烧掉。而Arduino这类单片机就是干这个的，中断响应是硬件级别的，稳稳当当。

还有一个更现实的原因：ROS2的导航框架（Nav2）、激光SLAM、路径规划这些重量级功能，本质上是计算密集型的软件任务，需要跑在操作系统上。你不可能把它们塞进一块8MHz的AVR芯片里。所以你需要的不是一个“能跑ROS2的板子”，而是一套“分工明确”的系统——上层交给树莓派或者PC，底层交给Arduino。

这就是ROS2+Arduino组合的核心逻辑：Arduino负责“手脚”，ROS2负责“大脑”。我这篇文章会把这套底盘的完整实现过程拆开讲透，从硬件选型到固件编写，从micro-ROS通信到Nav2导航，全部覆盖。不管是刚开始接触ROS2的新手，还是已经写过一些Arduino程序、想往机器人方向转型的开发者，这篇文章都能给你一套能直接落地的参考方案。

我要提前说明一点：这篇文章提到的Arduino系列底盘，我实际用的是Arduino Mega 2560作为主控。为什么不用Uno？后面讲硬件选型的时候我会详细说，这里先记住一个结论——做机器人底盘，IO资源和中断引脚数量直接决定你的扩展上限。

2. 整体架构设计与方案选型

2.1 为什么是ROS2而不是ROS1

很多老资料还在教ROS1，但我强烈建议新项目直接上ROS2。ROS1的架构里有一个roscore节点，所有节点通信都要经过它，这就等于单点故障——roscore挂了，整个系统全崩。ROS2采用的是去中心化的DDS通信，节点之间点对点直连，没有中心节点。

打个比方：ROS1像公司里所有员工汇报都要经过一个总经理，总经理请假了公司就瘫痪；ROS2像员工之间直接拉群沟通，哪怕走了一个人，其他人照常工作。

另外一个现实因素是生态。ROS1已经在2025年停止维护了，你学ROS1学到的东西，很快会过时。ROS2的Humble版本是长期支持版，支持到2028年，Jazzy版本也会逐步成为主流。对于新项目来说，选择长期支持的版本是唯一理性的选择。

2.2 底盘控制的三种方案对比

我在设计底盘时评估过三种主流的控制方案，这里直接放对比表：

我最终选了第三种方案的变体：Arduino跑micro-ROS节点，直接与ROS2主机的DDS网络通信。这样上层导航节点下发速度指令时，直接通过话题发布，不需要自己定义串口协议，省掉了大量通信层的重复劳动。

2.3 手动模式和自动模式的切换设计

一个成熟的底盘必须支持手动遥控和自动导航两种模式。手动模式用于调试、狭小空间操作和紧急接管；自动模式用于建图、路径规划和自主导航。

我实现的方式是在Arduino端维护一个模式切换标志位，通过订阅一个cmd_mode话题来切换。上位机发来true表示进入自动模式，Arduino只接受ROS2下发的速度指令；发来false则进入手动模式，接收遥控器或者键盘控制指令。这个设计的核心思想是：模式切换的最终执行权在Arduino端，而不是上位机端。因为Arduino更靠近硬件，它能保证在通信中断时自动切换回手动模式，防止小车失控。

3. 硬件选型：每一分钱都要花在刀刃上

3.1 电机和驱动板的选择逻辑

底盘最核心的部件是电机。市面上的选择五花八门，但真正适合移动机器人底盘的只有两种：直流减速电机和步进电机。步进电机精度高，但低速扭矩特性差、发热严重，而且需要专用的步进驱动器，不适合做轮式机器人底盘。直流减速电机配合编码器是行业标准方案。

编码器是很多人忽略的东西。没有编码器，你的小车就只能开环跑——你让它以50%的PWM占空比前进，它可能实际只走到30%的速度，因为电池电压在波动，地面摩擦在变化。有了编码器就能构成闭环：设定目标速度，编码器实测实际速度，PID控制器自动调节PWM占空比，让实际速度收敛到目标值。

电机选型时重点看三个参数：

• 减速比：一般选1:30到1:50之间。减速比太小，扭矩不够爬坡；太大，速度上不去。
• 编码器分辨率：至少选11线以上的霍尔编码器，配合4倍频可以做到44个脉冲/圈，做一般导航够了。如果想要更高精度，可以选带ABZ三相编码器的电机。
• 额定电压和空载转速：12V电机配12V电池，空载转速在300RPM左右比较合适，配合直径65mm的轮子可以实现约1m/s的最高车速。

驱动板我推荐TB6612FNG，而不是经典的L298N。TB6612的导通压降只有0.5V左右，L298N要2V以上，这意味着同样的电池电压，TB6612方案下电机实际能获得更高的驱动电压，扭矩大、效率高。而且TB6612体积小很多，可以直接插在面包板上，方便调试。

3.2 为什么主控选择Arduino Mega 2560

Arduino Uno是很多人入门的第一块板子，但做底盘它有个致命缺陷——只有两个外部中断引脚。一个带编码器的电机需要两个中断引脚（分别接A相和B相），两个电机就需要四个，Uno完全不够用。

Mega 2560有6个外部中断引脚，加上54个数字IO口、16个模拟输入口，扩展空间非常充裕。更重要的是，Mega的芯片是ATmega2560，Flash有256KB，RAM有8KB。跑micro-ROS固件、PID计算、传感器读取这些逻辑绰绰有余。

这里我要特别提醒：如果你用Arduino Uno跑micro-ROS，RAM大概率不够用。micro-ROS的客户端库自带的内存开销在3KB左右，再加上你的控制逻辑和编码器计数，Uno的2KB RAM基本会被吃干净，然后就会出现各种诡异的崩溃、死机现象。

3.3 电源系统的几个坑

电源是整个底盘最容易出问题的地方，我踩过的坑比写代码踩的还多。

第一个坑：电机和逻辑电路共用一个电源。电机启动瞬间的电流冲击会导致电压跌落，Arduino的5V稳压器扛不住这种波动，会随机复位。解决方案是分开供电：电机用12V电池直供，Arduino和传感器通过独立的5V稳压模块供电。

第二个坑：电池选的容量太小。两路电机全速运行时电流可以到2A以上，加上海外传感器和Arduino，总电流轻松超过3A。我建议选3000mAh以上的2S或3S锂电池，否则跑十分钟就没电了，建图建到一半断电，心态直接崩。

第三个坑：PCB走线太细。如果你自己画主板，电机驱动的电源线至少要用20mil以上的宽走线，最好直接上跳线。细线在大电流下会发热，电阻增大后电压进一步跌落，形成恶性循环。

4. Arduino端固件实现

4.1 开发环境准备：PlatformIO是首选

Arduino IDE用来学语法没问题，但做正经项目我强烈建议换到PlatformIO。它的优势是：支持多平台编译、依赖管理自动化、命令行构建、代码补全和调试。用VSCode + PlatformIO的体验甩Arduino IDE几条街。

平台选择atmelavr，开发板选择megaatmega2560。项目结构里，源码放在src/目录，库文件在lib/目录。我用到的核心库有：

• micro_ros_arduino：micro-ROS的Arduino客户端库
• PID：PID控制库
• Encoder：编码器读取库

4.2 micro-ROS Agent的部署

micro-ROS的架构分两层：上位机跑一个micro-ROS Agent，它像一个网关，负责把DDS消息转换成串口或UDP数据；Arduino端跑一个micro-ROS Client，通过串口或WiFi和Agent通信。

Standard流程是：

1. 先让micro-ROS Agent跑起来。在Ubuntu上，可以用Docker方式运行：

docker run -it --rm -v /dev:/dev --privileged --net=host microros/micro-ros-agent:humble serial --dev /dev/ttyACM0 -b 115200

这里我把Agent绑定到了Arduino的串口设备/dev/ttyACM0上，波特率115200。--privileged和--net=host是必要的，前者给了容器访问串口的权限，后者让Agent和ROS2的DDS网络直连。

2. 在Arduino端初始化micro-ROS节点。核心代码如下：

#include <micro_ros_arduino.h> #include <stdio.h> #include <rcl/rcl.h> #include <rcl/error_handling.h> #include <rclc/rclc.h> #include <rclc/executor.h> #include <geometry_msgs/msg/twist.h> rcl_publisher_t cmd_vel_pub; rcl_subscription_t cmd_mode_sub; geometry_msgs__msg__Twist cmd_vel_msg; void setupMicroROS() { set_microros_serial_transports(Serial); delay(2000); rcl_allocator_t allocator = rcl_get_default_allocator(); rclc_support_t support; rcl_ret_t rc = rclc_support_init(&support, 0, NULL, allocator); rcl_node_t node = rcl_get_zero_initialized_node(); RCCHECK(rclc_node_init_default(&node, "arduino_chassis", "", &support)); RCCHECK(rclc_publisher_init_default( &cmd_vel_pub, &node, ROSIDL_GET_MSG_TYPE_SUPPORT(geometry_msgs, msg, Twist), "cmd_vel_raw" )); RCCHECK(rclc_executor_init(&executor, &support.context, 2, &allocator)); }

这里有几个关键点。第一，cmd_vel_raw话题我故意不叫cmd_vel，因为Nav2的cmd_vel是经过速度平滑后的指令，底盘接收的是原始速度指令。如果你直接把底盘的订阅话题设成cmd_vel，那么遥控模式下手柄的指令也要发到同一个话题，会有优先级冲突。第二，rclc_executor_init里的参数2表示executor最多挂载两个句柄（这里是一订阅一发布），挂多了会出问题。

4.3 PID速度闭环的实现

底盘控制的核心是PID速度闭环。这里我使用的是一套经典的增量式PID：

float pidCalculate(float target_speed, float current_speed, PIDData* pid) { float error = target_speed - current_speed; float derivative = error - pid->last_error; float output = pid->kp * error + pid->ki * pid->integral + pid->kd * derivative; pid->integral += error; pid->last_error = error; // 积分限幅，防止积分饱和 if (pid->integral > pid->integral_limit) pid->integral = pid->integral_limit; if (pid->integral < -pid->integral_limit) pid->integral = -pid->integral_limit; return output; }

PID调参是个玄学活，但我可以给一套比较靠谱的起步值：Kp=1.5、Ki=0.1、Kd=0.05。调整顺序建议是：先把Ki和Kd调成0，只留Kp，从小到大增加Kp直到系统出现轻微震荡；然后加入Ki消除稳态误差；最后加入Kd抑制超调。

重要提示：编码器数据的滤波不可省。电机自带的编码器在低速时脉冲间隔长，计数误差很大，直接拿原始值算速度会导致PID输出剧烈抖动。我用的是一阶低通滤波：

float filtered_speed = alpha * raw_speed + (1 - alpha) * filtered_speed;

alpha取0.3左右比较合适。太小了响应迟钝，太大了滤波效果差。

4.4 串口监控与调试技巧

调试Arduino底盘的利器是串口。我在固件里加了一个调试模式，通过宏开关控制：

// 定义 DEBUG_ENABLE 开启调试输出 #ifdef DEBUG_ENABLE #define DEBUG_PRINT(x) Serial.print(x) #define DEBUG_PRINTLN(x) Serial.println(x) #else #define DEBUG_PRINT(x) #define DEBUG_PRINTLN(x) #endif

调试信息包括当前模式、目标速度、实际速度、PID输出、电池电压等。用PlatformIO的串口监视器看，一行一条，格式是[模式] 目标=xxx 实际=xxx PWM=xxx，方便对照分析。

调试时还有个技巧：在Serial Monitor里千万不要把波特率写错。micro-ROS通信本身占用了串口的115200波特率，你的调试输出和micro-ROS共用同一个串口，输出频率太高会干扰通信。所以我通常把调试输出的频率限制在10Hz以内，而且只在手动模式下输出，自动模式下关闭调试输出。

5. ROS2上位机与底盘通信

5.1 创建ROS2功能包

底盘通信层的功能包结构如下：

chassis_bringup/ ├── package.xml ├── CMakeLists.txt ├── launch/ │ └── chassis_bringup.launch.py └── src/ ├── chassis_node.cpp └── chassis_odom.cpp

这里同时创建了两个节点：chassis_node负责速度指令的下发，chassis_odom负责里程计数据的处理。选择C++而不是Python，是因为里程计数据的计算涉及大量矩阵运算和坐标变换，Python在性能上还是有一些短板。

5.2 底盘节点实现速度指令转发

底盘节点做的事情很简单：监听手柄的cmd_vel话题（类型geometry_msgs/msg/Twist），然后把线速度linear.x和角速度angular.z提取出来，发布到cmd_vel_raw给Arduino。但这里的“简单”背后有一个重要设计：为什么节点要转发而不是直接让Arduino订阅手柄话题？

原因在于耦合。手柄、键盘、导航栈都可能产生速度指令，它们的来源不同但最终都是底盘驱动。如果让Arduino直接订阅每一个来源，固件就必须知道所有上位机的逻辑，这违背了分层设计的原则。引入这个转发节点后，所有来源的速度指令统一汇总到这里，通过一个话题名cmd_vel_raw输出给底层，上层怎么变，底层不用关心。

底盘节点的C++核心代码：

class ChassisNode : public rclcpp::Node { public: ChassisNode() : Node("chassis_node") { publisher_ = this->create_publisher<geometry_msgs::msg::Twist>("cmd_vel_raw", 10); subscription_ = this->create_subscription<geometry_msgs::msg::Twist>( "cmd_vel", 10, [this](const geometry_msgs::msg::Twist::SharedPtr msg) { publisher_->publish(*msg); } ); } private: rclcpp::Publisher<geometry_msgs::msg::Twist>::SharedPtr publisher_; rclcpp::Subscription<geometry_msgs::msg::Twist>::SharedPtr subscription_; };

5.3 里程计数据融合与TF广播

底盘节点只管下发指令，真正体现“机器人有没有走准”的是里程计。Arduino端通过编码器计算每个轮子的转速，发布速度和里程增量。ROS2的chassis_odom节点接收这些数据，再在ROS2端推算里程计（odometry）和TF变换。

里程计的核心是航迹推测（Dead Reckoning）。假设机器人是两轮差速底盘，左右轮轮距为wheel_separation，左轮速度为v_left，右轮速度为v_right，那么：

v_linear = (v_left + v_right) / 2 v_angular = (v_right - v_left) / wheel_separation

有了线速度和角速度之后，还要做位置积分。这里涉及的坐标系变换是：

• base_link：机器人本体的坐标系
• odom：里程计坐标系，它的原点就是机器人的出发点
• map：地图坐标系，用于全局定位

odom到base_link的变换是积分出来的，会随时间和运动误差漂移；map到odom的变换则由SLAM或者AMCL计算，用于纠正漂移。这个三层TF结构是ROS2导航的标准结构，这也是为什么你的小车要跑Nav2必须要有一个正确的TF树。

// 位置积分更新 double dt = timestamp - last_timestamp; x += v_linear * cos(theta) * dt; y += v_linear * sin(theta) * dt; theta += v_angular * dt;

发布TF和odom：

tf_broadcaster_->sendTransform( tf2::StampedTransform( tf2::Transform(tf2::Quaternion(0, 0, sin(theta/2), cos(theta/2)), tf2::Vector3(x, y, 0)), now, "odom", "base_link") );

5.4 URDF与机器人模型的编写

如果你打算跑Nav2、用RViz2可视化，一个完整的URDF模型是必须的。URDF里定义了机器人每个部件的位置、形状、碰撞体、惯性参数，它是RViz2显示三维模型、Gazebo仿真物理计算的基础。

我的URDF核心结构：

<robot name="chassis"> <link name="base_link"> <visual> <geometry> <box size="0.3 0.2 0.1"/> </geometry> </visual> </link> <joint name="left_wheel_joint" type="continuous"> <parent link="base_link"/> <child link="left_wheel"/> <origin xyz="0 0.1 0" rpy="0 0 0"/> <axis xyz="0 1 0"/> </joint> </robot>

写URDF时最需要注意的是每个link的质量和惯性参数。Gazebo仿真需要这些参数来做物理计算，如果你不写惯性参数，链接会报错。对于调试来说，质量不重要，随便给一个值就行；但对于仿真验证，参数不合理会导致小车乱飘。

URDF写好后，还要配套写一个robot_state_publisher节点来发布每个关节的TF变换，这是ROS2最常见的标准节点，launch文件里直接启动它就行。

5.5 micro-ROS与串口通信的稳定性保障

这一节要讲的是通信稳定性的坑。micro-ROS通过串口和Agent通信，这个链路在实际使用中经常会出现断连问题，原因主要是这几个：

第一，串口权限不足。如果你的用户不在dialout用户组里，访问/dev/ttyACM0会报权限错误。执行：

sudo usermod -a -G dialout $USER

然后重新登录才生效。

第二，串口被其他程序占用。有时候screen或者minicom占用了串口，Agent就起不来。用ls /dev/ttyACM*检查设备是否存在，ps aux | grep screen检查占用。

第三，波特率不匹配。Agent启动时的-b参数必须和Arduino端set_microros_serial_transports里面的波特率保持一致，一个115200另一个9600必然连不上。

第四，Stack溢出。micro-ROS在Arduino上跑需要比较大的栈空间。在PlatformIO的platformio.ini里，加上：

build_flags = -DRCUTILS_NO_FILESYSTEM -DROSIDL_DYNAMIC_STRING monitor_speed = 115200

以及关键的一行：

board_build.f_cpu = 16000000L

如果跑micro-ROS时出现stack overflow错误，需要把board_build.mcu对应的栈大小改大，比如在platformio.ini中加入：

build_flags = -Wl,-u,vfprintf -lprintf_flt

或者在代码中调整：

// 在setup()中显式设置micro-ROS的stack大小 microros_reset_stack_size(4096);

这几个设置能解决大部分micro-ROS相关的不稳定现象。

6. 建图与导航实战

6.1 从传感器到地图：激光雷达与SLAM

底盘能动了，里程计准了，接下来就是导航。这一步需要给机器人装一个“眼睛”——激光雷达。我最常用的是RPLIDAR A1，性价比高，足够应对室内的建图任务。

建图使用SLAM-Toolbox，导航使用Nav2，这是ROS2生态的标准组合。SLAM-Toolbox接收激光雷达扫描数据（/scan）、里程计数据（/odom）、TF树（/tf），输出二维栅格地图（/map）。

launch文件长这样：

def generate_launch_description(): return LaunchDescription([ DeclareLaunchArgument('use_sim_time', default_value='false'), Node( package='slam_toolbox', executable='sync_slam_toolbox_node', name='slam_toolbox', output='screen', parameters=[{ 'use_sim_time': LaunchConfiguration('use_sim_time'), 'base_frame': 'base_link', 'odom_frame': 'odom', 'map_frame': 'map', 'scan_topic': '/scan', 'mode': 'mapping' }] ) ])

建图时有一个非常重要的实操经验：控制机器人匀速缓慢移动，转弯时速度要更慢。SLAM-Toolbox对扫苗畸变很敏感，转太快会导致点云错位、地图出现重影。

6.2 Nav2导航栈的核心参数调优

Nav2的导航栈里，最影响实际表现的是planner_server里的全局规划器和controller_server里的局部规划器参数。

全局规划器我推荐用NavFn，它在小地图上快而且稳定。局部规划器可以用DWB（Dynamic Window Approach）或MPPI。DWB的计算量小，在算力弱的平台上跑得动；MPPI更平滑，但需要更多的计算资源。

关键参数里面，我认为最重要的调整项是这些：

代价地图膨胀半径。默认值0.55m，但实际要结合你的车体宽度微调。我用的底盘宽度0.2m，膨胀半径设0.35m。设太小会导致机器人贴着墙走，很容易蹭到；设太大路径规划会过度保守，在窄通道里把自己卡死。

最大线速度和最大角速度。controller_server里max_vel_x默认0.5，max_vel_theta默认1.0。如果你的电机扭矩不够大，把这些值调小，否则控制器会频繁报Goal is blocked错误。

加速度限制。acc_lim_x和acc_lim_theta很重要，设太大电机会吃力，设太小路径跟踪会迟钝。我的底盘设的是0.5和1.0。

配置片段：

controller_server: ros__parameters: controller_frequency: 20.0 min_vel_x: 0.0 max_vel_x: 0.4 min_vel_theta: 0.0 max_vel_theta: 0.8 min_speed_xy: 0.0 max_speed_xy: 0.4

6.3 RViz2可视化与调试

RViz2是调试ROS2机器人最重要的工具，没有之一。它可以直接显示激光雷达扫描、地图、路径、机器人的3D模型。

调试导航时要注意看三个东西：

• TF树是否正确。在RViz2里添加TF显示，能看到所有坐标系的变换。如果底盘的base_link和odom的TF没发布，Nav2直接罢工。
• 全局代价地图和局部代价地图。地图上的黑色区域是障碍物，灰色区域是膨胀层。如果膨胀区域太大，说明你膨胀半径设的过大。
• 规划出来的路径。绿色线是全局路径，红色线是局部路径。如果路径频繁重规划，说明局部规划器参数不好或者代价地图更新太频繁。

RViz2的常见问题是加载不了模型。这多半是URDF的问题，检查一下robot_state_publisher是否正常启动，以及TF树的父子关系是否正确。用ros2 run tf2_tools tf2_echo map base_link检查map到base_link的变换是否能正常输出。

6.4 Gazebo仿真验证

在把代码烧到真实底盘之前，先在Gazebo里跑一遍仿真能省下大量真机调试时间。Gazebo需要的是机器人的URDF模型加上物理插件。底盘的运动学可以用gazebo_ros_diff_drive插件实现，它会自动把cmd_vel转换成轮子运动。

使用Gazebo仿真的核心价值是：提前发现逻辑错误，而不是硬件错误。比如你的PID参数写错了、坐标变换没发布、Nav2配置有问题，仿真环境里5分钟就能发现，真机调试可能得折腾一整天。

7. 常见问题与排查技巧实录

7.1 Arduino无法上传程序

这个问题遇到的人最多。排查顺序：

1. 检查开发板型号选对没有。PlatformIO里如果选错板子，编译能过，上传必挂。
2. 检查串口号。拔掉其他USB串口设备，只留Arduino，确认端口是/dev/ttyACM0还是/dev/ttyUSB0。
3. 检查bootloader是否损坏。如果上传时一直报avrdude: stk500_recv(): programmer is not responding，多半是Uno的bootloader被刷掉了。Mega 2560正常情况下很少出现这个，因为它的bootloader比较健壮。
4. 按住复位键几秒再点击上传，有时能抢救回来。

7.2 编码器读数跳动

编码器读数不均匀是新手最常见的挫折。原因基本集中在硬件接触不良和电磁干扰。我排查时的做法是：

1. 用示波器或者逻辑分析仪看编码器A、B相的输出波形。正常情况应该是方波，如果看到毛刺或幅值波动，优先检查接线。
2. 给编码器电源加滤波电容。在编码器的VCC和GND之间并联一个0.1uF的瓷片电容，能滤掉大部分高频干扰。
3. 在代码中做正交解码。不要用简单的上升沿计数，用Encoder库自动处理A、B相的相位关系，能消掉很多手动编码的错误。

7.3 Nav2的路径规划卡死

表现是机器人在原地打转，或者规划失败。最常见的三个原因：

• 全局代价地图没有正确订阅到地图。Gazebo或者真实激光雷达发布的地图话题名和Nav2订阅的不一致。用ros2 topic list检查一下/map话题是否存在。
• TF树断链。Nav2的规划器要求map → odom → base_link → laser的TF链路完整。缺一个环节，它就不干活。
• 膨胀半径设得太大。机器人被自己设置的膨胀区域困住，怎么规划都找不到路。这种时候把膨胀半径调小一档试试。

7.4 Arduino端的内存不足

编译时出现region 'data' overflowed by X bytes的错误，基本都是内存不够。排查方法：

• 精简代码，少用String对象，多用char数组。
• 把不需要的库注释掉，检查platformio.ini里是否引入了没用的依赖。
• micro-ROS的节点数量和数据缓冲区大小适当减小。在micro_ros_arduino的配置里，RMWS_FASTDDS_STATIC_BUFFER_SIZE调小一些能腾出不少内存。

7.5 底盘跑偏问题

两轮差速底盘跑不直，原因往往是两个轮子的转速不一致。先检查左右电机是否同型号，再检查PID参数是否分别标定过。每个电机的减速箱摩擦成本不同，同一个Kp参数下两个电机的响应速度可能有差异，需要分别调优。

编码器安装松动也会导致读数不准。轮子装不紧、编码器盘松动，都会让左右轮的里程计数据不真实，表现出来就是“明明下发的是直线，走一段偏到右边去了”。底盘螺栓拧紧后，重新标定一次轮距参数wheel_separation就行了。

8. 工具链与学习路径建议

8.1 IDE和仿真平台的选择

Arduino和ROS2的学习门槛都不低，我的建议是用PlatformIO作为开发环境，同时借助Wokwi进行快速仿真验证。

PlatformIO的优势前面提过，这里不重复。Wokwi是一个在线的嵌入式仿真平台，在浏览器里就能跑Arduino代码，特别适合调试不依赖硬件外设的逻辑代码。你可以先在Wokwi里验证PID算法、编码器计数逻辑，确认无误后再烧到真机上，能省出大量调试时间。

ROS2学习初期，小乌龟仿真（turtlesim）是最佳入门工具，它能直观展示话题通信、节点、坐标变换这些概念。之后是RViz2可视化，再到Gazebo仿真，最后上真机，这个顺序踩坑最少。

8.2 从入门到实战的几个阶段建议

学习ROS2和底盘开发是一个阶梯式上升的过程，这里给出我认为比较合理的学习路径，分成四个阶段：

• 阶段一（1-2周）：掌握ROS2基础概念，理解节点（node）、话题（topic）、服务（service）、动作（action）四大通信原语的区别，用C++或Python写几个简单的发布订阅程序。
• 阶段二（1周）：掌握Arduino基础，重点学PWM调速、编码器读取、串口通信，写一个能通过串口控制的小车。
• 阶段三（1-2周）：把micro-ROS跑起来，用话题发布器让Arduino底盘接受ROS2的cmd_vel指令，学会用RViz2监控话题和TF。
• 阶段四（2-4周）：集成激光雷达，跑通SLAM建图和Nav2导航，完成从“能走”到“会走”的跨越。

每个阶段都有明确的验收标准：阶段一的验收标准是能完成一个发布者一个订阅者的通信；阶段二的验收标准是能用PWM控制两个电机正反转；阶段三的验收标准是上位机发布cmd_vel，底盘能响应；阶段四的验收标准是机器人能完成指定的导航任务。

8.3 新手容易走错的方向

最后聊几个新手常见的认知误区。

误区一：一上来就想实现全自主导航。导航是系统工程，不是单点技术。在Nav2跑通之前，你应该先确保底盘稳定、里程计准确、地图建得清晰。连直线都走不稳的底盘，导航再好的算法也救不了。

误区二：把大量时间花在调激光雷达上。激光雷达只要能稳定输出/scan话题就行，刚入门不需要纠结点云的质量和细节。它的核心价值是给SLAM提供输入，而不是本身值得花大量精力去研究。

误区三：忽视电池管理系统。锂电池过放一次基本就废了，轻则容量下降，重则鼓包甚至起火。我给底盘装了一个低压报警器，电压低于设定值就会蜂鸣报警，提醒我及时充电。这个小东西成本不到十块钱，换来的安全性非常值。

关于ROS2+Arduino底盘，我实际操作下来最深的体会是：架构设计比代码本身重要得多。把上层和下层的职责分清楚，接口定义好，任何一层的替换和升级都不会牵连其他层。Arduino只管速度和编码器，ROS2只管规划和感知，中间用micro-ROS这个话题通信桥接起来，整个系统既清晰又稳健。这套架构跑起来之后，后续添加传感器、升级导航算法，都只是在这个框架下做加法，不会再动底盘本身的逻辑，这也恰恰是它最珍贵的地方。