关于自动泊车及其他

考虑一个自动泊车的算法问题.

给定一个平面,考虑位置和车头朝向的话.
实际上就是一组(x,y,\theta)的三元向量p的描述.

对于传动/转向/制动系统来说,应该是存在一个函数变换f.
给定一组机械参数,对应的是位置和朝向的\delta值.

那么问题实际上就简化为,给定要给起始位置的描述向量A,和一个最终位置的向量B().
根据函数f的\delta变换约束,求一个AB的平滑曲线的问题.

直接的gradient descent求解的话存在几个问题.

一个是实际情况下存在一些障碍物的问题,也就是限制的\delta变换函数f的选择范围.

另一个是并不能保证最终求得的解是满足需求意愿的.

对于第一点来说,原则上只是在每一步改变cost function的问题.
但随之而来会带来跟第二个问题相同的境况.

某种程度上来说,这种greedy的搜索算法面临的问题始终是不一定存在这样的解.
而且,考虑到搜索的深度和广度问题,即使存在这样的解,在时间效率和复杂度上也可能不是很实用.

那么,能不能在不改变基本算法的前提下,尽可能地做写prune之类的降低复杂度和搜索空间呢?

考虑对于一个给定的点p,在一个f的变换下,存在一个关于x,y的偏移范围的L2-distance约束.
也即是说,每一次f变化所能造成的"最大"\"最小"差量是已知的.

于是,粗略的考虑的话,变换次数是跟AB两点间的L2-distance有关的.

换句话说,减少目标的L2-distance的话,就可能减少搜索空间的代价.

为什么是可能呢?

考虑点A的描述为(x,y,\theta),B的描述为(x,y,-\theta).
这两个向量在x,y空间的L2-distance是零.
但显然这时候的解并不是预期中的不用做什么.

那么,这个有什么实际意义呢?
毕竟,对于给定的AB两点,并不存在改变这两点xy纬度下的L2-distance的方式.

换个角度.

考虑存在一条经过B点的由f驱动的曲线S.
也就是存在一条预设定的泊车路线.

那么就存在一个可能的裁剪方式,把问题变换为求A点到这条预定曲线S上某点U的问题.
而U的求解可以简单的是上面提到的xy维度的L2-distance判定.

进一步地,给定一条曲线S的话,求解U的过程可以是直接的使用(x,y,\theta)坐标系的点到曲线最短距离来计算.
这样的话,就存在一定的可能性,使得算法的整体搜索空间有一定幅度的缩减.

但问题的根本并没有什么太大的改观.
依然是被一个约束限制着.

那就是这个搜索路径不一定存在所期望的路径解.

另一个问题是交互方面的.

不考虑硬件约束的话,是存在能得到周围障碍图的能力的.
基于此,以及车辆本身的一些参数,是存在自动寻找落点的方式的.

即使没有地面导引指示.
本质上可以理解为是一个空间填充问题.

但在一些极端情况下可能存在一些比较不太合理的方案.

一种情况就是,如果周围都是空旷地方的情况.

在这种情况下,filling slot的最有策略就是选择不动.
但实际预期的情况可能并不是如此.

考虑人工介入的情况.

给定一块触摸屏幕,通过一些简单的拖拽方式是可以以所见即所得的方式定义终点B的参数的.
因为基本上所有的物理/成象参数都存在一个固定已知的换算/变换关系.

所以这个方案在是现实并没有什么太大的困难.

实际上,扩展考虑下.
如果车辆设备全部能够电子通讯化的话,远程/遥控驾驶并不是一件非常复杂的事情.

之所以不能或者说没有实现的关键点可能在于通讯延时的问题.

考虑一个40km/h世俗,远程通讯延时是200ms的话.
那么"实时"传回的图像至少存在2米的距离参数.
再加上人体反应和round triptime的话,在人的角度看待做出的反应可能只是针对10米之前的情况做出的判断了.
这个对于交通安全来说,并不是一个能接受的事情.

但换个角度来说,如果是一个直连车辆的设备,那么延时就可能可以降低两个一两个数量级.
达到近似real time的情况.

也就是说,理论上,接个手柄或者键盘等输入设备来驾驶也不是完全不可能的.