企业官网建设流程全解析

1. ROS Topic通讯的核心机制与实战小结

1.1 从“话题”说起：为什么ROS里到处都在聊Topic

刚接触ROS的人，十有八九第一个搞懂的概念就是Topic。这东西说白了就是一个广播频道，节点A往上面喊一嗓子，节点B、C、D只要调到了同一个频道，就都能听见。它解决的是机器人系统里最基础的一个问题：不同功能的程序之间怎么把数据传出去，而且传得足够松耦合。

我见过不少新手在学ROS的时候，把Topic和Service搞混，结果写出来的东西要么卡死，要么数据丢得莫名其妙。这里先把结论摆出来：Topic适合高频、单向、允许丢包的数据流，比如激光雷达的点云、摄像头的图像、电机的编码器计数；Service适合低频、双向、要求确认的操作，比如“让机械臂回到零位”这种指令。你拿Topic去发一个“必须执行”的控制指令，然后发现偶尔丢一帧导致机器人抽风，那大概率是选错了通讯方式。

Topic的通讯模型是典型的发布/订阅模式。一个节点可以同时发布多个Topic，也可以同时订阅多个Topic。发布者和订阅者互相不知道对方的存在，中间靠ROS Master来牵线搭桥。这种设计的好处是扩展性极强——你想加一个数据记录节点，直接订阅对应的Topic就行，不用改任何已有代码。坏处是调试的时候如果不知道Topic名字，就像在收音机里找电台，得一个个频段扫过去。

1.2 Topic通讯的三个关键参数：队列、频率与带宽

很多人用Topic只关心“能不能收到”，不关心“收得稳不稳”。实际做电机控制的时候，这三个参数直接决定了你的系统是流畅运行还是间歇性抽搐。

队列长度（queue_size）是第一个要盯紧的参数。发布者往Topic里塞数据，如果订阅者处理不过来，数据就会在队列里排队。队列满了之后，ROS默认的行为是丢掉最旧的数据。对于电机控制这种场景，丢一帧旧数据比堵住整个队列要好得多，因为旧的位置指令已经没有意义了。我一般会把控制指令的队列设成1到3，传感器数据的队列设成5到10，具体看处理频率。

发布频率是第二个关键点。电机的编码器读取，如果你用轮询的方式，频率太低会导致低速时测速不准，频率太高又会占满CPU。以常见的增量式编码器为例，假设电机额定转速是3000转/分，编码器线数是500线，四倍频后每转产生2000个脉冲。那么每秒的脉冲数就是3000/60×2000=100000个。这个频率下，如果你用中断方式读取，MCU还能扛住；如果用轮询，基本就废了。所以实际项目中，编码器读取要么用硬件正交解码，要么用中断加计数，轮询只适合低速场景。

带宽是第三个容易被忽视的点。Topic传输的是序列化后的消息，消息越大，占用的网络带宽和内存拷贝开销就越大。我见过有人在Topic里直接传整张未压缩的图像，结果整个系统的实时性都被拖垮了。对于电机控制，消息里只需要放目标速度、目标位置、使能标志这几个字段，用自定义的msg类型，别用std_msgs里的大块头。

提示：用rostopic hz命令可以查看某个Topic的实际发布频率，用rostopic bw可以看带宽占用。这两个命令在调试通讯问题时比看代码快得多。

1.3 用命令行工具快速验证Topic链路

在写驱动代码之前，我习惯先用命令行把整个链路跑通。这样做的好处是，如果后面代码出了问题，你可以快速判断是通讯层的问题还是驱动层的问题。

假设我们要控制一个电机，并且读取它的编码器。按照常见的做法，我们会定义两个Topic：一个用于发送控制指令，比如/motor/cmd_vel；另一个用于发布编码器数据，比如/motor/encoder。在终端里，你可以这样操作：

# 终端1：手动发布一个速度指令 rostopic pub /motor/cmd_vel std_msgs/Float32 "data: 100.0" -r 10 # 终端2：查看编码器数据是否回来 rostopic echo /motor/encoder # 终端3：查看控制指令的发布频率 rostopic hz /motor/cmd_vel

