CSK.Blog--个人原创Weblog

自制低成本3D激光扫描测距仪(3D激光雷达),第一部分

本文介绍我从今年十一假期开始制作的激光3D扫描测距仪的相关原理和制作细节。对于先前提到的激光键盘制作将会在后续文章中详细介绍,不过他们的核心原理是相同的。
这是本系列的第一部分,第二部分请访问
自制低成本3D激光扫描测距仪(3D激光雷达),第二部分
http://www.csksoft.net/blog/post/lowcost_3d_laser_ranger_2.html

版权信息:

本文采用CreativeCommons2.5授权许可,欢迎转载,但请保留原始作者信息以及原文链接。

在开始介绍原理前,先给出一些扫描得到的3D模型以及演示视频,给大家一个直观的认识。

相关的图片:

 

扫描得到的房间一角(点击查看原始尺寸)

扫描的我(点击查看原始尺寸)

扫描仪实物图

扫描仪实物

 

本文结构

  1. 简单介绍了激光雷达产品的现状
  2. 激光三角测距原理
  3. 线状激光进行截面测距原理
  4. 3D激光扫描仪的制作考虑
  5. 参考文献

简介-激光扫描仪/雷达

这里所说的激光扫描测距仪的实质就是3D激光雷达。如上面视频中展现的那样,扫描仪可以获取各转角情况下目标物体扫描截面到扫描仪的距离,由于这类数据在可视化后看起来像是由很多小点组成的云团,因此常被称之为:点云(Point Clould)。

在获得扫描的点云后,可以在计算机中重现扫描物体/场景的三维信息。

这类设备往往用于如下几个方面:

1) 机器人定位导航

目前机器人的SLAM算法中最理想的设备仍旧是激光雷达(虽然目前可以使用kinect,但他无法再室外使用且精度相对较低)。机器人通过激光扫描得到的所处环境的2D/3D点云,从而可以进行诸如SLAM等定位算法。确定自身在环境当中的位置以及同时创建出所处环境的地图。这也是我制作他的主要目 的之一。

2) 零部件和物体的3D模型重建

3) 地图测绘

现状

目前市面上单点的激光测距仪已经比较常见,并且价格也相对低廉。但是它只能测量目标上特定点的距离。当然,如果将这类测距仪安装在一个旋转平台上,旋转扫描一周,就变成了2D激光雷达 (LIDAR)。相比激光测距仪,市面上激光雷达产品的价格就要高许多:

图片: Hokuyo 2D激光雷达

上图为Hokuyo这家公司生产的2D激光雷达产品,这类产品的售价都是上万元的水平。其昂贵的原因之一在于他们往往采用了高速的光学振镜进行大角度范围(180-270)的激光扫描,并且测距使用了计算发射/反射激光束相位差的手段进行。当然他们的性能也是很强的,一般扫描的频率都在10Hz以上,精度也在几个毫米的级别。

2D激光雷达使用单束点状激光进行扫描,因此只能采集一个截面的距离信息。如果要测量3D的数据 ,就需要使用如下2种方式进行扩充:

  1. 采用线状激光器
  2. 使用一个2D激光雷达扫描,同时在另一个轴进行旋转。从而扫描出3D信息。

第一种方式是改变激光器的输出模式,由原先的一个点变成一条线型光。扫描仪通过测量这束线型光在待测目标物体上的反射从而一次性获得一个扫描截面的数据。这样做的好处是扫描速度可以很快 ,精度也比较高。但缺点是由于激光变成了一条线段,其亮度(强度)将随着距离大幅衰减,因此测距范围很有限。对于近距离(<10m)的测距扫描而言,这种方式还是很有效并且极具性价比的,本文介绍的激光雷达也使用这种方式,

图:一字线红色激光器

 

对于第二种方式,优点是可以很容易用2D激光雷达进行改造,相对第一种做法来说,他在相同的激光器输出功率下扫描距离更远。当然,由于需要控制额外自由度的转轴,其误差可能较大,同时扫描速度也略低。

这类激光雷达产品目前在各类实验室、工业应用场景中出现的比较多,但对于个人爱好着或者家用 设备中,他们的价格实在是太高了。当然,目前也有了一个替代方案,那就是kinect,不过他的成像 分辨率和测距精度相比激光雷达而言低了不少,同时无法在室外使用。

低成本的方案

造成激光雷达设备高成本的因素为

  1. 使用测量激光相位差/传播时间差测距
  2. 高速振镜的高成本
  3. 矫正算法和矫正人工成本

对于个人DIY而言,第三个因素可以排除,所谓知识就是力量这里就能体现了:-) 对于前2个因素,如果要实现完全一样的精度和性能,那恐怕成本是无法降低的。但是,如果我们对精度、性能要求稍 微降低,那么成本将可以大幅的下降。

首先要明确的是投入的物料成本与能达成的性能之间并非线型比例的关系,当对性能要求下降到一 定水平后,成本将大幅下降。对于第一个因素,可以使用本文将介绍的三角测距方式来进行。而对于 扫锚用振镜,则可以使用普通的电机机构驱动激光器来替代。

本文介绍的低成本3D激光扫描仪实现了如下的成本/性能:

成本:~¥150

测量范围:最远6m

测量精度:(测量距离与实际距离的误差)最远6m出最大80mm误差,近距离(<1m),误差水平在 5mm以内

扫描范围:180度

扫描速度:30 samples/sec (比如以1度角度增量扫描180度,耗时6秒)

对于精度而言,这个低成本方案足以超过kinect,不过扫描速度比较慢,但是对于一般业余用途而言已经足够。不过,该扫描速度是很容易提升的,本文将在分析其制约因素后介绍提高扫描速度的方 法。

原理和算法

这里先介绍测量目标上一个点所涉及的算法。3D扫描将采用类似的方式进行扩充。

使用单点激光进行三角测距

 

除了使用相位差和时间差进行TOF测距外,另一种测距方式就是三角测距。这也是实现低成本激光测距的关键,因为这种方式不需要具备其他测距方式所要求的特殊硬件。并且,在一定距离范围内, 三角测距也可以达到与TOF测距媲美的测量精度和分辨率。

