基于STM32智能导盲拐杖从方案设计到仿真调试完整复盘

简介：本资源是一套面向嵌入式初学者与视障辅助设备开发者的STM32智能导盲拐杖完整工程方案，聚焦于解决视障人群日常出行中的障碍识别与实时反馈问题。项目以STM32F103C8T6为核心控制器，集成超声波测距、MPU6050姿态传感、振动马达与蜂鸣器等模块，实现障碍距离检测、倾斜预警及多模态提示功能，兼具实践性与人文关怀价值。压缩包共193个文件，含30余个C/H源码文件（如stm32f10x_adc.c、stm32f10x_i2c.c）、Keil工程配置文件（uvprojx、uvoptx、hex、axf）、编译中间文件（o/d/crf）及PDF原理图、设计文档与WMV演示视频，总大小14.41MB，结构清晰，便于分模块学习与调试。已有25人下载学习，配套资料覆盖从硬件设计、传感器驱动、滤波算法到低功耗管理的全链路实现，特别包含keilkilll.bat一键清理脚本、详细注释代码及仿真验证说明，显著降低复现门槛。

基于STM32智能导盲拐杖：从方案设计到仿真调试的完整复盘

做毕业设计或者电子设计竞赛的时候，智能导盲拐杖算是出镜率非常高的一类题目。原因很直接：功能明确、传感器组合经典、软硬件工作量适中，而且“导盲助残”这个应用场景天然有社会价值，答辩的时候也容易讲出亮点。我前前后后帮人看过好几个版本的导盲拐杖方案，自己也完整搭过一套基于STM32F103C8T6的样机，今天就拿这个“程序+仿真+全套资料”的项目当例子，把整套东西从需求拆解到代码实现再到Proteus仿真排坑，一次性讲清楚。

先说结论：这套项目最核心的价值不是某个单项技术，而是它把超声波测距、人体跌倒检测、光线/水坑感知、语音提醒和紧急求助这些功能，用一颗STM32主控完整地串了起来。你拿到手的程序可以直接烧录跑实物，仿真文件可以拿来调逻辑、改参数、验收演示，全套资料里的原理图和设计文档则方便你快速改造成自己的方案。对于正在做课程设计、毕业设计的电子信息类学生，以及想入门STM32传感器融合开发的爱好者来说，是一个非常标准的练手范本。

1. 项目核心需求与整体设计思路拆解

1.1 智能导盲拐杖到底要解决什么问题

盲人出行的核心痛点不是“走路”本身，而是“无法预判环境”。普通盲杖靠敲击地面和障碍物来获取信息，探测范围有限、反馈滞后，而且对上方悬空物体（比如树枝、卡车挡板）和地面水坑基本无能为力。智能导盲拐杖的思路，就是用传感器替代“敲击”，用语音/震动替代“手感”，把探测范围从“地面接触点”扩展到“前方几米的空间”，同时补上摔倒检测和求助这两个安全兜底功能。

这套项目里，功能需求一般拆成这么四路：

• 前方障碍物检测：超声波传感器持续测距，距离小于安全阈值就语音提醒“前方有障碍物”。这是整个系统最核心的功能，也是最容易出彩、最容易翻车的部分。
• 地面水坑/光线检测：用水滴传感器或光敏电阻检测地面湿滑状况，检测到积水或光线过暗时给出不同的提示音。这个功能在答辩演示时很好用，因为效果直观。
• 跌倒检测：通过MPU6050陀螺仪加速度计判断人体姿态，检测到摔倒且短时间内没有起身，就触发蜂鸣器报警，有的方案还会加GPS/GSM模块发短信给紧急联系人。这个功能的算法阈值需要反复调，是项目的主要工作量之一。
• SOS紧急求助：独立按键触发，按下后蜂鸣器长鸣、LED闪烁，配合GSM模块（如果扩展）发送定位短信。

以上四路功能，如果你只做“程序+仿真”的交付版本，核心要跑通的是前两个，跌倒检测在纯仿真环境里不太好演示，但代码和原理图必须完整，方便后续扩展实物。

1.2 为什么选择STM32作为主控