如果rostopic echo能持续打印出数据，说明驱动节点已经在正常发布编码器Topic了。如果rostopic hz显示的频率和你设定的对不上，那就要检查发布循环里是不是有阻塞操作。我踩过的一个坑是，在发布循环里加了一个ros::Duration(0.1).sleep()，结果实际频率只有5Hz，和预期的50Hz差了十倍。后来发现是sleep的时间没算上处理时间，改成ros::Rate才把频率稳住。

2. 编写ROS驱动实现电机控制与编码器读取

2.1 驱动节点的整体架构设计

写一个电机驱动节点，本质上就是搭一座桥：一边是ROS的Topic，另一边是硬件接口。桥的这头是/motor/cmd_vel订阅者，那头是PWM输出；桥的这头是编码器计数器，那头是/motor/encoder发布者。中间的逻辑就是你要写的驱动代码。

我一般会把驱动节点分成三层：通讯层负责ROS消息的收发，控制层负责把速度指令转换成PWM占空比，硬件抽象层负责直接操作寄存器或调用硬件库。这样分层的好处是，换一个电机或者换一个主控板，只需要改硬件抽象层，上面的逻辑基本不用动。

对于电机控制，常见的硬件接口有三种：GPIO+PWM、串口伺服驱动器、CAN总线驱动器。GPIO+PWM适合小功率直流电机，直接用主控的PWM外设驱动H桥；串口伺服驱动器适合需要闭环控制的场景，驱动器内部已经做好了电流环和速度环；CAN总线驱动器适合多电机协同的场景，抗干扰能力强。下面我以GPIO+PWM这种最基础也最锻炼人的方式为例，把整个流程走一遍。

2.2 电机控制的核心：从速度指令到PWM占空比

假设我们用的电机额定电压是12V，额定转速是3000转/分，编码器是500线四倍频。ROS端发过来的速度指令单位是“转/分”，我们需要把它转换成PWM的占空比。

第一步是确定PWM频率。对于有刷直流电机，PWM频率一般在1kHz到20kHz之间。频率太低，电机会发出啸叫；频率太高，H桥的开关损耗会增大。我一般选10kHz，这个频率下电机运行比较安静，MOS管也不会太热。

第二步是确定占空比和转速的关系。理想情况下，占空比和转速是线性的：50%占空比对应1500转/分，100%对应3000转/分。但实际上，电机有死区、摩擦和负载，低速时非线性很明显。所以实际项目中，我会在驱动里加一个最小占空比和最大占空比的限制，比如最小20%，最大95%。低于20%电机可能转不起来，高于95%留一点余量防止过冲。

第三步是处理方向。H桥一般有两个控制引脚：一个控制方向，一个控制使能。或者用两个PWM引脚，一个正转一个反转。我习惯用“方向+使能”的方式，因为这样只需要一个PWM通道。方向引脚根据速度指令的正负来翻转，使能引脚输出PWM波形。

// 伪代码示例：速度指令转PWM double cmd_rpm = msg->data; // 来自ROS的速度指令 double max_rpm = 3000.0; double duty = fabs(cmd_rpm) / max_rpm * 100.0; // 死区补偿 if (duty > 0 && duty < 20.0) duty = 20.0; if (duty > 95.0) duty = 95.0; // 设置方向 if (cmd_rpm >= 0) { set_gpio(DIR_PIN, HIGH); } else { set_gpio(DIR_PIN, LOW); } // 设置PWM占空比 set_pwm_duty(PWM_CHANNEL, duty);

这里有个细节：当速度指令为0时，是让电机自由滑行还是主动刹车？自由滑行就是关掉使能，电机靠惯性慢慢停；主动刹车就是让H桥的下管导通，电机绕组短路，产生反向力矩。对于需要快速停车的场景，主动刹车更合适；对于节能场景，自由滑行更好。我一般会在驱动里加一个参数来配置这个行为。

2.3 编码器读取：中断、计数与速度计算

编码器读取是电机驱动里最容易出问题的环节。常见的问题有三个：丢脉冲、方向判断错误、速度计算抖动。