图片(来源自[3]): 激光三角测距原理

目前有不少爱好者[1][2]基于激光三角测距制作了激光雷达或者测距仪,本制作也采用了这个方式。除了本文外,参考论文[3]也给出了较多的细节。(该论文的作者所在的公司正是将低成本激光雷达用于家用机器人XV-11的开发商,这里就不扯开了:-)

这里摘录了论文中的示意图,要进行激光三角测距,所需的设备很简单: 点状激光器、摄像头。因此,能做到多少的成本大家现在应该比较清楚了。

图中展现了测量对象Object距离激光器的距离d的示意图。图中的Imager部分是对摄 像头的一种抽象表达(针孔摄像机模型)。标有s的线段实际可以是一个固定摄像头和激光器的平面。摄像头成像平面与该固定平面平行,而激光器发出的射线与该平面夹角beta仅存在于图中的视图中。

要测量距离d,首先要求激光射线射到了Object上,他的反射光在摄像头的感光平面上成像。对于不同远近的物体,当被测距激光照射后,摄像头上的成像光点的x值将变化。这里涉及到如下几个参数

Beta:激光器夹角

s:激光器中心与摄像头中心点距离

f:摄像头的焦距

如果这些参数在测距设备安装后不再改变(固定)且数值已知,则物体距离激光器距离可由如下公式求得:

q=fs/x        .... (1)

d=q/sin(beta) .... (2)

其中,x是测量中唯一需要获得的变量。它的含义是待测物体上激光光点在摄像头感光元件(如CMOS)上的成像到一侧边缘的距离。该距离可以通过在摄像头画面中查找并计算激光点中心位置的像素坐标来求得。对于示意图

式(1)求出了目标物体与摄像头-激光器平面的垂直距离(实际上对于大尺度测距,该值可以近似认为是实际距离)。这一步就是三角测距的所有内容了,非常简单。

 

不过,在实际操作中,上述公式仍旧需要扩充。首先时对于变量x的求解,假设我们已经通过算法求出了画面中激光光点的像素坐标(px,py),要求出公式中需要的x,首先需要将像素单位的坐标变换到实际的距离值。为了计算方便,在安装时,可以令摄像头画面的一个坐标轴与上图线 段s平行,这样做的好处是我们只需要通过光点像素坐标中的一个参量(px或者py)来求出实际投影距离 x。这里假设我们只用到了px。

那么,变量x可以由如下公式计算:

x=PixelSize*px+offset .... (3)

式(3)由引入了两个参数,PixelSize以及offset。其中PixelSize是摄像头感光部件上单个像素感光单元的尺寸,offset是通过像素点计算的投影距离和实际投影距离x的偏差量。这个偏 差量是由如下2个因素引入的:

  1. x变量的原点(示意图中与激光射线平息的虚线和成像平面焦点)的位置未必在成像感光阵列的第一列(或排)上(实际上在第一排的概率非常低)
  2. 通过摄像头主光轴的光线在画面中的像素坐标未必是画面中点。

对于PixelSize,可以通过摄像头感光元件手册来确定其数值。对于offset,要在安 装上消除offset或者直接测量,在业余条件下几乎是不可能的,因此,需要通过后面介绍的矫正步骤求出。

到这里,我们得出了通过激光点像素坐标(pX)来求出对应光点实际距离的公式:

d=fs/(PixelSize*px+offset)/sin(beta) .... (4)

 

接下来的问题就是如何确定这些参数了。不过,实际操作中,还需要考虑性能指标问题:要达到某种精度要求,究竟需要怎样的摄像头,上述各类参数如何选择呢?

决定单点激光测距性能的因素

有公式(3)可知,参数px是一个离散量(虽然有算法可以求出连续的px,后文将介绍) 。因此,得到的距离数值也将会发生一定的跳变。该跳变的程度反映了测距的分辨率以及精度。

如果将式(1)改写为x=fs/q并按q进行求导,可以得出:dx/dq=-fs/(q^2),或者写为 :

dq/dx=-q^2/fs .... (5)

式(5)的含义是,变量x每发生一次跳变,通过我们三角测距公式求出的距离值q跳变大小与当前实际待测距离的关系。可以看出,当待测距离边远后,从摄像机获得的像素点每移动一个单位距离,求出的距离值得跳变会大幅增大。也就是说:三角测距的精度和分辨率均随着距 离增加而变差

因此,要决定我们希望实现的指标,只需要明确:

希望测距的最大距离

在最大距离下,分辨率(式(5))的数值

在论文[3]中给出了他的选取规则,这里直接给出一个结论,具体过程就不重复了:

假设对于激光光点定位能做到0.1个次像素单位,单位像素尺寸为6um。并要求在6m处分辨率(dq/dx)<=30mm。则要求:

fs>=700

在我们制作过程中,这个要求还是很容易做到的。另外目前的CMOS摄像头往往具有更小的单位像素尺寸(在同样大小的芯片上做出了更高的分辨率),因此实际fs的取值下限可以更低 。

而对于摄像头分辨率、激光器夹角beta,则决定了测距的范围(最近/最远距离)。 这里也同样不再重复了,可以参考[3]。对于使用pX进行测距的摄像头,其分辨率480x640即可做出比较好的效果,更高的分辨率更好(当然后文会提到缺点)。beta一般在83deg左右。

 

2D激光雷达的原理和性能制约因素

在实现了单点激光测距后,进行2D激光扫描就非常容易:进行旋转。这里讨论的他的性能问题:扫描速度。

对于采用三角测距的方式,从摄像头画面上识别出激光点到计算出实际距离对于目前的桌面计算机而言,几乎可以认为不需要时间。那么,制约扫描速度的因素就在于摄像头的祯率了 。对于目前市面常见的usb摄像头,其工作在640x480分辨率的模式下最高帧率都在30fps,那么,扫描速度就是30samples/sec。换言之就是每秒钟进行30次的测距计算。

对于一个180度范围的激光雷达,如果按照每1度进行一次测距计算,最短需要6秒。

