企业官网建设流程全解析

用状态机重构STM32F4循迹小车：告别硬编码的工程化实践

在嵌入式开发中，处理多传感器输入和控制逻辑时，新手常陷入if-else或switch-case的硬编码陷阱。我曾见过一个典型的五路循迹小车项目，原始代码用超过20个条件判断处理传感器组合——这种写法不仅难以维护，遇到十字路口等复杂场景时更会暴露致命缺陷。本文将展示如何用**有限状态机(FSM)**重构这类控制逻辑，基于STM32 HAL库提供可复用的框架，让你的代码具备应对赛道变化的弹性。

1. 为什么状态机是循迹小车的救星

1.1 硬编码方案的三大痛点

原始代码中常见的Track_Adjust()函数通常存在这些问题：

// 典型硬编码示例（问题代码） if(sensor[0]==1 && sensor[1]==0 && sensor[2]==0 && sensor[3]==1){ turnLeft(30); // 魔法数字30没有明确含义 } else if(sensor[0]==1 && sensor[1]==1 && sensor[2]==0 && sensor[3]==0){ turnLeft(50); // 另一个魔法数字 } // 后续还有十几个类似条件...

致命缺陷对照表：

1.2 状态机的降维打击优势

有限状态机通过三个核心要素重构控制逻辑：

1. 状态(State)：如STRAIGHT、TURN_LEFT_20等具名操作阶段
2. 事件(Event)：传感器输入组合触发状态转移
3. 动作(Action)：进入/退出状态时执行的操作（如电机调速）

stateDiagram-v2 [*] --> STRAIGHT: 初始状态 STRAIGHT --> TURN_LEFT_20: 传感器=11000 TURN_LEFT_20 --> STRAIGHT: 传感器=11110 STRAIGHT --> CROSSROAD: 传感器=11111

注意：虽然mermaid图能直观展示状态转移，但在实际工程中建议用表格定义状态机，后文将给出具体实现方案

2. HAL库下的状态机工程实现

2.1 状态定义与类型设计

首先在track_fsm.h中建立状态机框架：