选型这块，我见过用51单片机做导盲拐杖的，也能跑，但体验差距很大。51的算力做单路超声波测距勉强够了，一旦加上MPU6050的姿态解算、多路传感器轮询、语音播报控制，主循环就会显得捉襟见肘，而且51没有硬件I2C和足够多的定时器通道，外设管理会非常痛苦。

STM32F103C8T6这个型号，也就是大家常说的“蓝丸”核心板，在这个项目里有几个不可替代的优势：

• 主频72MHz，算力充足：跑单路超声波测距的计时、MPU6050的I2C读取、多路传感器状态机切换，绰绰有余，不用担心实时性。
• 丰富的外设接口：超声波模块用定时器输入捕获或者GPIO模拟时序都行，MPU6050走硬件I2C，蜂鸣器用PWM控制，按键用外部中断，所有外设都有对应的硬件资源，不用挤占。
• HAL库和CubeMX配合，开发效率高：用STM32CubeMX初始化时钟、GPIO、定时器、I2C、USART，几分钟就能把工程骨架搭好，剩下的精力全部集中在业务逻辑上。
• 生态成熟，资料遍地都是：无论是Proteus仿真元件库、Keil工程模板，还是各种传感器驱动代码，稍微一搜就能找到参考，对做毕设的同学来说这是最大的隐形优势。

1.3 系统总体架构与数据流向

整个系统的工作流程可以概括为“感知-决策-反馈”三个环节。传感器持续采集环境数据，STM32轮询读取并做阈值判断，然后根据判断结果驱动蜂鸣器、语音模块和指示灯。用伪代码描述主循环逻辑大概是：