丢脉冲通常是因为读取方式不对。如果你用轮询的方式读编码器引脚，当脉冲频率高于轮询频率时，就会丢脉冲。比如你每1ms轮询一次，而编码器脉冲间隔是0.5ms，那就会丢一半的脉冲。解决办法是用外部中断，每个脉冲的上升沿和下降沿都触发中断，在中断里更新计数。对于STM32这类MCU，还可以用定时器的编码器模式，硬件自动计数，完全不占CPU。

方向判断错误通常是因为A相和B相的相位关系搞反了。正交编码器的A相和B相相差90度，正转时A相超前B相，反转时B相超前A相。如果你在中断里只读了A相的电平，那就只能计数，不能判断方向。正确的做法是在A相的上升沿读B相的电平：如果B相是低电平，说明正转；如果B相是高电平，说明反转。或者在A相和B相的每个边沿都触发中断，根据两个引脚的电平组合来判断方向。

速度计算抖动是另一个常见问题。如果你直接用“单位时间内的脉冲数”来算速度，低速时脉冲数很少，算出来的速度会一跳一跳的。比如每10ms算一次速度，低速时可能只有1个脉冲，那速度就是100脉冲/秒；下一个10ms有2个脉冲，速度就变成200脉冲/秒。这种抖动会让速度环没法调。解决办法是用滑动平均滤波或者低通滤波，把最近几次的速度值做平均。我一般会用一阶低通滤波，公式是v_filtered = alpha * v_new + (1 - alpha) * v_old，alpha取0.3到0.5之间，既能跟上速度变化，又能滤掉抖动。

注意：编码器的计数方向要和电机的实际转向对应起来。我见过一个项目，编码器计数增加时电机实际在反转，结果速度环变成了正反馈，电机直接飞车。调试的时候一定要先手动转一下电机，确认编码器计数方向和电机转向一致。

2.4 完整的驱动节点代码框架

把上面的逻辑串起来，一个完整的驱动节点大概长这样：

#include <ros/ros.h> #include <std_msgs/Float32.h> #include <std_msgs/Int32.h> // 硬件抽象层 class MotorHardware { public: void init(); void setPWM(double duty); void setDirection(bool forward); int readEncoder(); void resetEncoder(); }; // 驱动节点 class MotorDriver { public: MotorDriver() : nh_("~") { // 读取参数 nh_.param("max_rpm", max_rpm_, 3000.0); nh_.param("encoder_ppr", encoder_ppr_, 2000); nh_.param("control_freq", control_freq_, 50.0); // 初始化硬件 hw_.init(); hw_.resetEncoder(); // 订阅速度指令 cmd_sub_ = nh_.subscribe("/motor/cmd_vel", 1, &MotorDriver::cmdCallback, this); // 发布编码器数据 encoder_pub_ = nh_.advertise<std_msgs::Int32>("/motor/encoder", 10); speed_pub_ = nh_.advertise<std_msgs::Float32>("/motor/speed", 10); // 启动控制循环 last_time_ = ros::Time::now(); last_encoder_ = 0; } void cmdCallback(const std_msgs::Float32::ConstPtr& msg) { target_rpm_ = msg->data; } void spin() { ros::Rate rate(control_freq_); while (ros::ok()) { // 读取编码器 int encoder = hw_.readEncoder(); // 计算速度 ros::Time now = ros::Time::now(); double dt = (now - last_time_).toSec(); if (dt > 0) { int delta = encoder - last_encoder_; double rpm = delta / (double)encoder_ppr_ / dt * 60.0; // 低通滤波 filtered_rpm_ = 0.4 * rpm + 0.6 * filtered_rpm_; // 发布 std_msgs::Int32 enc_msg; enc_msg.data = encoder; encoder_pub_.publish(enc_msg); std_msgs::Float32 spd_msg; spd_msg.data = filtered_rpm_; speed_pub_.publish(spd_msg); last_encoder_ = encoder; last_time_ = now; } // 执行控制 double duty = fabs(target_rpm_) / max_rpm_ * 100.0; if (duty > 0 && duty < 20.0) duty = 20.0; if (duty > 95.0) duty = 95.0; hw_.setDirection(target_rpm_ >= 0); hw_.setPWM(duty); ros::spinOnce(); rate.sleep(); } } private: ros::NodeHandle nh_; ros::Subscriber cmd_sub_; ros::Publisher encoder_pub_; ros::Publisher speed_pub_; MotorHardware hw_; double max_rpm_; int encoder_ppr_; double control_freq_; double target_rpm_ = 0; double filtered_rpm_ = 0; ros::Time last_time_; int last_encoder_; };

