尧图网站建设 
简介这是一套基于ROS与STM32F1的小车完整代码及项目说明适合计算机、嵌入式、机器人相关专业学生用于课程设计、期末大作业或毕业设计实践。项目以串口通信为桥梁完整演示了ROS端任务调度、状态监控与数据处理以及STM32F1端电机驱动、传感器读取等硬件控制流程并涉及gmapping、amcl、move_base等导航栈应用帮助学习者掌握机器人系统与嵌入式协同开发的整体思路。资源压缩包共282个文件约6.92MB主要包含C/C源码、头文件、编译生成的axf/hex固件与o/d文件以及uvproj工程配置、sct链接脚本、map映射文件和txt说明文档等代码工程结构清晰便于按模块查阅。目前已有61人学习使用尤其适合需要从零搭建ROS小车项目、理解串口通信协议与底层驱动编写的读者。借助这套资料学习者可结合详细项目说明快速复现小车运动控制流程并通过实际调试积累排错经验为更复杂的机器人项目打下基础。1. 为什么是 ROS STM32F1 串口通信这套小车架构的真正分工如果你在找“基于ros和stm32f1的小车代码串口通信详细项目说明.zip”这套资源大概率是入了机器人开发的坑手头有一块 STM32F103 核心板、一台玩具车底盘想在上面跑 ROS却不知道怎么把两边接起来。市面上大多数教程要么只讲 ROS 侧的 move_base 和 gmapping要么只讲 STM32 的寄存器操作真正卡住人的——“下位机收到一串十六进制数据怎么解析、解析完怎么控制电机、编码器数据怎么回传成 ROS 里程计”——恰好是中间那条串口链路。这套架构里STM32F1 管实时性和硬件ROS 管决策和算法串口是唯一桥梁。无论你最终是想要 SLAM 导航还是遥控这个桥必须先搭对。本文不评析任何具体项目包而是讲清楚这套组合从零到联调的标准做法让新手能照做让老手能对照检查自己的参数选择和边界条件。2. 串口通信协议设计让 STM32 和 ROS 说同一种语言2.1 为什么这里选串口而不是 CAN 或 I2C在做两轮或四轮差速小车时不少初学者第一反应是问“能不能用蓝牙”“能不能走 WiFi”。当然能但串口是这套组合最稳妥、最不容易出错的物理链路STM32F1 的 USART 外设是标配ROS 端无论是树莓派还是 PCUSB-TTL 模块即插即用。串口还有一个优势——它足够低级协议完全由你定义出现问题时可以拉逻辑分析仪一个字节一个字节地看不需要像 CAN 那样处理仲裁和掩码也不需要像 I2C 那样关心上拉电阻和地址冲突。串口的选型还要考虑波特率。老工程师常选 115200因为它在 8N1 格式下约等于每秒 11.5KB 有效数据足够承载 20Hz 的里程计加上 50Hz 的控制指令。而 9600 虽然抗干扰更强但在大数据量时会成为瓶颈。我自己通常默认 115200只有在遇到严重丢帧且排除协议问题后才降到 57600。2.2 一帧数据的标准格式帧头、长度、指令、数据、校验通信协议是整个项目的灵魂。很多小车跑不起来根本不是电机问题而是下位机和上位机对“一帧数据”的理解不一致。一个健壮的串口帧格式必须包含五个部分帧头、数据长度、指令字、数据区、校验字节。STM32 接收端的推荐链路层解析逻辑可以写成#define FRAME_HEADER 0xAA #define FRAME_SIZE_MAX 16 uint8_t rx_buffer[FRAME_SIZE_MAX]; uint8_t rx_index 0; // 在 USART1 中断里调用按字节喂入 void uart_receive_byte(uint8_t byte) { if (rx_index 0 byte ! FRAME_HEADER) return; // 未捕获帧头之前丢弃所有非帧头字节 rx_buffer[rx_index] byte; if (rx_index 4) // 长度字段在帧头(1) 长度(1) 指令(1) 校验(1) 之后 { uint8_t payload_len rx_buffer[1]; if (rx_index payload_len 4) { uint8_t checksum 0; for (uint8_t i 0; i payload_len 3; i) checksum ^ rx_buffer[i]; if (checksum rx_buffer[rx_index - 1]) { protocol_handler(rx_buffer[2], rx_buffer[3], payload_len 0x0F); } rx_index 0; // 无论校验是否通过清空状态机等待下一帧 } } }这个状态机最关键的细节是只有捕获到帧头 AA 才开始存储否则直接丢弃。这样做的好处是即使线路中出现噪声字节状态机也能在下一个帧头前自我恢复。校验用的是单字节 XOR比累加和更简单比 CRC8 更快适合 F1 这种主频 72MHz 的 MCU如果你传输的是地图或点云这种大块数据再去考虑 CRC16。2.3 定义下行的指令集和上行的回馈集协议里指令字的设计决定了扩展性。我一般会把指令字按字节分割高四位表示指令类别1 代表运动控制2 代表参数设置3 代表状态查询低四位表示具体命令。例如0x11是线速度和角速度下发0x21是设置 PID 参数0x31是查询电池电压。上行数据同样需要协议不是仅回 ACK而是要把左右编码器累计值、瞬时速度、imu 数值都组帧传回去。特别注意STM32 端的上行帧和下行帧最好用相同的帧头但不同的指令字区间方便 ROS 端做区分。这样 ROS 解析代码只需要一个函数通过读 switch-case 选择处理逻辑。3. STM32F1 端实现电机控制、编码器和串口指令解析3.1 用定时器生成 PWMTIM2 做控制通道TIM4 做编码器捕获STM32F103C8T6 有多个定时器合理的分工是TIM2 输出两路 PWM 分别控制左右电机TIM4 工作在编码器模式同时采集两个电机的正交解码信号。这样硬件上天然隔离了控制与反馈不会出现同一个定时器既要输出脉冲又要捕获计数器的冲突。PWM 初始化中最容易被忽略的是死区补偿和频率选择。对于常见的 TB6612 驱动模块我通常把 PWM 频率定在 10kHz 到 20kHz 之间。频率太低电机会发出尖锐噪声且电流纹波大频率太高则会增加 MOSFET 的开关损耗。方向控制用两个 GPIO 引脚PWM 频率只负责速度大小——这比用方向引脚加 PWM 的混合模式更好排查因为如果小车只往一个方向转单独测试 GPIO 电平就能定位问题。编码器模式配置的标准写法// TIM4 编码器模式PA6/PA7 接编码器 A/B 相 void encoder_init(void) { RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM4, ENABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitTypeDef gpio { .GPIO_Pin GPIO_Pin_6 | GPIO_Pin_7, .GPIO_Mode GPIO_Mode_IN_FLOATING, }; GPIO_Init(GPIOA, gpio); TIM_TimeBaseInitTypeDef tim; TIM_TimeBaseStructInit(tim); tim.TIM_Prescaler 0; tim.TIM_Period 0xFFFF; // 16位自动重装载 TIM_TimeBaseInit(TIM4, tim); TIM_EncoderInterfaceConfig(TIM4, TIM_EncoderMode_TI12, TIM_ICPolarity_Rising, TIM_ICPolarity_Rising); TIM_Cmd(TIM4, ENABLE); }编码器模式配置完成之后读取当前累计值只需要读TIM4-CNT。注意要在主循环中以固定周期推荐 10ms读取一次然后立刻清零或者记录上一次的值做差值。用差值计算速度比用累计值除以时间更稳定因为不会受到计数器回绕的影响。3.2 串口指令解析后的控制逻辑速度环必须放在 MCU 侧下位机收到0x11指令后数据区携带的通常是目标线速度v和目标角速度w。MCU 要做的是根据差速模型分解成左右轮目标速度然后走 PID 闭环。不要把 PID 放在 ROS 侧通过串口周期修正——串口延迟在 10ms 量级时PID 会严重震荡。// 差速模型轮距 wheel_base轮半径 wheel_radius void set_target_velocity(float v, float w) { float v_left (v - w * wheel_base / 2.0f) / wheel_radius; float v_right (v w * wheel_base / 2.0f) / wheel_radius; pid_left.target v_left; pid_right.target v_right; } // 10ms 定时中断里执行一次 void motor_control_tick(void) { int16_t enc_left TIM4-CNT; TIM4-CNT 0; float speed_left enc_to_angular(enc_left); // 编码器脉冲 - rad/s float pwm_left pid_update(pid_left, speed_left); motor_set_speed(MOTOR_LEFT, pwm_left); // 右侧同理 }enc_to_angular的换算要写清楚角速度 脉冲数 / (减速比 * 线数 * 定时周期 * 2π)。如果你的电机是 1:30 减速箱、编码器每圈 13 线那么 MCU 计数器每转一圈得到的脉冲数就是 30 * 13 * 4 15604 倍频。这个数错了后续里程计会全盘偏掉误差可达 30% 以上。建议在调试阶段把换算系数打印出来手动推车 1 米看反馈值是否接近 1 米。3.3 串口回传把编码器数据打包成上行帧上行帧里除了速度值我建议顺带把 PID 的 error 值和当前 PWM 占空比也打出来。这样你在 ROS 端看数据时可以快速分辨是控制问题还是通信问题——如果 error 一直很大但 PWM 已经饱和说明目标速度超过电机能力如果 error 很小但 PWM 在震荡说明 PID 参数过激进。上行发送不要放在中断里做耗时操作。正确做法是在定时中断里填好发送缓冲区置一个标志位然后在主循环里调用UART_SendData逐字节发送。72MHz 的 F1 跑 115200 波特率发送一帧 16 字节大约需要 1.4ms这在 10ms 控制周期内完全可行。4. ROS 端实现serial 驱动节点、里程计计算与指令下发4.1 用 C 写一个串口驱动节点不要用 Python 起步虽然 Python 的 pyserial 写起来更短但 ROS 里你最终要跑整套导航栈C 节点在效率和与 move_base 的集成性上都有优势。使用serial库代码结构通常是这样#include ros/ros.h #include serial/serial.h #include geometry_msgs/Twist.h #include nav_msgs/Odometry.h // 订阅/cmd_vel回传/odom int main(int argc, char** argv) { ros::init(argc, argv, stm32_link); ros::NodeHandle nh(~); std::string port nh.paramstd::string(port, /dev/ttyUSB0); int baud nh.paramint(baudrate, 115200); serial::Serial ser(port, baud, serial::Timeout::simpleTimeout(10)); // 打开串口失败直接返回错误码 if (!ser.isOpen()) { ROS_ERROR(Failed to open port %s, port.c_str()); return -1; } ros::Subscriber sub_twist nh.subscribe(/cmd_vel, 10, twist_callback); ros::Publisher pub_odom nh.advertisenav_msgs::Odometry(/odom, 10); ros::Rate loop_rate(50); // 和 STM32 上行频率匹配 while (ros::ok()) { // 读取串口解析一帧 // 调用发布 odom 的函数 ros::spinOnce(); loop_rate.sleep(); } return 0; }4.2 /cmd_vel 到串口帧数据换算与字节序问题ROS 里的geometry_msgs::Twist给出的是线速度m/s和角速度rad/s你需要把它们转成 STM32 侧的浮点格式。常见做法是不采用 IEEE754 浮点直接传输而是先乘以 1000 转成 int16。原因有两点一是数据长度固定为 2 字节便于协议设计二是避开大小端问题——传输时统一高字节在前MCU 端组合即可。void twist_callback(const geometry_msgs::Twist::ConstPtr msg) { uint8_t frame[10]; frame[0] 0xAA; // 帧头 frame[1] 0x04; // 数据区长度 4 frame[2] 0x11; // 指令运动控制 int16_t v (int16_t)(msg-linear.x * 1000); int16_t w (int16_t)(msg-angular.z * 1000); frame[3] (v 8) 0xFF; frame[4] v 0xFF; frame[5] (w 8) 0xFF; frame[6] w 0xFF; frame[7] frame[0] ^ frame[1] ^ frame[2] // 省略后续字节 ^ frame[3] ^ frame[4] ^ frame[5] ^ frame[6]; ser.write(frame, 8); }注意这里的1000倍率。如果你后续要跑 SLAM 导航线速度精度到 1mm/s角速度精度到 0.001rad/s完全够用。如果 STM32 端用的是short类型倍率选 1000 不会溢出±32.7m/s而选 10000 在极限速度时会超过 int16 范围是一个隐蔽 bug。4.3 从 MCU 帧计算里程计并发布 TF里程计的计算公式不复杂难点在于发布时序必须先发布 TFodom到base_link再发布nav_msgs/Odometry消息。因为 move_base 和 AMCL 都会同时监听 TF 和 odom如果 TF 没到定位节点会直接报错。// 假设收到左右轮速度 v_l, v_r单位 m/sdt 是距上帧时间 double v (v_left v_right) / 2.0; double w (v_right - v_left) / wheel_base_; double dth w * dt; x_ v * cos(th_) * dt; y_ v * sin(th_) * dt; th_ dth; tf::Quaternion q; q.setRPY(0, 0, th_); // 先广播 TF transformStamped.transform.translation.x x_; transformStamped.transform.translation.y y_; transformStamped.transform.rotation.x q.x(); // ... 发布 transform // 再发布 Odometry odom.pose.pose.position.x x_; odom.pose.pose.position.y y_; odom.pose.pose.orientation.x q.x(); // ... 填充协方差并发布这里的wheel_base_必须与 STM32 端用到的轮距严格一致否则会出现“速度控制正确但轨迹画不出来”的怪现象。更隐蔽的问题是ROS 端的th_是 float 累加长时间运行后漂移是必然的。工程上每 5 分钟可以接受如果漂移明显那是轮距或编码器换算系数的问题不要用陀螺仪硬掰。5. 联调流程与常见问题排查从 USB-TTL 到整机运行5.1 用分步接法定位故障层不要直接开 move_base拿到任何小车代码包第一件事不是编译后直接上电跑导航。我习惯做三步隔离每一层通过后再往下走。第一步USB-TTL 接 PC不开 ROS。在 PC 上用串口助手手动发帧头AA 04 11 00 64 00 00看 STM32 是否回传数据电机是否转动。这步验证的是 USB-TTL 模块、STM32 解析逻辑和电机驱动。第二步用 Python 或serial命令行工具替换串口助手做同样的发送。这步验证的是 PC 上串口权限与路径是否正确。第三步再启动 ROS 节点用rostopic pub发cmd_vel。如果你跳过步骤一二直接做第三步出问题时你会同时面临“是板子问题、协议问题、还是 ROS 节点问题”三个变量。我在实际项目中见过大量案例最后定位到是 USB-TTL 模块的 TX/RX 接反了。这是串口通信里最高频的错误排查方法极简单——互相对调 TX 和 RX 再试一次即可。5.2 串口权限与硬件识别在 Ubuntu 上跑 ROS串口权限是一个几乎必踩的坑。接入 USB-TTL 后设备名通常是/dev/ttyUSB0。直接运行节点会报Permission denied原因是当前用户不在dialout用户组中。解决方法sudo usermod -a -G dialout $USER执行后必须重新登录才能生效或者重启。用ls -l /dev/ttyUSB0可以确认当前权限。另一个常见问题是插了两块 USB-TTL 时设备号漂移解决方案是使用 udev 规则绑定设备的idVendor和idProduct或者直接用/dev/serial/by-id/下的符号链接来替代写死的/dev/ttyUSB0。5.3 数据乱码和丢帧波形、波特率、接地三件事串口通信乱码有三大诱因。第一波特率不匹配——这是最白痴也最常见的错误常发生在你改过 STM32 端配置但 ROS 端 yaml 里的参数没同步改。第二共地问题——USB-TTL 的 GND 必须和 STM32 的 GND 接在一起否则两边电平参考不一致接收端采到的信号全是噪声。第三干扰导致丢帧——电机转动瞬间电流波动会耦合到串口线上如果你发现小车一动通信就断优先检查电源是否隔离或串口线是否与电机电源线绑扎在一起。遇到数据偶尔乱码时先用示波器或逻辑分析仪看 TX 引脚波形。正常 115200 波特率下一个位宽约 8.68μs如果波形里有毛刺或上升沿不干净优先在串口线上串一个 100Ω 电阻并确保走线尽量短。如果是 STM32F1 的 USART 配置问题检查是否误开了USART_IT_ORE中断——溢出错误在中断里没处理时会导致后续所有数据错位。# 在终端观察原始字节确认数据是否到达 sudo tio /dev/ttyUSB0 -b 115200 # 或使用 Python 快速抓取 python3 -c import serial; sserial.Serial(/dev/ttyUSB0,115200); print(s.read(32))5.4 上位机和下位机的启动顺序如果遇到“ROS 节点启动后串口没反应”的情况多数是下位机先于上位机启动而上位机在打开串口时对下位机发了一个复位信号DTR 引脚电平变化。STM32F103C8T6 的 BOOT0 和 NRST 如果受到 DTR 影响会导致芯片意外复位或进入 Bootloader 模式。规避的方式有两种一是硬件上把 USB-TTL 模块的 DTR/RTS 跳线帽拔掉或断开二是在软件上让 STM32 收到一个空串口数据时才进行初始化握手而不是上电就进入运行态。这类问题隐蔽但如果遇到了你可以这样验证先启动 ROS 节点再给 STM32 上电如果此时一切正常那就是启动顺序 DTR 共同导致的问题。6. 最后值得带走的三个调试技巧在线改 PID、串口看波形、任务收尾6.1 在线 PID 调参用上位机指令免重新烧录第一个技巧是把 PID 参数做成可在线修改的。在协议中预留0x21指令字数据区包含 Kp、Ki、Kd 三个浮点值各乘以 1000STM32 收到后更新到全局变量中。这样你在跑车时只需要在 PC 端发一组数据就能现场观察响应变化不用每次改代码重新编译烧录。烧录一次 STM32 至少耗时 5 秒加上重启和重新初始化累计起来会严重影响调试节奏——在线调参能把单次实验周期压缩到 3 秒以内。更关键的是你可以在小车运动过程中连续微调这在传统烧录模式下根本做不到。6.2 串口示波器让调试信息可见化第二个技巧与 ROS 可视化无关而是直接用串口打印曲线。我一般会在 STM32 端每 20ms 打印一串格式化数据形如v_left, v_right, pid_out用 kst 或 Arduino 串口绘图器连接在同一端口上。它比 ROS 的rqt_plot更轻因为不经过任何中间节点延迟看到的是 MCU 侧的第一手数据。如果这里曲线平滑但 ROS 端收到的 /odom 有跳变问题就在解析代码或数据回传协议上如果这里就有毛刺优先检查编码器接线。调试结束时记得把这些调试打印关闭——不是删掉而是用宏或条件编译包起来因为大量串口打印会占用带宽导致控制指令帧被延迟处理表现为“遥控时有明显迟滞”。例如实测下来 115200 波特率留出 20% 带宽给调试打印不会影响控制但超过 50% 时就开始出现帧间间隔抖动。6.3 里程计校准的标准动作跑直线和原地旋转最后一个技巧是关于里程计的验收。在投入 SLAM 之前一定要做两个标准的校准动作让小车沿直线走 2 米检查 /odom 里的位移是不是 1.9~2.1 米之间再原地旋转 360°检查角度是不是 355°~365°。这两个数据不达标建图一定飘而且你无法判断是激光雷达问题还是里程计问题——因为两者在 AMCL 里相互耦合。直线偏差大时调整左右轮换算系数通常是左右电机减速比有细微差异旋转偏差大时调整wheel_base_而且一次调整后必须重新做直线校准。把这个套路称为“先 L 后 R”养成习惯后这套 ROS STM32 的串口链路才算是真正能交付的状态。本文还有配套的精品资源点击获取 ROS+STM32小车串口通信实战：协议设计、电机控制与联调
简介这是一套基于ROS与STM32F1的小车完整代码及项目说明适合计算机、嵌入式、机器人相关专业学生用于课程设计、期末大作业或毕业设计实践。项目以串口通信为桥梁完整演示了ROS端任务调度、状态监控与数据处理以及STM32F1端电机驱动、传感器读取等硬件控制流程并涉及gmapping、amcl、move_base等导航栈应用帮助学习者掌握机器人系统与嵌入式协同开发的整体思路。资源压缩包共282个文件约6.92MB主要包含C/C源码、头文件、编译生成的axf/hex固件与o/d文件以及uvproj工程配置、sct链接脚本、map映射文件和txt说明文档等代码工程结构清晰便于按模块查阅。目前已有61人学习使用尤其适合需要从零搭建ROS小车项目、理解串口通信协议与底层驱动编写的读者。借助这套资料学习者可结合详细项目说明快速复现小车运动控制流程并通过实际调试积累排错经验为更复杂的机器人项目打下基础。1. 为什么是 ROS STM32F1 串口通信这套小车架构的真正分工如果你在找“基于ros和stm32f1的小车代码串口通信详细项目说明.zip”这套资源大概率是入了机器人开发的坑手头有一块 STM32F103 核心板、一台玩具车底盘想在上面跑 ROS却不知道怎么把两边接起来。市面上大多数教程要么只讲 ROS 侧的 move_base 和 gmapping要么只讲 STM32 的寄存器操作真正卡住人的——“下位机收到一串十六进制数据怎么解析、解析完怎么控制电机、编码器数据怎么回传成 ROS 里程计”——恰好是中间那条串口链路。这套架构里STM32F1 管实时性和硬件ROS 管决策和算法串口是唯一桥梁。无论你最终是想要 SLAM 导航还是遥控这个桥必须先搭对。本文不评析任何具体项目包而是讲清楚这套组合从零到联调的标准做法让新手能照做让老手能对照检查自己的参数选择和边界条件。2. 串口通信协议设计让 STM32 和 ROS 说同一种语言2.1 为什么这里选串口而不是 CAN 或 I2C在做两轮或四轮差速小车时不少初学者第一反应是问“能不能用蓝牙”“能不能走 WiFi”。当然能但串口是这套组合最稳妥、最不容易出错的物理链路STM32F1 的 USART 外设是标配ROS 端无论是树莓派还是 PCUSB-TTL 模块即插即用。串口还有一个优势——它足够低级协议完全由你定义出现问题时可以拉逻辑分析仪一个字节一个字节地看不需要像 CAN 那样处理仲裁和掩码也不需要像 I2C 那样关心上拉电阻和地址冲突。串口的选型还要考虑波特率。老工程师常选 115200因为它在 8N1 格式下约等于每秒 11.5KB 有效数据足够承载 20Hz 的里程计加上 50Hz 的控制指令。而 9600 虽然抗干扰更强但在大数据量时会成为瓶颈。我自己通常默认 115200只有在遇到严重丢帧且排除协议问题后才降到 57600。2.2 一帧数据的标准格式帧头、长度、指令、数据、校验通信协议是整个项目的灵魂。很多小车跑不起来根本不是电机问题而是下位机和上位机对“一帧数据”的理解不一致。一个健壮的串口帧格式必须包含五个部分帧头、数据长度、指令字、数据区、校验字节。STM32 接收端的推荐链路层解析逻辑可以写成#define FRAME_HEADER 0xAA #define FRAME_SIZE_MAX 16 uint8_t rx_buffer[FRAME_SIZE_MAX]; uint8_t rx_index 0; // 在 USART1 中断里调用按字节喂入 void uart_receive_byte(uint8_t byte) { if (rx_index 0 byte ! FRAME_HEADER) return; // 未捕获帧头之前丢弃所有非帧头字节 rx_buffer[rx_index] byte; if (rx_index 4) // 长度字段在帧头(1) 长度(1) 指令(1) 校验(1) 之后 { uint8_t payload_len rx_buffer[1]; if (rx_index payload_len 4) { uint8_t checksum 0; for (uint8_t i 0; i payload_len 3; i) checksum ^ rx_buffer[i]; if (checksum rx_buffer[rx_index - 1]) { protocol_handler(rx_buffer[2], rx_buffer[3], payload_len 0x0F); } rx_index 0; // 无论校验是否通过清空状态机等待下一帧 } } }这个状态机最关键的细节是只有捕获到帧头 AA 才开始存储否则直接丢弃。这样做的好处是即使线路中出现噪声字节状态机也能在下一个帧头前自我恢复。校验用的是单字节 XOR比累加和更简单比 CRC8 更快适合 F1 这种主频 72MHz 的 MCU如果你传输的是地图或点云这种大块数据再去考虑 CRC16。2.3 定义下行的指令集和上行的回馈集协议里指令字的设计决定了扩展性。我一般会把指令字按字节分割高四位表示指令类别1 代表运动控制2 代表参数设置3 代表状态查询低四位表示具体命令。例如0x11是线速度和角速度下发0x21是设置 PID 参数0x31是查询电池电压。上行数据同样需要协议不是仅回 ACK而是要把左右编码器累计值、瞬时速度、imu 数值都组帧传回去。特别注意STM32 端的上行帧和下行帧最好用相同的帧头但不同的指令字区间方便 ROS 端做区分。这样 ROS 解析代码只需要一个函数通过读 switch-case 选择处理逻辑。3. STM32F1 端实现电机控制、编码器和串口指令解析3.1 用定时器生成 PWMTIM2 做控制通道TIM4 做编码器捕获STM32F103C8T6 有多个定时器合理的分工是TIM2 输出两路 PWM 分别控制左右电机TIM4 工作在编码器模式同时采集两个电机的正交解码信号。这样硬件上天然隔离了控制与反馈不会出现同一个定时器既要输出脉冲又要捕获计数器的冲突。PWM 初始化中最容易被忽略的是死区补偿和频率选择。对于常见的 TB6612 驱动模块我通常把 PWM 频率定在 10kHz 到 20kHz 之间。频率太低电机会发出尖锐噪声且电流纹波大频率太高则会增加 MOSFET 的开关损耗。方向控制用两个 GPIO 引脚PWM 频率只负责速度大小——这比用方向引脚加 PWM 的混合模式更好排查因为如果小车只往一个方向转单独测试 GPIO 电平就能定位问题。编码器模式配置的标准写法// TIM4 编码器模式PA6/PA7 接编码器 A/B 相 void encoder_init(void) { RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM4, ENABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitTypeDef gpio { .GPIO_Pin GPIO_Pin_6 | GPIO_Pin_7, .GPIO_Mode GPIO_Mode_IN_FLOATING, }; GPIO_Init(GPIOA, gpio); TIM_TimeBaseInitTypeDef tim; TIM_TimeBaseStructInit(tim); tim.TIM_Prescaler 0; tim.TIM_Period 0xFFFF; // 16位自动重装载 TIM_TimeBaseInit(TIM4, tim); TIM_EncoderInterfaceConfig(TIM4, TIM_EncoderMode_TI12, TIM_ICPolarity_Rising, TIM_ICPolarity_Rising); TIM_Cmd(TIM4, ENABLE); }编码器模式配置完成之后读取当前累计值只需要读TIM4-CNT。注意要在主循环中以固定周期推荐 10ms读取一次然后立刻清零或者记录上一次的值做差值。用差值计算速度比用累计值除以时间更稳定因为不会受到计数器回绕的影响。3.2 串口指令解析后的控制逻辑速度环必须放在 MCU 侧下位机收到0x11指令后数据区携带的通常是目标线速度v和目标角速度w。MCU 要做的是根据差速模型分解成左右轮目标速度然后走 PID 闭环。不要把 PID 放在 ROS 侧通过串口周期修正——串口延迟在 10ms 量级时PID 会严重震荡。// 差速模型轮距 wheel_base轮半径 wheel_radius void set_target_velocity(float v, float w) { float v_left (v - w * wheel_base / 2.0f) / wheel_radius; float v_right (v w * wheel_base / 2.0f) / wheel_radius; pid_left.target v_left; pid_right.target v_right; } // 10ms 定时中断里执行一次 void motor_control_tick(void) { int16_t enc_left TIM4-CNT; TIM4-CNT 0; float speed_left enc_to_angular(enc_left); // 编码器脉冲 - rad/s float pwm_left pid_update(pid_left, speed_left); motor_set_speed(MOTOR_LEFT, pwm_left); // 右侧同理 }enc_to_angular的换算要写清楚角速度 脉冲数 / (减速比 * 线数 * 定时周期 * 2π)。如果你的电机是 1:30 减速箱、编码器每圈 13 线那么 MCU 计数器每转一圈得到的脉冲数就是 30 * 13 * 4 15604 倍频。这个数错了后续里程计会全盘偏掉误差可达 30% 以上。建议在调试阶段把换算系数打印出来手动推车 1 米看反馈值是否接近 1 米。3.3 串口回传把编码器数据打包成上行帧上行帧里除了速度值我建议顺带把 PID 的 error 值和当前 PWM 占空比也打出来。这样你在 ROS 端看数据时可以快速分辨是控制问题还是通信问题——如果 error 一直很大但 PWM 已经饱和说明目标速度超过电机能力如果 error 很小但 PWM 在震荡说明 PID 参数过激进。上行发送不要放在中断里做耗时操作。正确做法是在定时中断里填好发送缓冲区置一个标志位然后在主循环里调用UART_SendData逐字节发送。72MHz 的 F1 跑 115200 波特率发送一帧 16 字节大约需要 1.4ms这在 10ms 控制周期内完全可行。4. ROS 端实现serial 驱动节点、里程计计算与指令下发4.1 用 C 写一个串口驱动节点不要用 Python 起步虽然 Python 的 pyserial 写起来更短但 ROS 里你最终要跑整套导航栈C 节点在效率和与 move_base 的集成性上都有优势。使用serial库代码结构通常是这样#include ros/ros.h #include serial/serial.h #include geometry_msgs/Twist.h #include nav_msgs/Odometry.h // 订阅/cmd_vel回传/odom int main(int argc, char** argv) { ros::init(argc, argv, stm32_link); ros::NodeHandle nh(~); std::string port nh.paramstd::string(port, /dev/ttyUSB0); int baud nh.paramint(baudrate, 115200); serial::Serial ser(port, baud, serial::Timeout::simpleTimeout(10)); // 打开串口失败直接返回错误码 if (!ser.isOpen()) { ROS_ERROR(Failed to open port %s, port.c_str()); return -1; } ros::Subscriber sub_twist nh.subscribe(/cmd_vel, 10, twist_callback); ros::Publisher pub_odom nh.advertisenav_msgs::Odometry(/odom, 10); ros::Rate loop_rate(50); // 和 STM32 上行频率匹配 while (ros::ok()) { // 读取串口解析一帧 // 调用发布 odom 的函数 ros::spinOnce(); loop_rate.sleep(); } return 0; }4.2 /cmd_vel 到串口帧数据换算与字节序问题ROS 里的geometry_msgs::Twist给出的是线速度m/s和角速度rad/s你需要把它们转成 STM32 侧的浮点格式。常见做法是不采用 IEEE754 浮点直接传输而是先乘以 1000 转成 int16。原因有两点一是数据长度固定为 2 字节便于协议设计二是避开大小端问题——传输时统一高字节在前MCU 端组合即可。void twist_callback(const geometry_msgs::Twist::ConstPtr msg) { uint8_t frame[10]; frame[0] 0xAA; // 帧头 frame[1] 0x04; // 数据区长度 4 frame[2] 0x11; // 指令运动控制 int16_t v (int16_t)(msg-linear.x * 1000); int16_t w (int16_t)(msg-angular.z * 1000); frame[3] (v 8) 0xFF; frame[4] v 0xFF; frame[5] (w 8) 0xFF; frame[6] w 0xFF; frame[7] frame[0] ^ frame[1] ^ frame[2] // 省略后续字节 ^ frame[3] ^ frame[4] ^ frame[5] ^ frame[6]; ser.write(frame, 8); }注意这里的1000倍率。如果你后续要跑 SLAM 导航线速度精度到 1mm/s角速度精度到 0.001rad/s完全够用。如果 STM32 端用的是short类型倍率选 1000 不会溢出±32.7m/s而选 10000 在极限速度时会超过 int16 范围是一个隐蔽 bug。4.3 从 MCU 帧计算里程计并发布 TF里程计的计算公式不复杂难点在于发布时序必须先发布 TFodom到base_link再发布nav_msgs/Odometry消息。因为 move_base 和 AMCL 都会同时监听 TF 和 odom如果 TF 没到定位节点会直接报错。// 假设收到左右轮速度 v_l, v_r单位 m/sdt 是距上帧时间 double v (v_left v_right) / 2.0; double w (v_right - v_left) / wheel_base_; double dth w * dt; x_ v * cos(th_) * dt; y_ v * sin(th_) * dt; th_ dth; tf::Quaternion q; q.setRPY(0, 0, th_); // 先广播 TF transformStamped.transform.translation.x x_; transformStamped.transform.translation.y y_; transformStamped.transform.rotation.x q.x(); // ... 发布 transform // 再发布 Odometry odom.pose.pose.position.x x_; odom.pose.pose.position.y y_; odom.pose.pose.orientation.x q.x(); // ... 填充协方差并发布这里的wheel_base_必须与 STM32 端用到的轮距严格一致否则会出现“速度控制正确但轨迹画不出来”的怪现象。更隐蔽的问题是ROS 端的th_是 float 累加长时间运行后漂移是必然的。工程上每 5 分钟可以接受如果漂移明显那是轮距或编码器换算系数的问题不要用陀螺仪硬掰。5. 联调流程与常见问题排查从 USB-TTL 到整机运行5.1 用分步接法定位故障层不要直接开 move_base拿到任何小车代码包第一件事不是编译后直接上电跑导航。我习惯做三步隔离每一层通过后再往下走。第一步USB-TTL 接 PC不开 ROS。在 PC 上用串口助手手动发帧头AA 04 11 00 64 00 00看 STM32 是否回传数据电机是否转动。这步验证的是 USB-TTL 模块、STM32 解析逻辑和电机驱动。第二步用 Python 或serial命令行工具替换串口助手做同样的发送。这步验证的是 PC 上串口权限与路径是否正确。第三步再启动 ROS 节点用rostopic pub发cmd_vel。如果你跳过步骤一二直接做第三步出问题时你会同时面临“是板子问题、协议问题、还是 ROS 节点问题”三个变量。我在实际项目中见过大量案例最后定位到是 USB-TTL 模块的 TX/RX 接反了。这是串口通信里最高频的错误排查方法极简单——互相对调 TX 和 RX 再试一次即可。5.2 串口权限与硬件识别在 Ubuntu 上跑 ROS串口权限是一个几乎必踩的坑。接入 USB-TTL 后设备名通常是/dev/ttyUSB0。直接运行节点会报Permission denied原因是当前用户不在dialout用户组中。解决方法sudo usermod -a -G dialout $USER执行后必须重新登录才能生效或者重启。用ls -l /dev/ttyUSB0可以确认当前权限。另一个常见问题是插了两块 USB-TTL 时设备号漂移解决方案是使用 udev 规则绑定设备的idVendor和idProduct或者直接用/dev/serial/by-id/下的符号链接来替代写死的/dev/ttyUSB0。5.3 数据乱码和丢帧波形、波特率、接地三件事串口通信乱码有三大诱因。第一波特率不匹配——这是最白痴也最常见的错误常发生在你改过 STM32 端配置但 ROS 端 yaml 里的参数没同步改。第二共地问题——USB-TTL 的 GND 必须和 STM32 的 GND 接在一起否则两边电平参考不一致接收端采到的信号全是噪声。第三干扰导致丢帧——电机转动瞬间电流波动会耦合到串口线上如果你发现小车一动通信就断优先检查电源是否隔离或串口线是否与电机电源线绑扎在一起。遇到数据偶尔乱码时先用示波器或逻辑分析仪看 TX 引脚波形。正常 115200 波特率下一个位宽约 8.68μs如果波形里有毛刺或上升沿不干净优先在串口线上串一个 100Ω 电阻并确保走线尽量短。如果是 STM32F1 的 USART 配置问题检查是否误开了USART_IT_ORE中断——溢出错误在中断里没处理时会导致后续所有数据错位。# 在终端观察原始字节确认数据是否到达 sudo tio /dev/ttyUSB0 -b 115200 # 或使用 Python 快速抓取 python3 -c import serial; sserial.Serial(/dev/ttyUSB0,115200); print(s.read(32))5.4 上位机和下位机的启动顺序如果遇到“ROS 节点启动后串口没反应”的情况多数是下位机先于上位机启动而上位机在打开串口时对下位机发了一个复位信号DTR 引脚电平变化。STM32F103C8T6 的 BOOT0 和 NRST 如果受到 DTR 影响会导致芯片意外复位或进入 Bootloader 模式。规避的方式有两种一是硬件上把 USB-TTL 模块的 DTR/RTS 跳线帽拔掉或断开二是在软件上让 STM32 收到一个空串口数据时才进行初始化握手而不是上电就进入运行态。这类问题隐蔽但如果遇到了你可以这样验证先启动 ROS 节点再给 STM32 上电如果此时一切正常那就是启动顺序 DTR 共同导致的问题。6. 最后值得带走的三个调试技巧在线改 PID、串口看波形、任务收尾6.1 在线 PID 调参用上位机指令免重新烧录第一个技巧是把 PID 参数做成可在线修改的。在协议中预留0x21指令字数据区包含 Kp、Ki、Kd 三个浮点值各乘以 1000STM32 收到后更新到全局变量中。这样你在跑车时只需要在 PC 端发一组数据就能现场观察响应变化不用每次改代码重新编译烧录。烧录一次 STM32 至少耗时 5 秒加上重启和重新初始化累计起来会严重影响调试节奏——在线调参能把单次实验周期压缩到 3 秒以内。更关键的是你可以在小车运动过程中连续微调这在传统烧录模式下根本做不到。6.2 串口示波器让调试信息可见化第二个技巧与 ROS 可视化无关而是直接用串口打印曲线。我一般会在 STM32 端每 20ms 打印一串格式化数据形如v_left, v_right, pid_out用 kst 或 Arduino 串口绘图器连接在同一端口上。它比 ROS 的rqt_plot更轻因为不经过任何中间节点延迟看到的是 MCU 侧的第一手数据。如果这里曲线平滑但 ROS 端收到的 /odom 有跳变问题就在解析代码或数据回传协议上如果这里就有毛刺优先检查编码器接线。调试结束时记得把这些调试打印关闭——不是删掉而是用宏或条件编译包起来因为大量串口打印会占用带宽导致控制指令帧被延迟处理表现为“遥控时有明显迟滞”。例如实测下来 115200 波特率留出 20% 带宽给调试打印不会影响控制但超过 50% 时就开始出现帧间间隔抖动。6.3 里程计校准的标准动作跑直线和原地旋转最后一个技巧是关于里程计的验收。在投入 SLAM 之前一定要做两个标准的校准动作让小车沿直线走 2 米检查 /odom 里的位移是不是 1.9~2.1 米之间再原地旋转 360°检查角度是不是 355°~365°。这两个数据不达标建图一定飘而且你无法判断是激光雷达问题还是里程计问题——因为两者在 AMCL 里相互耦合。直线偏差大时调整左右轮换算系数通常是左右电机减速比有细微差异旋转偏差大时调整wheel_base_而且一次调整后必须重新做直线校准。把这个套路称为“先 L 后 R”养成习惯后这套 ROS STM32 的串口链路才算是真正能交付的状态。本文还有配套的精品资源点击获取