主题 : 关于ARM9视觉 有兴趣的同志们可以进来听听我的心声 复制链接 | 浏览器收藏 | 打印
级别: 新手上路
UID: 26223
精华: 0
发帖: 8
金钱: 40 两
威望: 8 点
贡献值: 0 点
综合积分: 16 分
注册时间: 2010-08-05
最后登录: 2012-09-10
楼主  发表于: 2011-06-18 13:50

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

历时数月 我完成了我坑爹的车载摄像头视觉的硬件和裸机程序 作为一个倒霉的实践者 我想谈谈我的感受 我的硬件部分是由我购买的核心板和我自己腐蚀的双层电机 舵机驱动板组成 电路是没有问题的 摄像头(MINI2440配套的那个)是架设在舵机上面 板子放在一小车车体上 之前看过几篇ARM视觉的论文 我当时的目标就是让摄像头可以扫出一封闭物体的边缘 然后和舵机得PWM信号和小车电机的转速信号做出一套数学联系 让舵机转动直到摄像头的中心点横坐标与该边缘物体的中心横坐标重合 然后电机差速让摄像头的Y线与车体中心线重合 之后电机前后推进 让摄像头的Y线再与物体中心Y坐标重合
这是最初步的构想
下面说实验结果
级别: 新手上路
UID: 26223
精华: 0
发帖: 8
金钱: 40 两
威望: 8 点
贡献值: 0 点
综合积分: 16 分
注册时间: 2010-08-05
最后登录: 2012-09-10
1楼  发表于: 2011-06-18 14:43
先说说我的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度做量化)
级别: 新手上路
UID: 26223
精华: 0
发帖: 8
金钱: 40 两
威望: 8 点
贡献值: 0 点
综合积分: 16 分
注册时间: 2010-08-05
最后登录: 2012-09-10
2楼  发表于: 2011-06-18 14:56
问题就出在每一帧数据的逐点比对找出最大值得时间上 我的摄像头是可以转动到火焰X方向 但是这仅仅是找出每帧数据的最大值的时间就超过了我的预期 还不包括色域判断这些更复杂的计算 从SDRAM里逐点比对一帧数据的最大值(同等RGB保留第一个采集到的)我没有计算过要花多少时间 但是至少是3到4秒 肉眼都能完全分辨出来帧间隔了 我承认我的主频不在最大频率 但是我的第一步实验仅仅是建立在找出一帧最大值一个 而且是裸奔都耗去这么长时间 我实在不知道写那些论文跑操作系统的哥们儿找出一帧数据的边缘 他们是否去算过这个计算量所需要的时间 更不用说还建立个环境判断公式了 320*240都花了那么长时间 我现在才发现我中套了 当然也不排除我没估计到的地方 有兴趣的朋友可以联系QQ774937617 讨论源码和电路图修正
级别: 新手上路
UID: 32057
精华: 0
发帖: 21
金钱: 105 两
威望: 21 点
贡献值: 0 点
综合积分: 42 分
注册时间: 2010-11-09
最后登录: 2017-09-13
3楼  发表于: 2011-06-23 11:11
我做的东西跟你的差不多. 是在linux系统下做的.现在采集jpeg图像,解压缩,显示,图像处理,加起来1.5秒一次吧.640*480的图像.
我加你qq了.有时间相互讨论.
2440
级别: 侠客
UID: 34266
精华: 0
发帖: 68
金钱: 350 两
威望: 70 点
贡献值: 0 点
综合积分: 136 分
注册时间: 2010-12-13
最后登录: 2015-07-01
4楼  发表于: 2012-03-14 09:00
看来需要上context处理器了吧
2440
级别: 侠客
UID: 34266
精华: 0
发帖: 68
金钱: 350 两
威望: 70 点
贡献值: 0 点
综合积分: 136 分
注册时间: 2010-12-13
最后登录: 2015-07-01
5楼  发表于: 2012-03-14 09:01
cortext
级别: 新手上路
UID: 28010
精华: 0
发帖: 35
金钱: 175 两
威望: 35 点
贡献值: 0 点
综合积分: 70 分
注册时间: 2010-09-04
最后登录: 2013-12-01
6楼  发表于: 2012-09-02 05:04
It looks like, that the calculation capcity of the processor is too low.

In this case you may need some algorithmen, like you under sample your data to like 80x60, instead of 320x240. Then you will be 16x faster. 320x240 is the resolution you do not need.

Tell me about what you have tryed.