别再只用if-else了！用状态机优化你的STM32循迹小车代码，让逻辑更清晰

用状态机重构STM32循迹小车：告别if-else的工程化实践

当你的循迹小车第一次成功沿着黑线跑起来时，那种成就感无与伦比。但随着功能不断增加——十字路口识别、起跑线检测、障碍物避让——你会发现原本清晰的if-else结构正在变成一团乱麻。每次修改都可能引入新bug，添加新功能变得战战兢兢。这就是我们需要状态机的时刻。

在嵌入式开发中，有限状态机(FSM)就像一位经验丰富的交通警察，它能将复杂的逻辑行为分解为明确的"状态"和"转移条件"。对于使用STM32的开发者来说，掌握状态机意味着代码可维护性的质的飞跃。让我们从工程实践角度，看看如何用状态机重构循迹小车代码。

1. 为什么if-else不是最佳选择

那个经典的while(1)循环里嵌套if-else的结构，是每个STM32开发者都写过的代码。它简单直接，但当逻辑复杂度上升时，问题接踵而至：

while (1) { if (左传感器触发 && 右传感器触发) 停车(); else if (左传感器触发) 左转(); else if (右传感器触发) 右转(); else 直行(); }

这种结构的致命缺陷在于：

• 可读性差：当条件判断超过5个时，代码变成"面条式"逻辑
• 难以扩展：新增一个"十字路口"判断需要修改所有条件分支
• 状态混乱：没有明确的状态划分，各种标志位相互影响
• 调试困难：当小车行为异常时，很难定位是哪个条件分支出了问题

我曾接手过一个学生项目，他们的循迹小车代码里有17层if-else嵌套。当小车在比赛中突然原地转圈时，没人能说清到底执行了哪段逻辑。

2. 有限状态机的基本原理

有限状态机由三个核心要素构成：

1. 状态(State)：系统在特定时刻所处的模式
2. 事件(Event)：触发状态转移的输入信号
3. 动作(Action)：状态转移时执行的操作

对于循迹小车，典型的状态可能包括：

状态转移表则明确了各种条件下状态的切换规则：

3. STM32上的状态机实现

在STM32 HAL库环境下，我们可以用枚举定义状态，用结构体封装状态机：

typedef enum { STATE_FOLLOW_LINE, STATE_TURN_LEFT, STATE_TURN_RIGHT, STATE_STOP, STATE_CROSSROAD } TrackerState; typedef struct { TrackerState current_state; void (*state_handler)(void); } StateMachine; StateMachine tracker_fsm = { .current_state = STATE_STOP, .state_handler = NULL };

状态处理函数采用函数指针数组实现，避免switch-case结构：

void FollowLine_Handler(void) { // 直线行驶逻辑 __HAL_TIM_SetCompare(&htim2, TIM_CHANNEL_1, 20); __HAL_TIM_SetCompare(&htim2, TIM_CHANNEL_2, 20); if (LEFT_SENSOR_TRIGGERED && RIGHT_SENSOR_TRIGGERED) { tracker_fsm.current_state = STATE_STOP; } else if (LEFT_SENSOR_TRIGGERED) { tracker_fsm.current_state = STATE_TURN_LEFT; } else if (RIGHT_SENSOR_TRIGGERED) { tracker_fsm.current_state = STATE_TURN_RIGHT; } } void (*state_handlers[])(void) = { FollowLine_Handler, TurnLeft_Handler, TurnRight_Handler, Stop_Handler, Crossroad_Handler };

主循环简化为状态机的执行和更新：

while (1) { tracker_fsm.state_handler = state_handlers[tracker_fsm.current_state]; tracker_fsm.state_handler(); HAL_Delay(10); // 适当延时防止状态检测过于频繁 }

4. 高级应用：处理复杂场景

当小车需要应对十字路口、起跑线等复杂场景时，状态机的优势更加明显。我们可以引入"子状态"概念：

typedef enum { SUBSTATE_APPROACHING, SUBSTATE_CENTERING, SUBSTATE_PASSING } CrossroadSubstate; typedef struct { TrackerState main_state; CrossroadSubstate crossroad_substate; uint32_t crossroad_timer; } AdvancedStateMachine;

对于十字路口的处理可以这样实现：

void Crossroad_Handler(void) { switch (adv_fsm.crossroad_substate) { case SUBSTATE_APPROACHING: // 减速接近十字路口中心 if (检测到中心点) { adv_fsm.crossroad_substate = SUBSTATE_CENTERING; adv_fsm.crossroad_timer = HAL_GetTick(); } break; case SUBSTATE_CENTERING: // 在中心点短暂停留 if (HAL_GetTick() - adv_fsm.crossroad_timer > 500) { adv_fsm.crossroad_substate = SUBSTATE_PASSING; Set_Target_Direction(选择预设方向); } break; case SUBSTATE_PASSING: // 按照选择的方向通过路口 if (离开十字路口条件) { adv_fsm.main_state = STATE_FOLLOW_LINE; } break; } }

5. 调试与优化技巧

状态机的一个额外好处是调试更方便。我们可以添加状态日志：

const char* state_names[] = { "FOLLOW_LINE", "TURN_LEFT", "TURN_RIGHT", "STOP", "CROSSROAD" }; void Log_State_Change(TrackerState old_state, TrackerState new_state) { printf("[FSM] %s -> %s\n", state_names[old_state], state_names[new_state]); // 或者通过串口发送到上位机 }

在状态转换时调用日志函数：

void Change_State(TrackerState new_state) { if (tracker_fsm.current_state != new_state) { Log_State_Change(tracker_fsm.current_state, new_state); tracker_fsm.current_state = new_state; } }

对于实时性要求高的场景，可以考虑以下优化：

• 使用查表法实现状态转移
• 将频繁调用的状态处理函数放在RAM中执行
• 对传感器输入进行去抖处理

// 快速查表法状态转移示例 static const TrackerState transition_table[NUM_STATES][NUM_EVENTS] = { [STATE_FOLLOW_LINE] = { [EVENT_LEFT_SENSOR] = STATE_TURN_LEFT, [EVENT_RIGHT_SENSOR] = STATE_TURN_RIGHT, // ... }, // 其他状态转移规则... }; TrackerState Get_Next_State(TrackerState current, Event event) { return transition_table[current][event]; }

在项目后期，当我们需要调整小车对不同路况的响应时，只需要修改对应的状态处理函数或转移表，而不用担心会意外影响其他部分的逻辑。这种模块化的设计也让团队协作更加顺畅——不同开发者可以负责不同状态模块的实现。