如果要提高扫描速度,很自然的就是提高祯率。对于usb摄像头,有PS eye摄像头可 以做到60fps。但这也只能实现3秒180度扫描。需要更加高的速率,也就意味着更快的传输速度,对于USB2.0而言,保证640x480的分辨率,fps很难有所提升。在论文[3]中,他们采用了高速摄像芯片+DSP 的方式实现了1200fps的帧率。

由于本制作不需要很高的扫描速度,因此我仍旧采用了30fps的摄像头。

3D激光扫描的原理

由前文已经指出,这里采用了线状激光器一次对一条线而非单点的目标物体进行扫描测距。将扫描器进行旋转,从而可以实现3D扫描。下图展示了他的工作画面和捕获到的摄像头画面 :

图:本制作早期使用的红色一字线激光器的工作画面

图:采用红色一字线激光器捕捉到的画面

对于线状激光器进行测距的问题,可以将它转化为前面单点激光测距的计算问题。 对于上图中的激光线条,算法将按照Y轴依次计算出当前Y轴高度下,激光光斑的X坐标值pX。并尝试通过先前的算法求处该点的距离。

为了简化问题,我们先考虑对于一个与摄像头感光面平行的平面上激光光斑各点的 距离问题:

图:激光线条光斑在平行平面上各点的距离问题抽象

如上图所示,远处平面为目标待测平面,上面有一条紫色的激光光斑。近处的平面 是摄像头的感光成像平面,经过了翻折后,他可以看作是目标平面到摄像头成像中心点组成的棱锥的一个截面。

图中的P1点位于摄像头投影画面高度的中点,按照针孔摄像机的定义,该点在画面上的投影P1'距离摄像头中心Camera Center的距离应当为摄像头的焦距F。因此,对于P1,可以直接带入式(4)求出实际距离

现在的问题是,对于其他高度上的点,如P2,是否可以通过式(4)求得?

图:3D测距的原理

答案自然是肯定的,不过这里涉及到了额外的参数。如上图所示,设P2的投影点P2' 到摄像头中心距离为f',则P2到baseline垂线距离d'可由如下公式得到:

d'=f'baseline/x .... (6)

而很容易知道,f'可以通过f求出:

f'=f/cos(arctan((P2'.y-P1'.y)/f)) .... (7)

其中的P2'.y以及P1'.y分别是点P2',P1'在成像元件上的实际高度,他们可由各自点像素坐标pY乘以像素高度求出。

在求出了垂线距离d'后,需要转化成实际的距离D,此时需要 知道P2-RotationCenter以及Baseline组成的夹角theta。该角度可以由立体几何知识通过激光器与 Baseline的夹角beta求出。具体的求解公式可以参考本制作配套源代码的计算部分。

在求出了平行平面上激光光斑任意点的坐标后,可以将问题一 般化,对于3D空间任意激光投影点,可以先构造出该点所在的一个平行平面,然后利用上述算法求解 。

对于每次测距采样,上述算法将产生一个数组dist[n]。其中 dist[i]为对应画面不同高度像素坐标i下激光点的距离。对于采用640x480分辨率的摄像头,n的取值 为480。

如果进行180度,步进为1度的3D扫描,则可得到分辨率为 180x480的点云阵列。
如果采用0.3度步进,扫描180度,则得到600x480的点云阵列

激光光点像素坐标确定和求解

这里讨论如何从摄像头画面中计算出光点的坐标信息,具体来说,要解决如下几个 问题:

  1. 识别并确定激光光点,排除干扰
  2. 确定光点中心的精确位置

先来看问题一,这个问题看似简单,不过实际会有很多问题,比如下面的几幅实际操作中遇到的画面:

 

图:不同环境和配置下摄像头捕获的画面

 

上面3幅图像分别是在使用红色激光器摄像头所拍摄到的。(a)的图像比较理想,在于画面中除了激光光点外没有别的内容,虽然可以看到上方有光电发射发出的干扰点,但激光光点仍旧可以通过求出画面中最亮点的方式获取。

(b)画面中出现了日光灯,由于日光灯亮度也较高,从画面上看与激光点中心亮度一致(均为纯白),对于这个图像,一种办法是同时判断临近像素的色彩,红色激光点的外围均为红色。

(c)画面中,除了激光点外,出现了其他的红色物体,并且部分高光区域也在图像中表现为纯白,此时,上述通过色彩判断的算法也将失效。因此需要有另外的办法。

完美的激光提取算法几乎是不存在的,一个例子就是当画面中出现了2个类似的激光点(另一个来自别的测距仪或者激光笔),此时单从一副图像上很难做出判断哪个才是正确的光点。

同时,较准确的识别光点也需要硬件设备以及光学设备的合作,具体的细节超过了本文的范畴。这里列举几种可行的办法:

1. 加装滤光片

在文献[3]和文献[4]中均提及使用滤光片的做法,仅保留激光器发射波长的光线进入,从而可以一定程度的避免光线干扰。

2. 调整摄像头曝光时间

调整摄像机曝光率也可以有效去除画面的干扰,例如上图(b)和(c),对于5mW的激光器,一定距离内其单位光照强度仍旧比日光强[3](人肉眼可以在室外识别出激光笔照射在地面的光点) ,因此,只要将摄像头曝光率调整的足够短,完全由可能将画面中除了激光点之外的内容剔除。

3. 采用非可见光激光器

例如使用红外激光器,这个做法与遥控器使用红外LED理由一样,在人造环境中少有红外光干扰。配合红外滤光片,可以有效滤除来自诸如日光灯等的干扰。但是,对于日光和白炽灯, 其中也含有足够强的红外光,无法单纯采用此法。

4. 增加激光器功率

配合曝光率控制,增加激光器发射功率也足以使得画面中仅保留光点,但这样也有危险性,尤其采用点状激光时。

本制作采用了上述的所有方法,将在后文具体介绍。

 

对于问题(2),最简单的做法是直接找出光电中最亮的像素的坐标。但是由于前面公式得知,这样的得到的pX值是整数,计算得到的q将会有比较大的跳变。因此这里介绍如何将pX变为更 加精确的"次像素"级别。