while (1) { // 1. 超声波测距，获取前方障碍物距离 distance = get_ultrasonic_distance_cm(); // 2. 根据距离分级决策 if (distance < 30) { play_voice("前方障碍物，请绕行"); set_buzzer_pattern(DANGER_CONTINUOUS); } else if (distance < 70) { play_voice("前方有障碍物"); set_buzzer_pattern(DANGER_SLOW); } // 3. 检测水坑传感器 if (water_sensor_detected()) { play_voice("前方地面湿滑"); } // 4. 跌倒检测与按键扫描 if (check_fall_detected()) { trigger_sos_alarm(); } if (sos_button_pressed()) { trigger_sos_alarm(); } // 5. 更新指示灯状态 update_led_status(); delay(50); // 主循环周期 }

这个架构的好处是结构清晰、便于扩展。你想加GPS模块，就是在主循环里加一个判断分支；你想用OLED显示距离和姿态，就是加一个显示刷新函数。对于答辩和演示场景，这个架构也方便你现场“表演”：拿一本书挡在超声波传感器前面，看它会不会语音报警；给水滴传感器滴水，看它会不会提醒地面湿滑，效果非常直观。

2. 核心模块硬件设计与外设接口细节

2.1 超声波测距模块：HC-SR04的驱动要点

超声波模块是这个项目的“眼睛”，选HC-SR04基本是标准答案，便宜、稳定、容易买。它的工作原理很简单：MCU给Trig引脚一个10us以上的高电平脉冲，模块内部发射8个40kHz的超声波脉冲，然后Echo引脚输出一个高电平，高电平持续时间就是超声波从发射到反射回来的时间。

距离计算公式：

距离(cm) = Echo高电平时间(us) / 58

这个58是怎么来的？超声波在空气中的速度约340m/s，即0.034cm/us。声波走一个来回，实际距离是单程，所以距离 = 时间(us) * 0.034 / 2 = 时间(us) / 58.8。工程上取58，误差在可接受范围内。如果追求更精确，可以微调除法系数，或者用查表法做温度补偿。

驱动方式有两种，我强烈推荐第二种：

• GPIO模拟方式：用HAL_GPIO_ReadPin配合定时器计时。简单，但占用CPU，而且测距时主循环会卡住，多路传感器轮询时响应变慢。
• 定时器输入捕获方式：把Echo引脚接到定时器的输入捕获通道，上升沿触发捕获记录起点，下降沿捕获记录终点，差值就是高电平时间。完全不阻塞CPU，适合做多路传感器同时工作的场景。

我用的是定时器输入捕获，具体配置是TIM2通道1做输入捕获，TIM2的溢出中断配合记录溢出次数，确保长距离（超过定时器溢出周期）也能精确计时。代码核心片段如下：

// 触发一次超声波测距 void ultrasonic_trigger(void) { HAL_GPIO_WritePin(TRIG_GPIO_Port, TRIG_Pin, GPIO_PIN_SET); delay_us(20); HAL_GPIO_WritePin(TRIG_GPIO_Port, TRIG_Pin, GPIO_PIN_RESET); } // 输入捕获中断回调 void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim) { if (htim->Channel == HAL_TIM_ACTIVE_CHANNEL_1) { if (capture_index == 0) { // 上升沿，记录起始时间 start_time = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1); overflow_count = 0; capture_index = 1; } else if (capture_index == 1) { // 下降沿，计算时间差 end_time = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1); uint32_t total_time = end_time - start_time + overflow_count * 65535; distance_cm = total_time / 58; capture_index = 0; } } }

注意一个细节：HC-SR04测距范围是2cm到400cm，小于2cm会测不准，大于400cm会超时。在主循环里要加超时判断，如果一段时间内没收到下降沿，距离就标记为最大值，避免输出乱跳。

2.2 跌倒检测模块：MPU6050与姿态解算

跌倒检测的原理说起来很朴素：通过加速度计判断人体是否处于“平躺或倒置”状态，同时用陀螺仪判断是否有剧烈的角速度变化（摔倒时的翻滚）。判断逻辑是：

• 读取三轴加速度值，计算合成加速度acc_magnitude = sqrt(ax^2 + ay^2 + az^2)
• 正常站立时，合成加速度约等于1g（约16384 LSB，取决于量程设置）
• 平躺时，Z轴加速度接近0g，X或Y轴接近1g
• 摔倒瞬间，合成加速度会出现一个明显的尖峰，可能达到2-3g，然后用积分或延时判断后续是否持续保持“非站立”状态

MPU6050的数据读取是整套项目里最容易出bug的地方，几乎所有人都会被它的I2C时序坑一次。有几个点必须注意：

• I2C地址是0x68还是0x69：取决于AD0引脚的电平。有的模块原理图默认接高电平，有的默认接地，代码里写错地址，读出来的全是0xFF。
• 要等一下让传感器稳定：MPU6050上电后需要约100ms的自检时间，直接读取会失败。我在初始化里加了HAL_Delay(200)。
• 数据需要校准：每个传感器的零漂都不一样，代码里需要做简单的重力校准，把静止时的偏移量存起来，后续读取时减掉。

我建议程序里用一个结构体管理姿态数据：

typedef struct { int16_t ax, ay, az; int16_t gx, gy, gz; float acc_magnitude; uint8_t fall_detected; } mpu6050_data_t;

跌倒检测的判定我用的是“尖峰+持续性”双条件判断，避免误报。具体逻辑是：先检测到加速度尖峰超过阈值（比如2.5g），然后延时500ms再检查姿态角，如果姿态角表明人已经不是直立（超过60度），才判定为跌倒。这个算法非常有效，做实物测试的时候，故意跌倒和弯腰捡东西都能正确区分。阈值怎么定？弯腰捡东西时加速度也可能会超过2g，但捡完东西人会马上站起来，姿态角恢复直立，所以“5秒后仍处于非直立状态”这个条件能把误报压到最低。

2.3 水坑检测与光线感知逻辑

水坑检测传感器有两种常见选型：一种是水滴传感器（两片裸露的平行铜线，遇到水电阻变小），一种是LM393比较器输出的模块（模拟输出+数字输出）。后者更简单，直接接GPIO或者ADC读取。光线感知可以用光敏电阻模块，检测环境光照强度，过暗时提醒用户注意路况。

这里有个设计思路上的取舍：水坑检测和光线检测，用模拟量还是数字量？我的建议是光线用模拟量（ADC），水坑用数字量。原因是环境光照是一个连续变化的值，你可以根据时间设置不同的阈值（白天和夜晚的“暗”标准不同），而水坑就是个二元事件，有水没水，不需要细分。

ADC读取光敏电阻的电压值，通过HAL库的HAL_ADC_Start_DMA或者单次转换实现。要注意STM32F103的ADC最大采样频率和参考电压设置，如果参考电压是3.3V，光敏电阻分压后的输出电压范围需要落在ADC的测量范围内。

2.4 报警与提示电路设计

声音提示方面，用蜂鸣器是最省事的，超声波传感器测到障碍物时让蜂鸣器按照不同频率鸣叫，距离越近频率越高，这个反馈非常符合直觉。但更直观的方案是用语音模块，比如常见的JQ8900或者SYN6288，可以播报“前方障碍物，请绕行”“地面湿滑，小心慢行”等语音，演示效果极佳。代价是语音模块需要预先烧录音频文件，占一个UART口，而且成本会高一些。

如果是纯仿真项目，语音模块在Proteus里没有现成的元件，一般用LED灯或8段数码管代替显示提示信息。所以做“程序+仿真”版本时，我建议程序里把语音播报抽象成一个接口函数比如play_prompt(uint8_t prompt_id)，实物版本里接语音模块，仿真版本里直接映射到LED，这样同一份代码可以无缝切换。

SOS按键的设计要点是防抖和误触。硬件上用RC滤波，软件上用状态机延时消抖，长按2秒才触发，短按不触发，避免放在口袋里的拐杖被误触报警。触发后蜂鸣器长鸣、LED快速闪烁，再次按一下按键解除报警。

3. 软件工程结构与核心代码实现

3.1 基于状态机的软件架构设计

导盲拐杖的逻辑虽然简单，但如果全部堆在main函数的while循环里，代码会变得非常难维护。我建议用状态机来管理整个系统的运行状态，这样既方便扩展，也方便仿真调试。

系统状态可以划分成这样：

状态	说明	进入条件	退出条件
STATE_NORMAL	正常行走，周期性检测前方障碍物和地面情况	系统启动	检测到跌倒或按下SOS
STATE_WARNING	检测到障碍物或水坑，发出提醒	距离/水坑低于阈值	环境恢复正常
STATE_FALL	跌倒报警状态	跌倒检测确认	按键解除
STATE_SOS	紧急求助状态	SOS按键长按2秒	再次按键解除

在STATE_NORMAL状态下，传感器轮询间隔可以拉长一点（比如100ms），降低功耗；在STATE_WARNING状态下，可以切换为50ms轮询，提高反应速度。这个设计有一个额外的好处：答辩时如果老师问“你怎么降低系统功耗”，你可以直接说“通过状态机控制不同状态的传感器采样频率和主频切换”。

3.2 多路传感器轮询的时序管理

一个常见的翻车点是：三路传感器直接顺序读取，每一路都会阻塞几百毫秒，导致响应迟钝。超声波测距一次要等Echo回来，理论上最多要等20ms（4米距离的回波时间），再加上别的传感器，整体轮询周期可能超过100ms，这对导盲场景来说太慢。

我的解决办法是分时复用+轮询调度：

• 每50ms触发一次超声波测距，但不在主循环里干等结果，而是通过外部中断接收结果。
• 每200ms读一次MPU6050，姿态解算放在一个低优先级的任务里。
• 水坑和光线检测每100ms读一次ADC或GPIO。
• 每个周期通过一个简单的time_tick计数器做非阻塞调度。

伪代码：

uint32_t tick = HAL_GetTick(); if (tick - last_ultrasonic_tick >= 50) { ultrasonic_trigger(); last_ultrasonic_tick = tick; } if (tick - last_mpu_tick >= 200) { mpu6050_read_all(); check_fall(); last_mpu_tick = tick; } if (tick - last_env_tick >= 100) { read_water_sensor(); read_light_sensor(); last_env_tick = tick; }

这样做之后，系统的响应时间在50ms以内，演示的时候手挡在超声波前面，蜂鸣器几乎立刻就有反应，体验完全不同。

3.3 Keil工程组织与代码模块划分

整套程序的工程组织建议按功能模块拆分成独立文件，避免一个main.c写两千行。

• main.c：系统初始化、主循环调度。
• ultrasonic.c/h：超声波测距驱动，输入捕获计时。
• mpu6050.c/h：MPU6050的I2C驱动、姿态读取、跌倒检测算法。
• water_light.c/h：水滴传感器和光敏传感器的读取。
• alarm.c/h：蜂鸣器、LED、语音播报的控制。
• state_machine.c/h：系统状态机逻辑。

这样划分之后，你在答辩时可以很清晰地介绍“每一层都在做什么”，老师会认为你对工程结构有整体把握。哪怕只写了一个模块的功能，代码可读性也比堆在一个文件里强太多。

4. 仿真环境搭建与Proteus调试实录

4.1 Proteus仿真模型的搭建步骤

拿到这套资料后，仿真部分通常是很多同学最先尝试的。因为不需要买硬件，只要装的Proteus能跑，就能立刻看到效果。但仿真和实物完全是两码事，有几个坑是每个用Proteus做STM32仿真的人都会踩的。

首先，Proteus自带的STM32模型仿真能力非常有限。老版本连STM32F103C8的完整外设都没建模，新版本（8.9以上）仿真STM32时，对定时器输入捕获、DMA、ADC这些外设的支持很弱。所以仿真方案的一个策略是：

• 用Proteus里的**“虚拟终端”或者LED指示灯**来替代串口输出，避免依赖STM32的复杂外设。
• 超声波传感器在Proteus里没有现成的HC-SR04模型，一般用一个**“信号发生器+可调电阻”或者脉冲源**模拟Echo信号。
• MPU6050在Proteus里也没有模型，所以跌倒检测功能通常是把加速度值用按键模拟（比如按一下代表跌倒），代码里打印出检测结果。

如果你拿到的资料里已经给了现成的Proteus仿真工程，首先要确认两件事：一是你的Proteus版本号是否兼容；二是仿真工程里单片机的型号后缀是否和你编译的固件匹配。很多人在这一点上浪费了大量时间——工程里的芯片是STM32F103R6，你烧的固件是按照C8T6编译的，仿真时不会报错，但外设引脚映射不同，结果是灯永远不亮。

如果资料里的仿真文件打不开或运行报错，最省事的做法是自己搭一个最小仿真模型：STM32F103 + 一个LED + 一个虚拟终端。不需要完整复刻全部硬件，只要能验证主循环在跑、传感器数据能打印出来，对于验收答辩来说就够用了。

4.2 仿真与实物的差异及应对策略

很多人拿到仿真代码，直接下载仿真跑一下，灯亮了就说“程序正常”。但实物上电后，一堆问题就冒出来了：超声波距离乱跳、蜂鸣器不响、MPU6050读不到数据，等等。这之间的差异主要有三个来源：

• 供电能力：仿真里电源是理想电源，实物里两个传感器加一个语音模块同时工作，电流可能飙到500mA以上。如果你的开发板USB口供电不足，电压跌落直接导致传感器工作异常。解决办法是外接5V电源适配器，或者用一节18650电池经过稳压模块供电。
• 时序不确定性：仿真里GPIO翻转是纳秒级的，实物里因为有走线电容、上拉电阻、传感器响应时间，时序会出现微小偏差。比如超声波触发脉冲，仿真里10us就够，实物里有的模块需要20us才可靠。没事，把触发脉冲宽度加宽就好。
• 接触不良和干扰：手头没有示波器的话，排障特别依赖万用表。杜邦线太长了会引入干扰，超声波模块的Echo线上串个330欧电阻，能减少信号振铃。

这里分享一个我自己的调试习惯：先把程序烧到实物上，只测超声波功能，用串口把距离值打印出来，确认距离正确再往下接其他传感器。一步一验证，不要一次性全接上，否则出了问题根本不知道根源在哪。

4.3 Keil工程配置的三处关键设置

无论你用的Keil MDK哪个版本，STM32工程的配置有几处必须检查，否则编译没问题，烧进去就是不工作。

• 芯片型号选择：Project -> Options for Target -> Device，必须选对具体的STM32型号。选错型号可能导致启动文件不匹配，程序跑起来莫名其妙死机。
• C99模式：C/C++选项卡里勾上C99 Mode，代码里用for(int i=0;...)这种写法才不会被警告。
• 下载器设置：如果你用ST-Link下载，Debug选项卡里选ST-Link Debugger，Settings里确认能识别到目标芯片。如果用串口ISP下载，需要手动拉BOOT0到高电平，下载完再拉回来，很多人忘记这一步导致下载失败。

仿真时还有一个容易被忽略的点：Proteus加载的hex文件路径不能有中文或空格，否则Proteus会报错找不到文件，或者加载的是旧版本的程序。别问我是怎么知道的。

5. 常见问题与排障实录速查表

5.1 超声波数据跳变或归零

这是导盲拐杖里出现频率最高的问题。现象是距离值偶尔变成0或者跳到很大。排查步骤：

• 检查Trig和Echo引脚是否接反，以及模块供电是否稳定。HC-SR04的供电必须在5V，3.3V供电会导致测距范围急剧缩短或读数不稳。
• 检查代码里是否处理了超时。如果Echo一直高电平没有下降沿，输入捕获会一直等待，读到的距离就是错乱的。必须用定时器溢出中断做超时清0。
• 检查Echo引脚是否接了上拉。部分模块Echo引脚输出是推挽的，不需要上拉，但也有模块需要外接10K上拉才能稳定。

5.2 MPU6050数据读取为0xFF或I2C卡死

这个问题的根源，八成在I2C通信时序或者地址配置上。排查步骤：

• 用示波器或逻辑分析仪看SCL和SDA波形，确认起始信号、地址位、应答位是否正常。没有示波器就先把I2C速率降低到100kHz，排除时序过快的问题。
• 确认你的模块地址。MPU6050的7位地址是0x68（AD0=0）或0x69（AD0=1），读操作时实际发送的地址是(addr<<1)|1。在HAL库里配置的是7位地址，不要自己左移。
• 检查是否忘了等传感器自检。初始化时给HAL_Delay(200)，不行就500ms。

5.3 仿真中LED不亮或程序不运行

• 确认hex文件路径有没有空格或中文，确认芯片型号和程序编译时一致。
• 确认Proteus中STM32的BOOT0和BOOT1引脚电平设置。仿真模型中这两个引脚的状态会直接影响程序是从Flash还是System Memory启动。
• 确认晶振配置。Proteus的STM32模型有时不支持外部晶振仿真，如果你的CubeMX配置的是外部晶振8MHz，仿真时可能无法起振。改成内部RC振荡器（HSI）可以解决。

5.4 蜂鸣器声音异常或无声

• 蜂鸣器分有源和无源两种。有源的内部有振荡电路，给高电平就响，无源的必须给PWM信号才能发声。驱动代码如果按有源写的，接了无源蜂鸣器，就是无声或声音极小。
• 有源蜂鸣器的驱动电流比较大，直接接GPIO可能会把单片机引脚拉低，通常需要三极管或ULN2003驱动。检查驱动电路是否正常。

6. 实用改进方向与扩展思路

这套导盲拐杖方案做到“程序+仿真+全套资料”这个程度，已经是一个完整可交付的毕业设计作品了，但如果你想让它更有竞争力，或者想在这个项目基础上做进一步开发，有几个方向很值得探索。

• OLED显示模块：在拐杖把手上加一块0.96寸OLED，实时显示当前距离、电池电量、系统状态。成本十几块钱，但整体观感立刻提升一个档次。OLED走I2C，和MPU6050挂同一条I2C总线上，需要处理好地址冲突。
• GPS+GSM短信报警：增加GPS定位和GSM短信模块，跌倒或SOS时自动给预设的紧急联系人发带定位坐标的短信。这个功能非常契合导盲拐杖的实际使用场景，而且答辩时是非常亮眼的“社会价值”加分项。
• 低功耗优化：用STM32的待机模式或停止模式，增加一个加速度计中断唤醒功能，平时MCU休眠，只有当人开始走动时被中断唤醒。这条路可以做得很深，能写出一部分的功耗分析和实验数据。

我个人在实际操作中的体会是，这套项目最难的部分不是某个传感器驱动，而是把多个传感器稳定地整合在一起，同时兼顾实时性和可扩展性。很多同学把代码写成了“顺序执行的大杂烩”，结果加一个新功能就要改一堆老代码，最后整个工程一团乱麻。所以我才反复强调状态机和非阻塞调度的价值，这不是什么高深的技术，但确实能让整个项目的代码质量上一个台阶。

最后再分享一个小技巧：如果你在做实物调试，准备一根长一点的USB转TTL串口线，把STM32的USART1接到电脑上，串口打印是调试传感器数据最快捷的途径。很多问题，其实一行printf打印关键变量的日志就能定位，根本不用示波器。希望这套导盲拐杖方案能帮到你，也欢迎在评论区交流你在仿真或实物调试中遇到的问题。

本文还有配套的精品资源，点击获取