循迹避障智能小车的制作实例
题目
一、任务
设计并制作一个寻迹智能电动车,根据要求完成从出发区到终点区的任务:
二、要求
1、基本要求
- 电动车从出发区出发(车体不得超出出发区),沿引导黑线向终点区行驶,电动车行驶过程中不可脱离黑色引导线行驶。
- 电动车行驶过程中遇到十字路口时发出声光指示信息。
- 电动车避开障碍物通过不得与其接触且选择最短行驶距离到达终点区。
- 电动车到达终点后应立即停车,但全程行驶时间不能大于 60 秒,行驶时间达到60秒时必须立即自动停车。
2、发挥部分
- 电动车行驶过程中遇到正立放置的障碍物电动车必须选择向左转避开障碍物,遇到倒立放置的障碍物电动车必须选择向右转避开障碍物,电动车不得接触障碍物。
- 电动车在完成一次完整的行程(即完成一次基本要求)后,拿走场地所有障碍物,电动车重新拿至出发区,重新起动,能重复上次行驶路线到达终点区。
- 电动车进入终点区域后,能进一步准确驶入终点区,要求电动车的车身完全进入终点区到达终点区中心。停车后,能准确显示电动车全程行驶时间和路程。
四、说明
- 场地上面铺设白纸,可用一张A0或者两张A1纸制作。
- 场地的引导线宽度2cm,可以涂墨或粘黑色胶带。示意图中的和尺寸标注线不要绘制在白纸上,出发区和终点区的边框为 25cm*25cm 用签字笔细线标注。
- 电动车出发方向由测评专家指定,可选择(如图)正X 方向或正Y 方向。
- 障碍物为饮用水瓶使用 380ml的农夫山泉空瓶,场地上可允许有最多两个障碍物(也可只有一个,也可以放置两个,由测评专家指定),放置位置可在任意十字路口中间位置(T 字路口不放置) 。
- 电动车允许用玩具车改装,但不能由人工遥控,其外围尺寸(含车体上附加装置)的投影,长<30cm,宽*20cm。
- 要求在电动车顶部明显标出电动车的中心点位置,即横向与纵向两条中心线的交点。
成品展示
现在已经缩短了车身 重新做了板子,两个瓶子的各种情况都能在11-25秒到达终点。
图片展示:
方案确定
1.循迹
循迹模块,使用红外收发管作为传感器即可。
需要在方格中直行、转弯,且能判断十字、T字路口,至少需要使用三路传感器。
这里使用了五路,多了两路辅助判断车体的体势。
2.避障/判断正倒立
同样使用红外一体管,通过区分当前高度能否接收到一定量的反射光来判断正瓶子的正倒立。
3.主控
选了自己熟悉的STM32
4.小车车身和电机
选用容易控制角度的2只舵机+1只导向轮。
车身用现成的套件组装。
程序部分
最重要的部分为“where_to_go.c”路径决策程序,以及“ctrl_system.c”控制主程序,使用一个平面状态机来完成功能。
总体描述
控制主程序
状态转换图
这个转换图应该挺难看懂,圆圈里的状态,与下面这个状态枚举是一一对应的:
1 | typedef enum SystemState{ |
这里列举一下”steering.h”(舵机驱动)供外部调用的函数(其实这个函数集,还是少了一个“?轮前进?角度”的功能的函数,现在用延迟代替,偷懒了呵呵)
1 | void STEERING_Init(void); |
总之,这个图想表达的信息,就是——探测障碍物和做决策的时间点:
- 直行中,遇到十字路口时–>做决策–>普通转弯
- 普通转弯后–>做决策–>紧急转弯
- 紧急转弯后–>做决策–>紧急转弯
(可以看出“普通转弯”和“紧急转弯”的应用时机不同,因为车的体态不一样,这里的普通转弯有一个轮子前进半圈的过程(为了转弯后,车身能与轨迹平行),而紧急转弯是直接转动车身。)
每当“做决策”的时候,控制程序便调用“where_to_go.c”的函数,告诉决策模块:前方是否有障碍物(以及障碍物的正倒立情况)、是否达到了下一个十字路口(供决策程序计算更新当前坐标),而决策程序返回“该向左还是向右走”的决策。
决策程序
这里实现的决策程序最终得到的,并不是最优路径,这里用了一种偷懒的方式。
1 | typedef enum{ |
决策程序的主体思想是:
事先人工构建一个决策表(这里的DIR_GO WTG_TABLE[X_LENGTH][Y_LENGTH][4]
),由当前的坐标和车身方向,确定一个新的行走方向(直走,左转,右转或者停止)。
- 普通模式下:当行车路线不由障碍物正倒立情况决定时,根据决策表决定方向,并记录决策
- 回放模式下:无视障碍物情况,完全依据历史记录行走。
其中还有一个小细节,就是确定前方有障碍物之后,应记录下来,确保之后不会走到那个点(checkBarrierPoi函数)。
一些细节
到这里,小车主体功能已经实现了,但是实际调试的时候,会发现一些问题。
避障模块,区分正倒立的特殊情况
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20//bit0 1:上面两个探测器,bit2 3:下面两个探测器
const BARRIER_TYPE DATA_TYPE_TABLE[16] =
{
BARRIER_TYPE_NONE, //0000
BARRIER_TYPE_DOWN, //0001
BARRIER_TYPE_DOWN, //0010
BARRIER_TYPE_DOWN, //0011
BARRIER_TYPE_UP, //0100
BARRIER_TYPE_UP, //0101
BARRIER_TYPE_UP, //0110
BARRIER_TYPE_DOWN, //0111
BARRIER_TYPE_UP, //1000
BARRIER_TYPE_UP, //1001
BARRIER_TYPE_UP, //1010
BARRIER_TYPE_DOWN, //1011
BARRIER_TYPE_UP, //1100
BARRIER_TYPE_UP, //1101
BARRIER_TYPE_UP, //1110
BARRIER_TYPE_UP, //1111
};循迹传感器模块 传感器间距的问题
最好让间距正好合适:在未脱轨时,靠前的三个传感器,有且只有一条感应到轨迹。
这样能让车子的前进路线更直。车身惯性的问题
注意放慢速度以及适当停止运作一段时间即可。
总结
程序编写,总共耗时三天半,一天半完成各部分驱动以及大致流程,一天研究路径决策,一天边调试边修改程序..
最麻烦的地方还是路径决策..其他功能都是可以慢慢调试出的.
这个路径决策,我还是不满意,理想的结果应该是:每获得新的障碍物情报,根据当前位置和情报重新计算具体路线,若路线上再发现情况,再计算新路径。算法还是得多积累。
写在作品验收之后
验收时看到不少同学的作品,发现了一些别人做这题出现的问题:
- 调速不到位,不知道是使用了差的减速齿轮还是程序没写好,小车速度降不下来
- 传感器配置不合理,有人做了个——前2个红外对管,后2个红外对管,到最后都没调试出来——没事别给自己增加额外的难度
- 程序编写问题,尽量用状态机思路吧,别想着全靠延迟来完成这东西,现实中可变因素太多了
- 调试场地和实际场地不符,这肯定要跪
2015-10-19
比赛结束了,我把资料包放出来吧.