对于这个问题,学术界已有不少的研究,这里推荐参考论文[5],其中介绍了几种次像素激光光点定位算法的介绍以及分析了他们的优劣。这里也不再重复了。

简单来说,可以认为激光光点的亮度是一个二维的Gauss函数经过了一次采样得到了画面上的激光点。那么,可以通过拟合或者简单的线性插值/求质心的手段,估计出光点的中心。

本制作使用了简单的质心法求取次像素的激光中心点。

图:采用滤光片后,从白色日光灯画面(右上图)中识别并计算出激光光点中心坐 标

可能有人会问这样的估算精确有效吗?一般而言,精确到0.1个像素单位是比较可靠的,也有文献指出他们做到了0.01个像素的可靠定位。

对于线状激光器的求解过程与点状激光类似,区别在于将按照图像的每行(或者每列)分别找出激光光斑的中心。可参考文献[6],文献[7]给出了一个针对线状激光 更优的光点中心提取算法。

摄像头校正

进行激光测距的基本原理非常简单,但在实现中却有很多制约因素。除了前文提到的进行三角测距求解公式中的那些参数需要确定之外,校正摄像头从而得到理想的针孔摄像机模型下的图像也是很重要的环节。

首先要回答的一个问题是:为何要校正摄像头?校正什么参数?

校正的主要理由是实际上目前使用的摄像头并非是前文所提到的针孔摄像机模型。 所谓针孔摄像机,简单说原理就和小孔成像类似:光线通过一个小孔后再背后的感光部件上成像。但大家知道,现实的摄像机都是采用光学透镜聚光成像的,并且所用的透镜并非是抛物面的(很难加工 ),同时,感光芯片也透镜之间也非严格平行[8]。总之,现实就是产生的画面实际上存在扭曲和偏移 的。如果直接使用原始摄像机的画面进行测距,势必造成误差。因此需要进行相机的校正,通过校正 后获取消除上述画面扭曲和偏移的图像,再用来进行激光测距的相关操作。

图: 摄像头原始画面和经过相机校正后的修正画面

上图左侧图片是一种摄像头拍摄到的原始画面,可以明显看出图像存在着扭曲,对相机校正后,我们可以校正后的参数修正扭曲的画面,得到右侧图像的效果。

对于摄像机校正的具体原理、算法和过程超过了本文的介绍范围,具体信息可以参考如下的文献和教程:[8][9][10]。在本文后续的制作部分,也会介绍本次制作的校正过程和结果。

校正和求解三角测距所用参数

前文介绍的三角测距公式中涉及了如下的参数:

Beta:激光器夹角

s:激光器中心与摄像头中心点距离

f:摄像头的焦距

pixelSize:感光部件单位像素尺寸

offset:激光点成像位置补偿值

这些参数有些很难通过实际测量求出,有些很难再安装时就控制好精度。他们数值 的精确度会对测距精度有着非常大的影响。例如pixelSize一般都是微米级别的数值,很小的误差即可导致最终测距的偏差。

对于他们的求解,我们将在测距仪制作完成后进行的校正环节求出。这里的校正, 实际过程是在实现测量好的距离下采集出测距公式中用到的pX数值。然后通过曲线拟合的方式确定参 数。

这部分的具体操作将在后文的制作/校正过程中具体介绍。

 

制作低成本的3D激光雷达

这部分的内容请访问

自制低成本3D激光扫描测距仪(3D激光雷达),第二部分

http://www.csksoft.net/blog/post/lowcost_3d_laser_ranger_2.html
 

参考文献

[1] Details of the Laser Range finder

http://www.eng.buffalo.edu/ubr/ff03laser.php

 

[2] Webcam Based DIY Laser Rangefinder

http://sites.google.com/site/todddanko/home/webcam_laser_ranger

 

[3] K. Konolige, J. Augenbraun, N. Donaldson, C. Fiebig, and P. Shah. A low-cost laser distance sensor. In Int. Conference on Robotics and Automation (ICRA), 2008.

 

[4] Kenneth Maxon. A Real-time Laser Range Finding Vision System

http://www.seattlerobotics.org/encoder/200110/vision.htm

 

[5] Fisher, R. B. and D. K. Naidu. A Comparison of Algorithms for Subpixel Peak Detection. Springer-Verlag, Heidelberg, 1996.

 

[6] Mertz, C., J. Kozar, J.R. Miller, and C. Thorpe. Eye-safe Laser Line Striper for Outside Use. Intelligent Vehicle Symposium, 2002.

 

[7] J. Forest, J. Salvi, E. Cabruja, C. Pous, Laser stripe peak detector for 3D scanners. A FIR filter approach, in: International Conference on Pattern Recognition, Cambridge, August 2004, pp. 646–649

 

[8] Learning OpenCV: Computer Vision with OpenCV Library, Gary Bradski and Adrian Kachlev, first edition , 2008 O’Reilly, ISBN 978-0-569-51613.

 

[9] 分享一些OpenCV实现立体视觉的经验
http://blog.csdn.net/scyscyao/article/details/5443341

 

[10] Camera Calibration Toolbox for Matlab
http://www.vision.caltech.edu/bouguetj/calib_doc/

基于AVR的室外太阳能气象站一年工作情况报告

去年使用AVR和无线模块作了太阳能供电的室外气象站和信件检查器。至今仍旧工作稳定。下面是它采集到的温度湿度情况,以及自身运作状况。这里已图表做一些分析和总结。

 

目前该设备可通过网络在外部访问: http://cskhome.3322.org:8111 (请勿恶意攻击,虽然对我也没什么损失)

之前的文章

太阳能供电无线气象站及信件检测器和AVR以太网终端的设计制作

http://www.csksoft.net/blog/post/ihes_outsidesensor.html

 

 一年来的日均气温、湿度以及电池最低电压走势图 (点击察看原始尺寸):

 

 