这个框架里，MotorHardware类负责和硬件打交道，MotorDriver类负责ROS通讯和控制逻辑。实际项目中，你只需要根据自己用的主控板实现MotorHardware里的几个函数就行。

3. 实操过程中的关键细节与避坑经验

3.1 硬件连接与电源处理的那些坑

电机驱动板的电源处理，是很多新手翻车的地方。我见过有人直接把12V电机和5V的MCU接在同一个电源上，结果电机一启动，MCU就复位。原因很简单：电机启动瞬间的电流冲击把电源电压拉低了，MCU的欠压复位电路动作了。

正确的做法是电机电源和逻辑电源分开。如果必须共用一个电源，至少要在电机电源和逻辑电源之间加一个LC滤波或者二极管+大电容的隔离电路。二极管防止电机反向电动势倒灌，大电容提供瞬态电流。我一般会在电机驱动板的电源输入端并一个1000uF的电解电容和一个0.1uF的陶瓷电容，前者吸收低频波动，后者滤高频噪声。

另一个坑是共地问题。如果电机驱动板和MCU板是分开供电的，一定要把两者的地连在一起。否则PWM信号没有参考地，驱动板收到的可能是乱七八糟的噪声。我习惯用一根粗一点的线把两个板子的地连起来，越短越好。

还有编码器的信号线。编码器输出一般是5V的方波，如果MCU是3.3V的，直接接上去可能会烧引脚。要么用电平转换芯片，要么用电阻分压。我一般用两个电阻分压：1kΩ和2kΩ串联，5V进来，3.3V出去。虽然简单，但很有效。

3.2 调试顺序：先开环，再闭环

很多新手一上来就把速度环、位置环全打开，结果电机要么不动，要么疯转。我建议的调试顺序是：先让电机开环转起来，再加编码器反馈，最后加闭环控制。

第一步，开环测试。写一个最简单的程序，让PWM输出固定占空比，比如50%，看电机能不能转。如果电机不转，先检查硬件：电源有没有电、H桥有没有使能、PWM引脚有没有输出。用万用表量一下电机两端的电压，如果有电压但电机不转，可能是电机坏了或者线断了。

第二步，编码器测试。手动转电机，看编码器计数有没有变化。如果计数不变，检查编码器的电源和信号线。如果计数变化但方向不对，把A相和B相的线对调一下。如果计数跳变很大，可能是信号线太长受到了干扰，加一个屏蔽线或者磁环。

第三步，闭环测试。先调速度环的P值，从小到大慢慢加，直到电机能稳定跟随速度指令。如果电机出现振荡，说明P值太大了，加一点D值来抑制振荡。如果电机响应太慢，加一点I值来消除稳态误差。这个过程需要耐心，我一般会花一两个小时来调一组参数。

提示：调PID的时候，可以用rqt_plot把目标速度和实际速度画在一起，这样能直观地看到超调、振荡和稳态误差。比盯着数字看快多了。

3.3 常见问题速查表

这个表是我自己踩坑踩出来的，基本上覆盖了80%的常见问题。剩下的20%通常是硬件本身的毛病，比如电机轴承卡死、编码器码盘脏了，这种就只能换件了。

4. 从单电机到多电机：扩展思路与实战建议

4.1 多电机控制的Topic设计

单电机跑通之后，下一步往往是控制多个电机。比如一个差速底盘有两个电机，一个机械臂有六个关节。这时候Topic的设计就很关键了。

最简单的做法是每个电机一套Topic：/motor1/cmd_vel、/motor1/encoder、/motor2/cmd_vel、/motor2/encoder。这样做的好处是逻辑清晰，每个电机独立控制。坏处是电机多了之后，Topic数量爆炸，而且多个电机需要同步的时候不好处理。