typedef enum { STATE_LOST, // 00000 STATE_STRAIGHT, // 11111 STATE_TURN_LEFT_10, // 11100 STATE_TURN_LEFT_30, // 11000 STATE_TURN_RIGHT_10, // 00111 STATE_CROSSROAD, // 特殊场景 STATE_COUNT // 状态总数 } FSM_State; typedef struct { FSM_State current; void (*entry_action)(void); // 进入状态时执行 void (*exit_action)(void); // 退出状态时执行 } FSM_Context;

2.2 状态转移表实现

用查表法替代条件分支，在track_fsm.c中定义：

// 传感器模式到状态的映射 static const uint16_t sensor_state_map[] = { [0b00000] = STATE_LOST, [0b11111] = STATE_STRAIGHT, [0b11100] = STATE_TURN_LEFT_10, [0b11000] = STATE_TURN_LEFT_30, // 其他模式映射... }; // 状态行为配置 static FSM_StateConfig state_configs[STATE_COUNT] = { [STATE_STRAIGHT] = { .entry = straight_entry, .exit = NULL // 无退出动作 }, [STATE_TURN_LEFT_10] = { .entry = turn_left_10, .exit = brake_motors // 退出时刹车防抖 }, // 其他状态配置... };

2.3 事件处理核心逻辑

状态机引擎只需不到20行关键代码：

void FSM_ProcessEvent(uint16_t sensor_pattern) { FSM_State new_state = sensor_state_map[sensor_pattern]; if(new_state != fsm_ctx.current) { // 执行退出旧状态动作 if(fsm_ctx.state_configs[fsm_ctx.current].exit) fsm_ctx.state_configs[fsm_ctx.current].exit(); // 状态转移 fsm_ctx.current = new_state; // 执行进入新状态动作 if(fsm_ctx.state_configs[new_state].entry) fsm_ctx.state_configs[new_state].entry(); } }

3. 实战：从if-else到状态机的重构对比

3.1 原始代码片段分析

以处理左转弯为例，传统方案需要多个独立判断：

// 旧方案（片段） if(LED_1==1 && LED_2==1 && LED_3==0 && LED_4==0 && LED_5==1) { runCarLittleLeft(); } else if(LED_1==1 && LED_2==1 && LED_3==1 && LED_4==0 && LED_5==1) { runCarLittleLeft(); } else if(LED_1==1 && LED_2==1 && LED_3==1 && LED_4==0 && LED_5==0) { runCarLeft(); // 更大幅度转向 }

3.2 状态机方案改进

1. 抽象状态：将runCarLittleLeft()和runCarLeft()合并为STATE_TURN_LEFT，通过参数区分程度
2. 统一处理：传感器模式到状态的映射集中在表格中
3. 行为解耦：转向具体实现放在状态入口函数

// 新方案状态入口函数示例 static void turn_left_entry(uint8_t degree) { // 根据转向程度计算电机PWM差值 int16_t diff = degree * SPEED_FACTOR; set_motor_speed(BASE_SPEED + diff, BASE_SPEED - diff); } // 状态转移表中配置 [0b11100] = { .state = STATE_TURN_LEFT, .param = 10 }, [0b11000] = { .state = STATE_TURN_LEFT, .param = 30 }

4. 应对复杂场景的扩展技巧

4.1 十字路口处理方案

传统硬编码遇到11111全检测模式时难以区分直线和十字路口，状态机可通过超时机制增强鲁棒性：

// 在状态机上下文中添加计时器 typedef struct { FSM_State current; uint32_t enter_time; // 进入当前状态的时刻 // ...其他字段 } FSM_Context; // 十字路口判断逻辑 if(current_state == STATE_STRAIGHT && HAL_GetTick() - ctx.enter_time > CROSSROAD_TIMEOUT) { transition_to(STATE_CROSSROAD); }

4.2 状态持久化调试技巧

添加状态历史记录便于问题追踪：

#define HISTORY_SIZE 10 FSM_State state_history[HISTORY_SIZE]; uint8_t history_index = 0; void record_state(FSM_State state) { state_history[history_index++] = state; history_index %= HISTORY_SIZE; } // 通过串口打印历史状态 void print_state_history(void) { for(int i=0; i<HISTORY_SIZE; i++) { printf("[%d] %s\n", i, state_names[state_history[i]]); } }

5. 性能优化与进阶设计

5.1 内存与速度权衡

对于资源紧张的STM32F4，可采用以下优化策略：

方案对比表：

5.2 分层状态机设计

当处理坡道、障碍等复合场景时，可采用层次化状态机：

// 顶层状态 typedef enum { MODE_NORMAL, MODE_SLOPE, MODE_OBSTACLE } TopLevelState; // 每个顶层状态包含子状态机 struct { TopLevelState mode; union { FSM_Context normal_fsm; SlopeFSM slope_fsm; // 其他状态机 }; } SystemState;

在电机控制中断中根据当前模式选择处理逻辑：

void TIMx_IRQHandler(void) { switch(system_state.mode) { case MODE_NORMAL: normal_fsm_update(); break; case MODE_SLOPE: slope_fsm_update(); break; // ... } }

6. 真实项目中的经验教训

在去年全国大学生智能车竞赛中，我们最初采用硬编码方案，直到测试时才发现这些问题：

1. 参数调整噩梦：修改一个转弯参数需要检查5处相关代码
2. 赛道适应性差：主办方临时增加S弯道时被迫重构全部逻辑
3. 调试效率低下：无法直观看到当前决策路径

改用状态机后，最明显的改善是：

• 新增特殊赛道元素只需添加状态定义
• 所有速度参数集中在单个头文件配置
• 通过状态历史记录快速定位异常

// 实际比赛中的状态机扩展示例 [0b10101] = { .state = STATE_ZIGZAG, .handler = handle_zigzag }, [0b10001] = { .state = STATE_UTURN, .handler = handle_uturn }

关键提示：在状态机中预留STATE_ERROR和STATE_RECOVERY等容错状态，可显著提升系统鲁棒性