图表由家中IHES服务器每天每半个小时一次采集得到,从气温上来说,曲线变化还是很明显的,和以前地理书上的曲线图一致。(有没有觉得今年最高日均气温比去年低了一点...)。湿度变化就没那么有规律了。

最后一张是电池最低电压的走势,可以看出大部分时间靠太阳能电池板的发电电池电压均维持在4V以上(锂电池3.3V-4.2V放电范围)。在今年7月份是下降到了3V左右。这是因为太阳能板出现了老化。我采用的是低价的滴胶工艺的电池板,在日照一定时间后其表面开始出现泛黄和龟裂。最终变得完全不透光。这也验证了太阳能电池板工艺与寿命的说法,滴胶工艺的寿命就在1-2年左右。

在更换了电池板后,一切又恢复正常。目前看来太阳能电池的发电量是足够设备使用的,那么接下来就可以考虑增加新的传感器(如监测风向,降雨量和地震波?)

 

稳定性方面,该气象站在工作近2年中有过一次大修,主要是更新固件以及更换太阳能电池板。不过在雨雪天气中,会出现偶尔的无线通讯困难。总体来说超出了我的预期:-)

 

电池功耗方面,该气象站在没有日照条件下,每8小时电压约降低0.2-0.3V。应该说是比较低的,考虑到目前的工作模式是服务期没半小时会通过无线进行数据轮训,发射红外线进行邮件检查等。目前遇到的一个麻烦反而是在白天太阳能发电量过大导致电池过充使得内部的保护电路动作。由于考虑到目前核心电路保存在无日光照射的阴暗处,所以没啥危险性。当然,这也另一个角度说明其实AVR的功耗也可以做的很低,只要有合理的编程控制。并非低功耗就需要使用MSP430。

 

另外一个有趣的现象是在日照充足的夏季,太阳能电池发电量(效率?)反而不如冬天好。电池最高电压在冬季均能在每日中午达到电池饱和水平,而在夏季每天13:00左右达到的最高峰往往只是4.0V。这一点我这里就暂不解释了,留给大家思考:-)

 

好了,分享就到这里,如果需要具体的气象采集数据,可以与我联系。

自制的低成本激光3D扫描测距仪和激光投射键盘

应该有不少朋友通过weibo和论坛的预告得知了此事,这里也同样做下预告。

上周陆续完成了如下2个作品:3D激光测距扫描仪 以及 激光投射键盘。目前正在编写他们的原理文章以及准备代码开源的工作。

这里先收集他们的图片集供各位预览。文章将在1-2周后首先公布于我的blog。然后会转贴在几个论坛和weibo上。

3D激光测距扫描仪

采用我们RoboPeak团队的RoboPeak USB Connector作为控制器,使用红外线激光进行测距。

性能参数:

测距范围:0-6m (校正范围)

绝对测距精度:1m内-/+10mm与实际值的偏差,5m处最大80mm与实际值的偏差

扫描角度: 0-180度

最小步进:0.3度

扫描分辨率: 480 points per sample

扫描速度:30 samples per sec (180度,1度步进需时6秒)

成本:~¥150

视频1: 实时3D场景重建:

视频2: 扫描得到的客厅:

近距离扫描得自己:

 

激光投射键盘:

 直接导致我做这个的想法是在淘宝找到了投射键盘图案的激光头,并且很便宜。那时候正好在做3D扫描仪,因此打算顺便做一个玩。由于两者其实原理类似。有了做激光测距的经验,完成这个键盘是很容易的(实际上我也只花了2天1个晚上就完成了所有部分)。

 

性能指标:

精度:+/-1mm的与实际值偏差

分辨率:0.1mm

刷新率: 30Hz

成本:~¥100

演示视频:

效果:

 

 

预告就写到这里,这些内容均会有文章介绍。而且了解我的人会知道,文章将会比较长:-) (写得也累)。我虽然很乐意能将自己的一些经验分享给大家,但也非常痛恨那些直接抄袭牟利的。所以届时在文章和代码上会做一些处理,如果只是照抄照搬,将是不可用的,但保证所有内容真实表达,真正去实践并理解文章的可以仿制出相同或更高性能作品:-)

 

敬请期待

我的微博

其实虽然开通有一段时间了,不过还是在这里当作一个"新闻"告诉大家:-)


欢迎相互关注。

我以前对微博这类有一定的抵触,怕这样自己今后就没有动力去写Blog。不过后来的一些事情说服了我,也不能太落伍。Blog我还是会坚持写,并保证有较高的质量。但在我尚抽不出时间前,大家可以前往微博看我的扯淡以及近期做的一些东西:-)

P.S. Blog我已经憋了有2-3篇长文还没发,尽请期待:-P

自然魔方-2011上海国际科学艺术展RoboPeak参展作品

原文发表于RoboPeak团队网站: http://www.robopeak.net/blog/?p=195

这个展已经酝酿了一年多了,而参展作品的一些相关技术我们也早在做(我blog似乎以前放出来些视频:-P)。不过真到了布展阶段还是很折腾的。大家能在繁忙工作之余一起负责这个展很不容易的。

 在本届上海国际科学与艺术展(http://www.science-art.com.cn/article.php?id=7162)上,我们团队很荣幸参与其中,参展作品为-《自然魔方》。

展览时间为5.13至5.23,展览位于浦东展览馆,免费开放。我们展位在4楼A厅,欢迎大家前去参观和体验 :-)

现场视频:http://www.tudou.com/programs/view/sQhnXxlNPBw/

 

 

作品简介

立体魔方Qube是RoboPeak团队对于物联网在家庭使用以及智能玩具领域的前瞻性探索,每个魔方都配备各种传感器,不断得采集外界信息,并通过无线芯片将信息与其他的魔方进行分享和交流。这是一个充满智能化物件的环境。可以说,物与物、人与物之间都是紧密相连着。

现场人与魔方的互动

绚丽多彩的魔方

我们的展位

技术介绍:

本作品是我们对2.4Ghz传感器网络以及创意电子的一次应用尝试,采用AVR+RoboPeak开发的ArduinoLite实现。我们将会在今后发布关于自然魔方的更多细节。

 