另一种做法是用一个Topic传数组：/motors/cmd_vel里放一个Float32MultiArray，每个元素对应一个电机的速度。这样做的好处是同步性好，一次发布所有电机的指令。坏处是消息类型复杂了，调试的时候不如单个Topic直观。

我一般会根据场景来选：如果是差速底盘这种只有两三个电机的，用独立Topic；如果是机械臂这种六七个电机的，用数组Topic。另外，对于需要严格同步的场景，比如多轴联动，我还会加一个/motors/sync的Topic，用来触发所有电机同时执行。

4.2 实时性与线程安全的考量

ROS1的ros::spin()是单线程的，所有的回调函数都在同一个线程里执行。如果你的驱动节点里既有高频的控制循环，又有回调函数，那回调函数可能会阻塞控制循环。比如你在回调里做了一次耗时的串口读写，控制循环就会卡住，PWM输出就会断。

解决办法是用多线程。ROS提供了ros::AsyncSpinner，可以开多个线程来执行回调。控制循环放在主线程里，回调放在其他线程里。这样即使回调偶尔卡一下，控制循环也不会受影响。

但多线程带来了新的问题：数据竞争。如果回调线程在写target_rpm_，控制线程在读target_rpm_，就需要加锁。我一般用std::mutex来保护共享变量，但锁的粒度要小，只锁读写的那一行，不要锁整个控制循环。否则锁本身就成了瓶颈。

