关于ARM9视觉有兴趣的同志们可以进来听听我的心声

tsy1988331 2011-06-18 03:05:10

历时数月我完成了我坑爹的车载摄像头视觉的硬件和裸机程序作为一个倒霉的实践者我想谈谈我的感受我的硬件部分是由我购买的核心板和我自己腐蚀的双层电机舵机驱动板组成电路是没有问题的摄像头（MINI2440配套的那个）是架设在舵机上面板子放在一小车车体上之前看过几篇ARM视觉的论文我当时的目标就是让摄像头可以扫出一封闭物体的边缘然后和舵机得PWM信号和小车电机的转速信号做出一套数学联系让舵机转动直到摄像头的中心点横坐标与该边缘物体的中心横坐标重合然后电机差速让摄像头的Y线与车体中心线重合之后电机前后推进让摄像头的Y线再与物体中心Y坐标重合
这是最初步的构想
下面说实验结果

先说说我的CLK设置因为事先分析过各类CLK（抱歉我说的这么直白）的关系实际我要用到唯一需要改变的CLK部分（摄像头部分和友善之臂配套的裸机CAMCLK一致）只有舵机部分因为要把基础时间弄到US级所以改了MPLL 48M
/*upll*/ChangeUPllValue(56,2,1);//UPLL 96M
/*mpll*/ChangeMPllValue(56,2,2);//MPLL 48M
rCLKDIVN=1<<3; // UCLK=UPLL/2=48M HCLK=MPLL=PCLK=FCLK=48M
rTCFG0=(0x2f<<8)|(0x2f);// CLK FOR TIMER input=48M/(47+1)/100=10K HZ T=0.1US
rTCFG1=0;//all timer clk=input clk =5K T=0.2us
因为该改变并不影响CAMCLK 摄像头仍可以正常工作
好了先不说CLK 因为CAMCLK 和 PWM的CLK都在我的容忍范围之内每帧的扫描速度和舵机的反应速度都在我的预定之内
心情不太好直接说问题吧 ARM9配套的摄像头是可以直接提取出RGB数据光到色转换是已经完成不需在程序设置的那么我是把摄像头的RGB地址和240*320液晶屏的地址做了重叠的也就是说我所需要的数据范围压缩为240*320*16（RGB565）一帧那么我首先做的并不是划分三基色域而是只捕捉一帧图像的最亮点因为三基色的最大值都为白最小值都为0 所以我第一次实验就是将灯都关掉然后将打火机在摄像头前点亮然后看舵机是否能带摄像头转到与火焰最亮点的行值重合因为火焰的颜色在漆黑背景下最接近三基色最大值所以你只需要将SDRAM中转存的RGB按照液晶屏的地址顺序读出每读一个与前一个数据进行对比记录下一帧数据里最大的一个RGB值那么该值肯定就是火焰最亮点因为我只有一个舵机摄像头架设在舵机上面也就是摄像头只能水平转动所以可以将行的像素点数据和舵机的转角和PWM控制转角的信号做一个量化舵机是0到180度像素点是1到240号 PWM是1.5MS到2.5MS 将这三者进行一个量化比如我火焰最亮点在地Y行第X个（240*320）那么我只用保留X 也就是1到240个像素点这范围内的第X个 180度/240P 每个PIXEL对应舵机的0.75度又因为舵机转角和PWM 2000US对应是每度2000US/180度所以可以算出每PIXEL对应PWM多少US 设这个值为Z 比如火焰亮点在X 那么只需用XZ就可以控制舵机带动摄像头转动直到摄像头的中心点240/120与X点重合（有误差且实际不能用0到180度做量化）

问题就出在每一帧数据的逐点比对找出最大值得时间上我的摄像头是可以转动到火焰X方向但是这仅仅是找出每帧数据的最大值的时间就超过了我的预期还不包括色域判断这些更复杂的计算从SDRAM里逐点比对一帧数据的最大值（同等RGB保留第一个采集到的）我没有计算过要花多少时间但是至少是3到4秒肉眼都能完全分辨出来帧间隔了我承认我的主频不在最大频率但是我的第一步实验仅仅是建立在找出一帧最大值一个而且是裸奔都耗去这么长时间我实在不知道写那些论文跑操作系统的哥们儿找出一帧数据的边缘他们是否去算过这个计算量所需要的时间更不用说还建立个环境判断公式了 320*240都花了那么长时间我现在才发现我中套了当然也不排除我没估计到的地方有兴趣的朋友可以联系QQ774937617 讨论源码和电路图修正

...全文