Arduino-Lite, 轻量级且高性能的AVR固件库

一篇拖了2年多的文章...目前首发于我们RoboPeak团队网站,可以过去查看中英文版本以及最好的阅读体验。这里只是缩略版本。

RP Blog文章:

Arduino-Lite, RoboPeak使用的高效轻量级AVR库(1) -- 介绍篇

http://www.robopeak.net/blog/?p=42

Arduino-Lite, RoboPeak使用的高效轻量级AVR库(2) -- 使用篇

http://www.robopeak.net/blog/?p=70

Arduino-Lite开发参考文档

http://www.robopeak.net/blog/?p=107

我blog早先时候写的一篇相关文章:

说说我从去年9月份开始的AVR单片机学习和使用

http://www.csksoft.net/blog/post/255.html

Arduino-Lite是我们RoboPeak机器人团队开发使用的轻量级高性能AVR固件库,我们机器人小车的AVR系统中全部采用Arduino-Lite所开发。目前已经将他全部开源了,希望对各位有所帮助。

Google Code项目主页: http://code.google.com/p/arduino-lite/

简介

Arduino固件库提供了非常易于初学者使用的函数库,可以很快对AVR进行开发,即使是专业人员用这个库也会觉得便利。同时他对引脚的抽象编号也有利于固件代码的移植。不过这个库相对体积过大,性能也不理想,所以难以在产品领域使用。这就是我们开发Arduino-Lite的原因所在。

Arduino-Lite包括了2大部分

1) 改良和扩充的Arduino固件库,

提供大多数情况下大于50%的代码尺寸缩小和10倍以上的运行速度加速。同时支持更多的AVR芯片和时钟频率。使得这个库能可被用于对成本和性能敏感的产品应用中

2) 自我包含的编译开发环境

不需要安装任何第三方程序即可完成AVR的开发、下载工作。Arduino-Lite自带了avr-gcc(WINAVR),不过创建新工程非常简单,基本的文件夹复制操作即可自动产生新的工程,也不用编写和修改Makefile脚本,都是智能进行的

 

这里先给出2个直观的例子:

实现PWM输出功能:

代码类型 代码 执行所需的AVR时钟周期
Arduino analogWrite(9, pwm_val); ~80
Arduino-Lite ANALOG_WRITE(9, pwm_val); 2
Arduino-Lite PWM_SET(9, pwm_val); 1
avr-gcc直接寄存器操作 OCR01 = pwm_val; 1

可以看出,Arduino-Lite提供的函数和使用方式与Arduino非常接近,但效率上他有和直接去操作AVR寄存器性能一致。

编写一个PWM驱动LED闪烁程序的代码尺寸对比: 

  • Arduino库产生的最终代码: 2048 byte
  • Arduino-Lite产生的最终代码: 100byte

对于AVR ISP编程器的支持,Arduino-Lite支持Arduino方式的串口下载,也支持HIDboot的USB-HID下载,同时原生支持我们RoboPeak做的开源USB免驱动编程器RoboPeak USB Connector进行AVR芯片编程(见http://www.robopeak.net/blog/?p=133)。

特点和适合使用的场合

同样使用C++/C编写且基于avr-gcc编译器。但与Arduino固件库相比,Arduino-Lite有如下优势。

非常轻量级

使用Arduino-Lite的固件往往比使用Arduino固件库小了50%以上.

高效率

许多Arduino-Lite提供的与Arduino固件相同功能的函数,例如digitalWrite之Arduino-Lite版本:DIGITAL_WRITE仅使用一条AVR指令实现.

支持更多的AVR芯片和时钟频率

除了 Atmega8(A), Atmega168(PA), Atmega328(PA), Atmega1280 芯片外, Arduino-Lite 也支持以下芯片: Attiny2313, Attiny26, Atmega48(PA), Atmega88(PA)

对于时钟频率, Arduino-Lite 支持从1Mhz 至 20Mhz 的频率范围.

 

除此之外,Arduino-Lite还有如下特点:

 

自包含,无需依赖任何第三方工具/编译器/库

只要系统中带有文本编辑器,即可直接用Arduino-Lite进行AVR固件开发、编译、烧录等动作。Arduino-Lite自带了avr-gcc(WINAVR)以及相关的函数库。

灵活易与整合的编译环境,基于Make,但无需用户编写或是生成任何Makefile

创建一个新的Arduino-Lite工程,最简单的办法是将模板工程文件夹解压缩并重命名为希望的工程文件。并将相关的源代码以任何目录结构放置于工程目录下,Arduino-Lite就能编译项目,无需用户修改/编写/生成Makefile.

 

我们认为Arduino-Lite适用于以下领域

  1. 对固件代码尺寸/器件成本敏感的场合,比如需要使用Attiny或者Atmega48等小Rom尺寸的芯片的场合
  2. 对固件执行速度有较高要求的场合,比如对实时性要求较高的工控领域和机器人控制器领域
  3. 喜欢使用Make脚本、自定义IDE等的开发环境
  4. Arduino/AVR爱好者,且有一定的编程经验,不满足于Arduino IDE环境,期望更高效的固件库
  5. 希望将Arduino的简易开发特性运用于Attiny, Atmega48以及不同时钟条件下的硬件环境
相比Ardunio的固件库,Arduino-Lite或许不适合
  1. 不喜欢命令行界面、Make编译脚本的人群 (我们也有计划将Arduino-Lite支持Arduino-IDE)
  2. 希望直接使用Arduino各类第三方库,急需应用的情况

实现细节

省略,请参考RP Blog原文:http://www.robopeak.net/blog/?p=42

 

如何使用

 可以在Google code上下载已经打包好的zip包,或者直接checkout 源代码使用,具体见:http://www.robopeak.net/blog/?p=70

 

开发和配置过程都异常的简单,基本都是鼠标操作即可搞定,也无需以来别的软件、库。

 

下面有段使用RP USB Connector进行AVR烧录的视频:

(http://www.tudou.com/programs/view/Den9uh3HTHE/)

 

函数手册

 略文,详见:http://www.robopeak.net/blog/?p=107

Arduino-Lite新增函数/宏

基本IO引脚控制

PWM输出控制

模拟量采集(ADC)

睡眠和延迟

中断处理和管理

串口通讯

调试功能

文本格式化

XV-11拆解和部件使用

详细的拆解照片就不发出来了,放出一小部分给大家看看,但不作解释:-)

XV-11国外已有不少开源项目利用起了这个硬件设备,蛮不错的。

最后来段视频:http://www.tudou.com/programs/view/1iMA0Tc3y1k/

Ar.Drone和XV-11入手

经历了一段时间的等待,Ar.Drone和XV-11都到货了,过程还算顺利。

 

Ar.Drone应该已经有不少人听说或者购买了,所以就贴几张照片,视频网上已经有太多了,就不重复了。

简单的说他是一个玩具级别的四轴飞行器。不过这个玩具还是比较复杂的,配备了前放和正下方的摄像头用于实时远程观看和航拍,并且用于姿态传感器数据,另外配备超声波测距仪(测高)、6DOF的惯导系统(3轴陀螺仪+3轴加速度计)。

虽然这个飞行器主要是供人消遣的(在iOS或者Android设备经过WIFI操作),不过厂商也提供了可在PC(linux, win32)、iOS、Android上的SDK,供开发者获取飞行器传感器数据、摄像头画面以及控制飞行。利用他的SDK即可实现自主飞行、目标物体跟踪和探测、SLAM等更加高级且有意义的事情。

另外他的控制系统是基于ARM9的Linux方案,网上也有人成功利用他的usb口外接额外GPS等外设、也可通过WIFI使用telnet登陆上边的linux shell,可谓充满了无限的可能性。感觉就是四轴中的Roomba...

使用下来觉得的确是一个不错的设计,虽然存在诸多缺点(噪音大,不是足够稳定,待机短),不过相比那些开源的四轴项目(如MK)或者其他的商业模型级别的4轴,Ar.Drone已经足够稳定和易用了,并且成本上也做得很出色,即使是售价都比开源的成本略高而已。这里面算法和传感器方案的创新有不少的功劳,比如他使用超声波方案代替了传统的气压计,节省了不少成本(虽然牺牲了些性能),也利用正下方的摄像头做水平位移的检测。

总的来说这是一款很值得体验的产品,并且,如果你不仅仅把他当作是一个玩物的话,他会带来更加巨大的价值。

 

再来提提XV-11,这估计国内就没什么人气了,不过他的竞争产品,Roomba相信大家就比较熟悉。XV-11和roomba相比绝对是遥遥领先了,不过他们都比不过人工的打扫效果。当然,我也并不看重他的打扫效果:-)。这里贴一些视频和图片:

 