std::mutex mtx_; double target_rpm_ = 0; void cmdCallback(const std_msgs::Float32::ConstPtr& msg) { std::lock_guard<std::mutex> lock(mtx_); target_rpm_ = msg->data; } void controlLoop() { double rpm; { std::lock_guard<std::mutex> lock(mtx_); rpm = target_rpm_; } // 用rpm执行控制，锁已经释放 }

注意：在实时性要求高的场景里，std::mutex可能会引起优先级反转。如果对实时性要求特别高，可以考虑用无锁队列或者原子变量。不过对于大多数ROS驱动来说，std::mutex已经够用了。

4.3 驱动节点的参数化与复用

写驱动的时候，我习惯把所有的硬件相关参数都做成ROS参数，而不是硬编码在代码里。比如PWM频率、最大转速、编码器线数、PID参数、最小占空比，全部通过nh_.param()来读取。这样换一个电机或者换一个主控板，只需要改launch文件里的参数，不用重新编译代码。

<launch> <node name="motor_driver" pkg="my_robot" type="motor_driver" output="screen"> <param name="max_rpm" value="3000.0"/> <param name="encoder_ppr" value="2000"/> <param name="control_freq" value="50.0"/> <param name="pwm_freq" value="10000"/> <param name="min_duty" value="20.0"/> <param name="max_duty" value="95.0"/> <param name="kp" value="0.5"/> <param name="ki" value="0.1"/> <param name="kd" value="0.01"/> </node> </launch>

这样做还有一个好处：你可以用rosparam在运行时动态修改参数。比如调试PID的时候，不用重启节点，直接rosparam set /motor_driver/kp 0.8，然后看效果。调好了再写回launch文件。

4.4 从驱动到应用：上层怎么用这些Topic

驱动写好了，上层应用怎么用呢？以差速底盘为例，上层通常会有一个base_controller节点，订阅/cmd_vel（geometry_msgs/Twist），然后根据底盘的运动学模型，把线速度和角速度分解成左右轮的速度，再发布到/motor1/cmd_vel和/motor2/cmd_vel。同时，base_controller还会订阅/motor1/encoder和/motor2/encoder，通过正运动学算出底盘的位姿，发布到/odom。

这个链条里，驱动节点只负责“让电机转”和“读编码器”，不关心底盘怎么运动。这种分层设计让每一层都可以独立测试和替换。比如你想换一个电机，只需要改驱动节点，上层的base_controller完全不用动。

我见过有人把运动学模型直接写在驱动节点里，结果换一个底盘结构就要重写驱动。这种耦合是要尽量避免的。驱动的职责就是“把ROS指令变成硬件动作，把硬件反馈变成ROS消息”，其他的事情交给上层去做。

5. 调试工具与实战技巧

5.1 用rqt工具链快速定位问题

ROS自带了一套rqt工具，用好了能省很多时间。rqt_graph可以看节点和Topic的连接关系，一眼就能看出哪个节点没连上。rqt_plot可以画Topic数据的曲线，调PID的时候特别有用。rqt_console可以看日志，驱动里用ROS_INFO打印的信息都会在这里显示。

我一般会在驱动里加一些调试输出，比如每100个控制周期打印一次实际速度和目标速度。这样在rqt_console里就能看到速度跟随的情况。如果实际速度一直跟不上目标速度，可能是P值太小或者负载太大；如果实际速度在目标速度附近振荡，可能是P值太大或者D值不够。

5.2 用rosbag记录数据离线分析

有些问题不是实时能看出来的，比如偶发的丢帧、间歇性的通讯超时。这时候rosbag就派上用场了。你可以用rosbag record把相关的Topic都录下来，然后离线用rqt_plot或者Python脚本分析。

# 录制电机相关的Topic rosbag record /motor/cmd_vel /motor/encoder /motor/speed -O motor_test.bag # 回放 rosbag play motor_test.bag # 查看bag里的Topic rosbag info motor_test.bag

我一般会在调试阶段录几个bag，把正常情况和异常情况都录下来。对比分析的时候，很容易就能看出异常情况下哪个Topic的数据不对。比如正常时编码器计数是单调递增的，异常时出现了跳变，那就能定位到是编码器信号受到了干扰。

5.3 编码器测速的精度提升技巧

如果你对测速精度要求比较高，比如要做高精度的速度闭环，那普通的“单位时间脉冲数”方法可能不够。这时候可以用T法测速或者M/T法测速。

M法就是上面说的，固定时间间隔数脉冲，适合高速。T法就是固定脉冲数，测时间间隔，适合低速。M/T法结合两者，高速时用M法，低速时用T法，全速范围内都能保持较高精度。

实现M/T法需要一个高频的计时器，比如1MHz的定时器。在编码器脉冲的上升沿读取计时器的值，两个脉冲之间的时间差就是脉冲周期。速度就是1 / (脉冲周期 * 编码器线数)。这种方法在低速时特别准，因为低速时脉冲周期长，计时器的分辨率足够。

不过M/T法的实现复杂度比M法高不少，需要硬件定时器的支持。如果你的主控没有多余的定时器，或者对精度要求没那么高，M法加低通滤波也够用了。

5.4 驱动节点的启动与关闭处理

驱动节点在启动和关闭的时候，有一些事情必须做。启动的时候，要把电机使能引脚拉低，确保电机不会突然转起来。关闭的时候，要把PWM输出关掉，让电机自由滑行或者主动刹车，避免节点挂了之后电机还在转。

ROS提供了ros::shutdown()的回调，可以在节点关闭前执行清理操作。我一般会注册一个shutdown回调，在里面关PWM、关使能、释放硬件资源。

void shutdownCallback() { hw_.setPWM(0); hw_.setDirection(false); hw_.disable(); ROS_INFO("Motor driver shutdown, hardware disabled."); } // 在main函数里注册 ros::on_shutdown(shutdownCallback);

另外，如果节点是异常退出的，比如被kill -9杀掉的，shutdown回调不会执行。这时候硬件可能会保持最后的状态。所以硬件上最好有一个看门狗，如果一段时间没收到PWM更新，就自动关断输出。很多电机驱动芯片自带这个功能，选型的时候可以留意一下。

6. 从Topic通讯到驱动开发的进阶路线

6.1 什么时候该从Topic切换到其他通讯方式

Topic虽然好用，但不是万能的。如果你发现你的控制指令偶尔会丢，或者你需要确认指令是否被执行了，那就该考虑换通讯方式了。

Service适合“请求-响应”式的操作，比如“读取当前编码器值”、“设置PID参数”、“校准编码器零位”。这些操作不需要高频执行，但需要确认结果。用Service的好处是调用方会阻塞等待结果，不用担心丢包。

Action适合“长时间执行、可以中途取消”的操作，比如“让电机转到指定位置”。Action底层是Topic+Service的组合，既有Topic的实时反馈，又有Service的确认机制。如果你要做位置控制，Action比Topic更合适。

Parameter适合“配置”类的数据，比如最大速度、PID参数。这些数据不需要频繁更新，用Parameter Server来管理最方便。

我一般的选型原则是：高频数据流用Topic，低频操作用Service，长时任务用Action，配置参数用Parameter。按照这个原则，电机驱动里的速度指令用Topic，编码器读取用Topic，使能/失能用Service，位置控制用Action。

6.2 驱动代码的测试策略

驱动代码的测试比上层应用代码要难，因为它依赖硬件。但也不是完全没法测。我一般会分三层来测：

单元测试：把硬件抽象层mock掉，用假的编码器数据和假的PWM输出，测试控制逻辑是否正确。比如给定一个速度指令，看PWM占空比算得对不对；给定一串编码器脉冲，看速度算得对不对。这部分可以用gtest来做，不需要硬件。

集成测试：把驱动节点和硬件连起来，用rostopic pub手动发指令，看电机是否按预期动作。这部分需要硬件，但不需要上层应用。

系统测试：把驱动节点和上层应用连起来，跑完整的任务流程。比如让底盘走一个正方形，看轨迹是否闭合。这部分需要整个系统都就绪。

我见过很多人跳过单元测试，直接做系统测试。结果出了问题不知道是驱动的问题还是上层的问题，排查起来特别费劲。花半个小时写几个单元测试，后面能省好几个小时。

6.3 驱动开发的常见误区

第一个误区是在回调函数里做耗时操作。比如在速度指令的回调里做串口通信，串口通信可能要几毫秒，这几毫秒里控制循环就停了。正确的做法是在回调里只更新目标值，实际的控制在独立的控制循环里做。

第二个误区是忽略编码器的溢出。编码器计数器一般是16位或32位的，转多了会溢出。如果你不做溢出处理，速度计算就会出现巨大的跳变。解决办法是用int64_t来存累计计数，每次读取时把当前计数和上次计数做差，然后累加。这样即使硬件计数器溢出了，软件里的累计值也不会错。

第三个误区是不做异常处理。电机堵转、编码器断线、电源掉电，这些异常如果不处理，轻则驱动节点崩溃，重则烧电机。我一般会在驱动里加一些保护逻辑：电流超过阈值就降速，编码器长时间没变化就报错，通讯超时就停车。这些保护逻辑平时用不上，但关键时刻能救你一命。

6.4 继续深入的方向

如果你已经把单电机的Topic通讯和驱动写通了，下一步可以往这几个方向深入：

多电机同步：研究如何让多个电机严格同步，比如用CAN总线的同步帧，或者用ROS的message_filters做时间同步。

实时性优化：研究如何降低控制循环的抖动，比如用SCHED_FIFO实时调度策略，或者把控制循环放到单独的CPU核心上。

硬件加速：研究如何用FPGA或者专用的运动控制芯片来分担MCU的负担，让MCU专注于ROS通讯。

安全机制：研究如何做功能安全，比如双编码器冗余、看门狗、安全扭矩关断。这些在工业场景里是必须的。

每一条路都有很多坑，但也都有很多乐趣。我自己的经验是，先把一条路走通，再走第二条。不要贪多，贪多嚼不烂。

提示：ROS的官方wiki和社区论坛是很好的资源，但上面的内容质量参差不齐。看的时候要带着批判性思维，最好自己动手验证一下。我见过不少wiki上的示例代码其实是有bug的，直接抄会踩坑。

最后再分享一个小技巧：如果你在调试电机驱动的时候，发现电机偶尔会抽一下，但找不到规律，可以试试在PWM输出和编码器读取之间加一个小的延时。有时候是因为PWM的开关噪声耦合到了编码器信号线上，导致编码器误计数。加一个1us到10us的延时，等PWM稳定了再读编码器，往往能解决问题。这个技巧是我在一个项目里偶然发现的，后来成了我的标配操作。