建议使用本模板发帖，也可以自由编辑，但必须完整描述产品及问题（至少包含：产品名称、版本、问题描述）。
产品型号 / 套件：阿克曼小车整套开发套餐
版本 / 规格：
控制板 / 主板：stm32
操作系统 / 软件 / 固件版本：
参考的教程或步骤：就你们发的stm32软件教程
问题描述：
报错信息 / 日志 / 截图：
复现步骤：
一步一步做的 但就是烧录不进去是为什么？
请先按阿克曼底盘 STM32 教程核对以下设置：
- 使用 Type-C 线连接 STM32 主控板的
type-c口(UART1)与电脑 USB 口。 - 打开 FlyMcu，点击“搜索串口”，选择控制板实际对应的 COM 口，波特率设为
115200。 - 点击
STMISP，在底部选择“DTR低电平复位，RTS高电平进BootLoader”。 - 选择编译生成的
.hex文件，再点击“开始编程”。
如果仍然失败，请检查是否误选了 COM1 或其他设备的串口，并关闭串口助手等可能占用该 COM 口的软件。若提示 COM_CMD_TIMEOUT，重新核对串口、波特率和上述 BootLoader 设置后，可再次点击“开始编程”。
仍无法烧录时，请把 FlyMcu 右侧窗口中的完整错误日志以文字形式贴出，并补充主控板 Type-C 接口连接和完整 FlyMcu 设置界面的截图，便于继续判断。
若您觉得本回复有帮助，可以点击下方按钮将其标记为解决方案。
还是不行 依旧是这样
您这条回复没有附上新的截图或 FlyMcu 日志，因此目前看不到“依旧是这样”具体是哪条错误。请继续检查：
- 将
.hex文件复制到全英文路径，确保文件夹名称不含中文，然后重新选择该文件。 - 确认 Type-C 线支持数据传输；建议直接更换一根数据线，并仍连接主控板的
UART1。 - 保持波特率为
115200，底部选择“DTR低电平复位，RTS高电平进BootLoader”，关闭可能占用串口的软件后，可再尝试几次“开始编程”。 - 如果 USB 串口方式始终失败，教程也支持使用
st-link或j-link进行烧录。
请把 FlyMcu 右侧窗口中从开始编程到失败的完整日志以文字形式贴出，并上传能看清所选 COM 口、波特率、STMISP 底部选项和 .hex 文件路径的完整截图，以便进一步判断。
若您觉得本回复有帮助，可以点击下方按钮将其标记为解决方案。
我们已请官方支持人员协助您排查写保护问题。如果仍需要助手帮助，请在这里回复并@我。 @hiwonder_wanchenccc
好的
好的，有需要时请继续在这里回复并@我。
按下面处理：
- 断开小车电池，只保留下载器供电；同时拔掉可能占用主控串口的蓝牙、ROS/树莓派串口线等外设。
- 重新进入 BootLoader 模式，再用 FlyMCU 选择正确串口与
115200。 - 点击左侧的 “清除芯片(Z)”，等待出现"去除读保护，并擦除成功"。
这一步会擦除 STM32 的全部 Flash，原程序无法保留。 - 成功后直接点 “开始编程(P)” 写入
.hex；不要勾选"编程到FLASH时写选项字节"。 - 写完后恢复正常启动方式，复位小车。
若仍然卡在"开始擦写保护"，建议不要继续用串口 BootLoader 清保护，改用 ST-Link + STM32CubeProgrammer：
- 用 SWD 接线：
SWDIO、SWCLK、GND、3.3V、NRST。 - 在 CubeProgrammer 选择
ST-LINK，勾选 Connect under reset 后连接。 - 在
Option Bytes中将RDP设为Level 0 (0xAA)并应用，或执行Full chip erase。 - 重新下载程序。
去除写保护成功后，先不要继续反复修改 Option Bytes。-4 STM_WriteMemory 说明当前仍在实际写入阶段失败，请按以下顺序核对：
- 查看 STM32/RRC 开发板背面的丝印版本，必须选择该版本对应源码编译生成的
.hex，不要混用其他主板版本的固件。 - 将
.hex放到全英文路径中，文件夹名称不要包含中文。 - 使用支持数据传输的 Type-C 线连接主控板的
type-c口(UART1)，必要时更换数据线。 - 在 FlyMcu 中重新“搜索串口”，选择主控板实际对应的 COM 口，波特率设置为
115200。 - 点击
STMISP，底部选择“DTR低电平复位，RTS高电平进BootLoader”，重新选择.hex后再尝试几次“开始编程”。
如果仍然固定报 -4 STM_WriteMemory，请停止反复清除保护，可改用 st-link 或 j-link 直接烧录。同时请贴出从“开始编程”到报错为止的完整 FlyMcu 文字日志、开发板背面丝印版本，以及能看清 COM 口、波特率、BootLoader 选项和文件路径的完整截图，以便进一步定位。
若您觉得本回复有帮助，可以点击下方按钮将其标记为解决方案。
解决方案 首选换软件进行烧录 选择ATK XISP进行烧录 不要选择FlyMCU 另外 我的单片机型号是
STM32F407VET6 店家给我两份资料 一个是《小型阿克曼底盘》还有一个是《STM32机器人控制器》第二个程序是可以烧录的 第一个不行。还有就是这个文件1的有一份安装电机的视频 是右车轮插入M1 左车轮接入M2 这个步骤是对的 下面还有一个pdf是告诉我们反着接是错的 希望官方后续统一一下。另外最开始按照舵机源码J1开始调试 没反应 最后调到第四个通道才有用。
感谢您补充完整的验证结果：STM32F407VET6 使用 ATK XISP 可以正常烧录，《STM32机器人控制器》程序可用，而《小型阿克曼底盘》程序无法烧录，资料中的 M1/M2 接线说明也存在冲突，舵机从 J1 调试无反应、第四通道才可用。我们会整理并反馈这些资料问题，供官方后续核对并统一修正。
确实有用，多谢
以下内容为GPT总结 路线以经过我本人认证
STM32小型阿克曼底盘------控制板整机联调补充记录
一、串口控制链路问题
最初使用UART1对应的COM7进行控制测试。
UART1/COM7的主要用途：
- STM32 BootLoader烧录
- 烧录波特率115200
- 下载HEX固件
当时虽然串口助手能够收到二进制数据，但发送电机、蜂鸣器和LED控制帧后，硬件没有反应。
后续确认运行控制接口为：
- 接口：UART2
- 测试串口：COM8
- 波特率：1,000,000 baud
- 数据位：8
- 校验位：None
- 停止位：1
- 流控：None
切换到UART2/COM8后，蜂鸣器、LED、电机和PWM舵机控制命令才能正常执行。
结论：
UART1和UART2用途不同。
UART1/COM7：
主要用于115200波特率的BootLoader烧录。
UART2/COM8：
用于1,000,000波特率的运行时二进制控制协议。
COM7、COM8只是当时Windows分配的端口号，重新插拔后可能变化，不能永久写死。
二、蜂鸣器调试记录
初始现象：
烧录完成后，打开控制板开关或者按RESET键，蜂鸣器没有响。
最初的错误判断：
曾怀疑程序没有运行、蜂鸣器没有供电或固件烧录失败。
后续验证：
在正确的UART2/COM8上发送蜂鸣器控制命令后，用户明确听到了蜂鸣声。
协议功能号：
PACKET_FUNC_BUZZER = 0x02
控制参数包括：
- 发声频率
- 单次发声时间
- 间隔时间
- 重复次数
结论：
板载蜂鸣器及其软件控制链路工作正常。
注意：
是否在开机或RESET后发声完全由当前固件决定。没有开机蜂鸣声不能证明程序没有运行。
RESET只会让STM32重新启动，不会清除Flash中的程序。
三、LED灯调试记录
控制板上存在两类LED：
-
电源指示灯
通电后保持常亮，主要用于表示电源状态，一般不能通过运行协议控制。 -
系统可编程LED
源码名称为LED_SYS，可以通过串口协议设置亮起时间、熄灭时间和重复次数。
协议功能号：
PACKET_FUNC_LED = 0x01
当前源码只注册了一个可编程LED：
LED ID = 1
最初现象：
发送测试命令后，用户看到的两个红色LED没有变化，因此曾怀疑LED命令没有执行。
原因：
当时观察到的常亮红灯主要是电源指示灯，不应把它们当作可编程LED；同时初期还使用了错误的UART接口。
后续测试：
切换到UART2/COM8后，已经发送并执行过系统LED间歇闪烁控制。
结论：
系统LED控制功能可用，但必须区分"电源指示灯"和"LED_SYS可编程灯"。
不能通过常亮电源灯是否闪烁来判断程序控制是否成功。
四、后轮电机调试记录
协议功能号：
PACKET_FUNC_MOTOR = 0x03
电机命令中的速度单位：
r/s，即每秒转数，不是PWM百分比，也不是m/s。
当前实车接线映射经过实际转动确认：
协议motor_id 0：
物理接口M1
右后轮
协议motor_id 1：
物理接口M2
左后轮
车辆前进时的符号约定：
M1右后轮：正转速
M2左后轮：负转速
例如直行前进目标：
M1 = +0.3 r/s
M2 = -0.3 r/s
两个电机使用相反的数值符号，是因为左右电机在底盘上采用镜像安装。符号相反不代表车辆原地旋转。
五、已完成的电机测试
- 单独转动后轮测试
结果：
M1和M2均能够转动。
确认：
M1接右后轮，M2接左后轮。
- 低速方向测试
使用相同转速绝对值、相反符号控制两只后轮。
结果：
确认车辆前进方向应使用：
M1为正
M2为负
- 加速测试
执行过以下目标转速变化：
0.2 r/s
0.4 r/s
0.6 r/s
0.8 r/s
1.0 r/s
随后逐步减速到0
结果：
两只后轮能够随目标值增加而加速，测试结束后成功停止。
- 0.3 m/s换算测试
小型阿克曼源码中的轮径：
60 mm
理论换算：
轮速 = 线速度 / 车轮周长
0.3 m/s对应：
0.3 / (π × 0.06)
≈ 1.59 r/s
执行过约1.59 r/s的短时间测试，结束后成功停止。
- 五分钟连续运行测试
源码中JGB520电机配置的目标转速上限约为：
1.5 r/s
为避免长时间超过源码设定上限，五分钟测试采用：
1.5 r/s
60 mm轮径下对应的理论线速度：
1.5 × π × 0.06
≈ 0.283 m/s
测试内容：
- 后轮持续运行约300秒
- M1保持正转速
- M2保持负转速
- 前轮舵机同时周期转向
- 每隔约1秒重新发送后轮目标转速
- 测试结束后逐步减速
- 最终向两个电机发送0 r/s
- 舵机返回1400 μs中位
执行结果：
- 总执行时间约307秒
- 脚本未报告串口错误
- 两只后轮最终停止
- 舵机最终返回1400 μs
- COM8最终关闭
注意：
该测试只能证明控制命令能够持续执行，不能代替电机温升、电流和真实车速测量。
六、编码器与PID说明
电机控制不是直接发送固定PWM。
控制流程为：
目标转速r/s
↓
STM32内部PID控制器
↓
根据编码器测速误差计算PWM
↓
板载H桥驱动电机
↓
电机转动
编码器用于STM32内部闭环调速。
但是，当前出厂固件的标准UART2控制协议没有提供可直接使用的后轮编码器计数或实际转速查询命令。
因此目前能够确认的是：
- 电机能够接受目标转速命令
- 两个电机驱动通道能够工作
- 电机能够加速、持续运行和停止
目前不能仅通过UART2确认：
- 实际编码器脉冲数
- 实际后轮转速
- 实际线速度是否精确达到目标值
- 左右轮实际速度误差
- PID跟踪误差
如果需要读取真实编码器数据，需要修改STM32源码，增加编码器计数或实际r/s的串口上报功能，然后重新编译和烧录固件。
七、电机、蜂鸣器和LED测试结论
蜂鸣器：
已通过UART2命令实际发声，功能正常。
系统LED：
已进行串口控制和间歇闪烁测试。必须与常亮电源指示灯区分。
M1电机：
能够运行，当前连接右后轮。
M2电机：
能够运行，当前连接左后轮。
前进方向：
M1使用正转速，M2使用负转速。
持续运行：
已完成约五分钟连续测试，并在结束后自动停止。
编码器：
参与板内PID控制，但尚未通过串口独立读取和验证。
整体结论：
控制板的UART2运行协议、蜂鸣器、系统LED、两个后轮电机输出和PWM舵机控制均已进行实际联调。
STM32小型阿克曼底盘------PWM转向舵机调试问题记录
日期：2026-08-04
一、测试环境
控制板：Ros Robot Controller，STM32F407
运行固件：RosRobotControllerM4.hex（出厂固件）
运行通信接口：UART2
测试串口：COM8（COM号重新插拔后可能变化）
串口参数：1,000,000 baud，8N1，无流控
转向舵机物理接口：PCB丝印J1
当前固件中的协议舵机ID：4
目测校准的前轮直行中位：约1400 μs
二、问题一：发送舵机命令后，前轮没有动作
现象：
最初按照小型阿克曼源码发送逻辑舵机ID 1的控制命令。STM32能够接收命令，也能返回一个脉宽数值，但前轮没有产生任何机械动作。
排查过程：
- 确认出厂程序运行时前轮能够转向。
- 因此舵机本体、接线和当时的供电基本可用。
- 依次测试协议舵机ID 1、2、3、4。
- 最终确认只有协议舵机ID 4能够控制前轮转向。
结论：
当前烧录的出厂固件中，前轮转向舵机的协议ID是4。
注意：
PCB上的"J1"只是接口的电路板编号，不代表协议中的"舵机ID 1"。
资料中的小型阿克曼源码使用：
pwm_servos[0]
这通常表示逻辑通道1，但它与当前出厂固件和实际控制板的映射不一致。可能原因包括固件版本不同、资料版本不同或控制板内部通道映射不同。
因此：
当前出厂固件使用舵机ID 4。
如果以后重新编译并烧录其他源码，舵机ID可能发生变化，需要重新测试，不能永久假定为4。
三、问题二：误把STM32返回值理解为舵机真实角度
现象：
向错误的舵机通道发送命令后，STM32仍然能够返回一个"舵机位置"数值，看起来像是舵机已经响应。
实际原因：
普通三线PWM舵机只有：
- 电源
- GND
- PWM控制信号
它没有角度反馈信号。
STM32返回的是软件内部保存的目标脉宽/current_duty，并不是舵机轴或前轮的真实角度。
因此，即使出现以下情况：
- 舵机接错通道
- 舵机没有供电
- 舵机堵转
- 舵机连杆卡住
- 舵机没有实际运动
STM32仍可能返回已经保存的目标脉宽。
结论：
控制板返回目标脉宽，只能证明命令被软件处理，不能证明舵机真实到达目标角度。
四、问题三：源码默认中位与车辆实际中位不一致
源码默认设置：
1500 μs = 转向中位
实际测试结果：
1500 μs：前轮轻微偏右
1450 μs：仍存在轻微偏差
1400 μs：目测基本回正
结论：
当前车辆的实际直行中位约为1400 μs，而不是源码默认的1500 μs。
可能原因：
- 舵机摇臂安装角度存在偏差
- 转向连杆长度存在偏差
- 舵机本身的电气中位存在偏差
- 前轮机械定位存在偏差
这属于机械中位偏移，不代表舵机损坏。
注意：
1400 μs是目前通过目测得到的近似值。最终应通过车辆落地直线行驶测试进一步校准。
五、问题四：5分钟测试中的左右转向幅度不对称
5分钟测试时使用的舵机脉宽：
1350 μs和1650 μs，每10秒切换一次。
该组数值以源码默认中位1500 μs为中心：
1350 = 1500 - 150
1650 = 1500 + 150
如果实际中位确实是1500 μs，则这是一组对称命令。
但是，本车已经校准出实际中位约为1400 μs。因此相对于本车实际中位：
1350 μs = 1400 - 50 μs
1650 μs = 1400 + 250 μs
左右偏移量分别为50 μs和250 μs，明显不对称。
结论：
刚才舵机没有发生通信故障或程序报错；问题出在测试脉宽仍然围绕1500 μs设置，没有围绕已经校准的1400 μs设置。
这是测试参数设置问题，不是舵机硬件故障。
六、小型阿克曼源码中的转向模型
源码参数：
后轮直径：60 mm
轴距参数：170 mm
轮距参数：180 mm
软件转向角限制：约±40°
转弯半径与目标转角的关系：
θ = atan(170 / r)
其中：
θ：软件使用的目标转向角
r：目标转弯半径，单位mm
反向计算：
r = 170 / tan(|θ|)
源码中的角度与PWM脉宽换算：
pulse = 1500 - (2000 / π) × θ
换算成角度后，大约为：
100 μs ≈ 9°
150 μs ≈ 13.5°
按源码默认中位1500 μs计算：
1350 μs ≈ +13.5°
1650 μs ≈ -13.5°
对应模型转弯半径约708 mm。
但是本车实际中位约为1400 μs，因此若保持相同换算斜率，应加入约-100 μs的中位修正：
pulse_corrected = 1400 - (2000 / π) × θ
按照该修正：
理论±13.5°对应约1250 μs和1550 μs。
注意：
以上角度和半径是源码中的几何模型值。舵机摇臂、转向连杆和车轮结构会影响实际前轮角度，因此不能仅凭PWM脉宽认定真实转向角。
七、后续建议使用的测试参数
当前协议舵机ID：
4
当前近似中位：
1400 μs
首次对称小幅测试建议：
1300 μs ↔ 1500 μs
相对于1400 μs：
两侧各偏移100 μs
源码理论角度约±9°
模型转弯半径约1.07 m
需要更大幅度时再逐步增加，不要直接使用未经验证的极限脉宽。
每次测试结束：
- 后轮目标速度设为0。
- 舵机返回1400 μs。
- 关闭串口。
- 检查舵机是否发热、抖动、堵转或碰到机械限位。
八、最终结论
本次舵机调试发现的核心问题不是舵机损坏，而是：
- PCB接口编号J1与协议舵机ID不是同一概念。
- 当前出厂固件实际使用协议舵机ID 4，而不是源码中推测的ID 1。
- STM32返回的是软件目标脉宽，不是舵机真实角度反馈。
- 源码默认中位1500 μs与本车实际中位约1400 μs不一致。
- 5分钟测试仍使用1350/1650 μs，导致相对于1400 μs的左右转向幅度不对称。
- 实际转向角和转弯半径需要结合机械结构与落地行驶结果进一步标定。