http://www.tudou.com/programs/view/e4urN4N1uyk/ 

 

http://www.tudou.com/programs/view/X768U-jbvBY/

关于我们RoboPeak团队以及更多的图片视频

又是很久没有更新自己的Blog, 很多朋友都问起过RoboPeak团队和项目的情况,在我们正式发布Demo前,这里先透露一些相关的信息吧。今后关于RP的任何进展都首先会在团队网站公布,我的Blog也会友情转载:-)

 

团队网站:  www.RoboPeak.net

团队Blog: http://www.robopeak.net/blog/

RoboPeak是国内由一群软件工程师、电子工程师、新媒体艺术家所组成的机器人及相关技术领域的设计研发团队,于2009年底创建。

团队致力于民用机器人平台系统、机器人操作系统(ROS)以及相关设备的设计研发,并尝试将日新月异的机器人技术融入人们的日常生活与娱乐当中。同时,我们将尽力为机器人技术在开源硬件、开源软件社区的普及做出贡献。

团队在嵌入式系统、系统级软件/固件、图像识别等领域拥有丰富的经验,拥有独立设计,开发机器人操作系统、相关传感器设备硬件/固件的能力。

 

我们团队主要由高中本科的同学和朋友组成,大家利用业余的时间进行这个项目。之前我Blog中放出的照片中的智能小车就是我们制作的机器人平台系统的原型机,他包含了由团队自行设计的硬件系统以及我们定义的机器人操作系统RoboPeak Infrastructure. 下面贴一些进一步的介绍图片。

原型机的图片和配置:

激光雷达扫描得到的环境模型

下面是我们成员vinjn童鞋带来的演示视频:

激光雷达得到的平面地图信息

使用Ipad进行操控

一些RoboPeak设计的专属硬件

下面说说我自己的一些感想吧。这个项目至今已经快2年了,不过大家都比较低调,所以至今不大做什么宣传,不过我们都期待着在实现到一定的水平后有一个公开的发布演示,所谓厚积薄发:-)

就我个人来说,基本上业余时间都用在了RoboPeak上,虽然这目前只是一个业余的兴趣项目,不过还是希望能将他做到完美和极致。目前工作也差不多2年半了,的确感受到工作后不比学生阶段有很多的闲暇时间做些别的事情,也有很多现实的问题来面对。不过这不能成为放松的借口,通过参与RoboPeak,觉得还是有很多收获的,更重要的是有一群志同道合的伙伴,感觉很幸福。大家都在繁忙工作之余抽出时间来,很不容易。

机器人领域的特殊之处是他涉及的方面很宽,从最基本核心的机械、电子电路、传感器、运动理论以及到上层的软件构架、图像识别、定位和地图构建理论等都有所涉及。这一方面是一个很有趣的地方,因为这样可以在这个过程中学到新的知识和技能,我自己就从参与RoboPeak开始正式学习AVR单片机,以至于后来Blog都已经偏重硬件方面了。利用这样的机会去接触新的领域往往学习起来是最快的,不过另一方面也对从事这个领域的人有比较高的要求,如果只是简单的制作可以要遥控的小车,那这最多也就是个遥控玩具,要称为机器人,就需要有自主行动和规划的能力,这也是我们目前和今后打算探索的领域,也是打算在公开演示中所期望展示的部分。事情要做好,都要付出努力,兴趣也是如此,也需要有坚持和付出,过程不会都是有趣的,但是等到有了成果那种喜悦是非常美妙的。我自己也一直在想,虽然目前我们还是刚起步,一些设计也会被人觉得山寨,不过事在人为,这都会改变的。

另外也有不少朋友问过我们有没有打算开源或者公开设计,这个计划我们的确有,目前市面上也有很多优秀的开源库,例如MRPT(mrpt.org)库提供了现成的SLAM算法,当今比较热门的SLAM算法他都有所提供。今后在合适的时机,相信我们也会把自己的一些资料贡献给社区,希望对国内外机器人爱好者有所帮助,比如我们内部使用的Arduino改良库ArduinoLite已经公开(还没有机会好好的介绍),今后还有更加强大的东西会贡献出来。不过我们也担忧完全开源会被别人直接抄袭用于谋利,尤其是在我们国家,不过,真正有技术含量的东西,即使你全部开源了给抄袭者,他估计连怎么抄袭都不会。(相关的机器人研究论文和专利网上本来就都有)

说到此还是打住,大家如对我们的项目感兴趣,可以期待我们的正式发表以及我们的团队网页:-)

简单聊下SWF的保护

所谓简单聊下,就是大致提一下,不做深入研究,毕竟自己好久没涉及Flash这一块了。这里一方面是给好友Tony(http://www.greatony.com)开发的工具做一下宣传,另外也算分享一些我之前的想法吧。

和目前炒得很火的HTML5不同的几处之一,Flash产生的最终发布格式是SWF,而非可见代码的HTML tag + js 组合。这样虽然被很多人批评诸如对搜索引擎不透明、难以做第三方扩展等问题,但却有另外一个好处:对知识产权保护比较有利。

虽然位图、声音、矢量图等信息仍旧以原先的格式打包进入了SWF文件,这部分内容还是可以轻易被各类Flash逆向工程工具获得,但是最核心的AS3源代码已经被编译成为了Bytecode,理论上,这是可以做到令逆向工程者无法获取与源代码100%相同的逆向结果的。另外,扯开点说,swf本身也作了LZ压缩,在网络通讯上,与下载等量功能的HTML5也具有优势,同时Adobe也给出了比较清晰(?)的swf specification。所以我近期还是比较看好Flash的未来的。

好了,不扯远了,这里接说说前面我提到那个“理论上,这是可以做到令逆向工程者无法获取与源代码100%相同的逆向结果的。”相信凡是做过Flash开发的朋友们都知道这条目前是不成立的,诸如ASV等逆向工具均可以得到几乎是与源代码一致的反编译结果,甚至连内部变量都可以获得。造成这样的原因主要还是Flash编译器,比如mxmlc,对Bytecode没有做过多复杂的处理。

就像我之前在Flash交流会(http://www.csksoft.net/blog/post/avm2_intro.html)提到的,该编译器并没有在编译阶段对AS3源代码做任何的优化。(Flash VM将在JIT阶段做出简单的优化) 相反,他甚至会产生比源代码更加糟糕的Bytecode,同时,也会包含很多源代码的细节。这就给反编译提供了很多的便利。

其实相同的问题在Native程序开发时就早已遇到过,搞反汇编的朋友应该很了解混淆、花指令这类的概念。简单的来说就是插入无关的指令来干扰反汇编程序,使得他崩溃或者无法得到正确结果。同时,混淆的汇编代码也会造成人工分析汇编的障碍,从而提高了软件分析的难度,最终达到了保护软件核心算法不被逆向的手段。

同样,我们也可以利用这些技术来达到保护SWF文件的办法。关于这个,Tony同学比我有更多的研究,大家不妨阅读他Blog的几篇文章以及他前不久在Flash交流会做的演讲:

演讲:《Swf文件格式和Abc代码混淆工具的开发》

http://v.ku6.com/show/MwjMgfhEgUFoiZhx.html 

SWF文件格式和ABC代码混淆工具的开发 (一) – 出发点和目标

http://www.greatony.com/?p=84

 

SWF文件格式和ABC代码混淆工具的开发(二) – SWF和ABC文件格式

http://www.greatony.com/?p=96

 

Tony也开发了一款针对AS3.0 SWF的代码混淆与分析工具 SWFSpy,目前已经支持对Bytecode进行符号名替换、插入无关代码等混淆操作,对付ASV等工具已经绰绰有余,同时可以用来观察SWF各Tag数据,比如其中的图像资源,也可以反汇编ABC代码。受他之托,这里介绍此工具给各位。我个人认为此工具虽然目前还在不断完善中,但核心的混淆和分析功能均已经实用。

他网站提供了该混淆分析器的免费版本。

SWFSpy

http://www.orandea.com/product?lang=cn

 

下面是几张截图,分别为支持的混淆选项、Tag分析和反汇编。

 

 

 

再回来文章的主题上来,其实目前Flash的保护除了Bytecode混淆还可以做更进一步的扩充,比如已经广泛用于native程序的加壳技术,不过AVM2对代码执行权限的限制可能会制约加壳的实施,但不妨作为一个有益的尝试。加壳不但可以保护代码,同时也能降低代码尺寸,这个在Scene Demo中有很好的体现,如果今后谁实现个Flash版本的kkrunchy壳(http://www.csksoft.net/blog/view.asp?id=165)进行PAQ7算法的压缩,那或许Scene Demo比赛中说不定还真有Flash影子了,当然,Adobe需要继续优化AVM2才行。这就权当一种假设吧。

虽然工作后已经很久没有使用Flash开发过完整的东西,不过我还是会时刻关注这方面的技术,回想高中时候最早接触的Flash4到目前的Flash11,变化还是很大的。另外也想到自己Flash网站好久没有更新了,现在都是AS3得天下了,当年花费我比较大心血的AS1.0的网站,或许是可以开源了...

分页:[«]3[4][5][6][7][8][9][10][11][12][13][14][15][16][17][»]

日历

<< 2015-6 >>

Sun

Mon

Tue

Wed

Thu

Fri

Sat

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

Copyright Shikai Chen 2000-2012. Powered By Z-Blog(CSK Modified)