用51 使用摄像头的可行性分析 凭什么我么51的寻线小车就不能用摄像头!!!!【恢
一直觉得摄像头阿 图像处理阿 很神秘,总与 高速,32位,ARM,昂贵 这些词 分不开的。总是让我这种只用51之类的8位单片机的学生望尘莫及。直到最近发现 阿莫这里有卖OV6620图像处理器的,好便宜。终于心动了 ,想拿来玩玩这个传说中的高级的东东。于是着手开始在网上搜集资料。
问过很多人包括学校教过我单片机的老师,只要一提到图像处理 他们就说我至少得用32位的片子。如果我说我想用51 来。。。。那么他们肯定对我不屑一顾,或者说我天方夜谭。
图象处理有那么难么?彩色的不行我弄灰度的不行么,灰度的不行,我弄黑白的不行么?
问别人是不行了,自己一点点来琢磨吧。
首先得了解 图像传感器的原理。关键词 CMOS图像传感器 PLA lm1881视频信号分离
找了好久才意外的在 好像叫飞思卡尔的寻线小车比赛的资料那了解到。 在这个论坛上也有 ,而且好多 :)所以我就不多说了 贴出一个时序图(图一)来大概表示一下。
http://cache.amobbs.com/bbs_upload782111/files_11/ourdev_455172.JPG
(原文件名:PAL.JPG)
传感器工作原理基本知道了,那么就该考虑如何提取信号了。看到的那些资料一般采用的都是 高度AD加+16位单片机。单片机的速度没问题我的STC的能接48M的晶振 还是单时钟/机器周期 :)。可AD就不行了, 人家AD速率是M级的 我的 才K级,差太远了。根本不行。于是第一个念头就是找个高速AD,精度低无所谓,速度能上去就行。去了下电子市场,人家的高速AD都是专柜的,最便宜的100多!!去淘宝,淘了半天 ,找到的最便宜的 都大几十。 都太贵了阿 ,我一个穷学生买不起啊 。给一个十块钱的单片机 配一个 好几十的AD 也太不划算了 。
不得不再降低要求了,灰度图像处理不了,那黑白(二值化)图像不行么? 寻线小车不就是找黑白线么?他们采集了灰度图像不也是最终才程序里要 二值化么。于是!!!!!!!!!!!!我想起了我之前寻线小车红外传感器的电路!!一个运方搭的 比较器 !!用它把传感器输出的信号 二值化处理 然后用普通 io口采集不就行了? 我就不信运方的速度还会跟不上!!!!关于 黑白的阈值暂且有两种想法,一种是固定的,用一个可变电阻提供阈值电压,自己手动在现场调试合适为止。 另一种复杂点的就是用 动态阈值,比较电压用一个DA提供。使用时,先给摄像头各个标准的黑白图像,让单片机自动调整阈值电压
直到得到合适的图像为止。
图像数据就算采集好了吧。下面开始图像识别咯。分辨率暂且定为84x48 ,(因为我用的诺基亚5110的液晶屏 就是这个数 打算采集的图像给他显示) 一幅这样的图算下来也就504 字节,STC的58的RAM有1280字节, 足够了 。
1对黑线的识别 那些寻线小车的技术报告里已经写了很多了,我就不多说了。
2对于我这种二值化图像采集的方法 除了能用在寻线 上 还能有什么 有用的地方么 ?
a 阿哈 偶然间想起一句话 “白纸黑字 写着清清楚楚” 就用它来识别白纸上的简单符号把。
之前一直在琢磨 怎么用 触摸屏 实现 手写 或者 手势 识别,这下用上了。
(未完 待续)
继续上面的
纸上的线条 和触摸屏 输入的线条区别就是 纸上的线条比较粗,而触摸屏输入的可以认为是单纯的轨迹线条 。那么先把图像处理以下 ,计算黑色轨迹的重心 ,就可以等同 触摸屏那样识别了。
关于触摸屏 识别的大体思路 目前的设想是,将输入的线条 和实现存库里的模型比较,如果80%吻合的话 就认为比对成功。
但是,平时输入的轨迹大小不一,如果直接对比的话效果不太理想。于是就想出了个办法, 再比对前,将输入的轨迹安比例缩放成和库里的模型长宽相同的一个图形。然后再进行比对。 下面花了个示意图 (图3)。
图2
http://cache.amobbs.com/bbs_upload782111/files_11/ourdev_455170.jpg
(原文件名:zhongxin.jpg)
图3
http://cache.amobbs.com/bbs_upload782111/files_11/ourdev_455171.jpg
(原文件名:手写识别.jpg)
以上纯属个人瞎想,希望能在这里和大家讨论讨论 交流交流。 :)
本贴被 hexixiaomao 编辑过,最后修改时间:2008-10-15,04:11:10. 根据这个思路,我想,如果只是寻线,可以利用一排感光元件来检测,甚至不用摄像头,类似于扫描仪的原理. 支持楼主,我公司有一个图像火检项目,采用dm642为处理器,对saa7111采集的数据进行处理.不过看见有人做的一个简单的电路,好像用很小的单片机就能实现,实际处理的就是视频画面内的亮暗部分区分.我想,楼主的思路应该有实现的可能.我提供一个思路,用一个简单的三极管电路,就可以检测视频信号的行同步信号,检测到行同步信号后,单片机就可以计时,比较器输出的电压高低时间,分别对应那一行的黑白对比,这样处理起来应该很简单.黑线偏移,可以简单通过行同步开始后,脉冲变化时间的区别判断向左还是向右,以及可能的角度,然后车根据这些数据进行调整姿态,应该是可行的吧? 很佩服你这种精神,事实上很多新发明新创造就是在别人认为不可行的情况被那些勇于探索的人实现了,不要理会你老师的不屑,中国这种误人子弟的教育呆子太多了,我相信即使不成功你也会学到很多东西 先把视频分成16×16,只采这256个点,先玩起来,慢慢改进算法提高分辨率。
一定能成功的。 支持哈,我觉得关键是要有想法,有了想法慢慢琢磨,可以得到很多东西的!
单片机的资源要是挖掘还是不少的,51还是不是想想中的那样慢! 加油 上半年参见飞思卡尔用的摄像头 32*32点阵 32级灰度图像 6bit数字接口。
用的飞思卡尔8位单片机驱动。超频到24M。 当然可以 速度问题而已 希望各位高手能够 多提点意见帮忙 我现在忙着找工作 目前还没时间 弄这个, hzyhscm 能不能告诉我下 你的那块用51产生视频信号的东东的详细点的信息 谢谢 好想法,支持。如果真的可以那该多好啊,期待。。。。。。。。。。。。。。。。。 支持 支持 1,你说你用的单片机还是单时钟/机器周期
2,后面你又提到58,1280RAM,应该是STC89C58吧
STC89C58不是单时钟/机器周期。 潜力贴,站好位置 好,顶起 可以的 顶!LZ继续努力。 支持 俄 顶得好快 呵呵 谢谢 顶!希望你能成功。 fifo 好是好 不过要是这样算下来 比用arm都贵,没必要了。
要去找工作面试咯 具体下一步实现 等有了空再说 :) 争取在年前实现。
不是非要抱着51不放,现在一片 STM32比一片增强型51贵不了多少,价格性能51都已经都没啥竞争力了。淘汰早晚的事。
我发这个帖子就只是想 尽量的用最有限的资源来实现高级的功能。或者说 扩展下思维 ,把一个复杂问题简单化。 留名,看后面的分析 楼主思路清晰,不错 没 p89lv51倒是可以双倍速 12系列我也用过 看了资料 据说是挺快的 不过没具体测试过 上面的 别动不动 就说51 慢 12系列的 我用过 能上48M晶振 单指令周期 相当于8051的576M !!!! 谢谢 九九
我去看看资料 我知道ST12系列是单时钟,可是你后面说用58,有1280RAM,你找找12系列有这个吗? 回 13楼 目前世界上 效果最好的 寻线机器人 根本就没用摄像头的。结构设计的很巧妙。那个的视频网上好多。国内的比赛,个人认为,所有人的基本框架都一样 ,没有什么根本的创新的地方,只是拼参数,拚你调的效果而不是创意。 回 8楼stc12系列的是 单时钟的 回 13楼 我做小车的思路 一直都是 分布式控制的 一个单片机 只管某一方面的任务。 顶!!! 给点思路
最好是有动态阈值电路
还有,既然你用了OV6620,为什么不考虑用数字方式采集图像呢?
在摄像头和cpu之间加一个fifo,先把图像丢到fifo里,cpu一次取一部分来处理,也不怕cpu速度不够内存不大了。。
《电子技术应用》第9期,有相关资料 同感 楼主 包括我在这里问的和qq群问的 无一不是被人不屑一顾 顶你 顶四你 想法不错 但不全面 没有从项目总体的可行性入手。
识别不是瓶颈,瓶颈是算法我认为。
数字图像处理算法 对51是个考验
寻线小车我也做过 用的是飞利浦的单片机,由于单片机的速度还可以告诉过S弯道时很平稳
你的单片机既要处理图像又要控制小车行走。
不知道1秒能给小车多少控制命令。
随便玩玩的话,如果车走得慢应该可行。
但是要是比赛用那就算了。[你可以看一下第一届飞思卡尔全国的比赛视频 清华和上海交大的那几台车]
本贴被 leealian 编辑过,最后修改时间:2008-10-15,12:33:49. 支持一下 总体思路正确!好好干!
不过,最好放弃51,用更快的CPU。能做更多的事。 顶 不是不能用,而是51的速度跟不上,AD的转换速度低的话采集图像分辨率低。
如果用OV6620之类的CMOS传感器的话是不要求单片机有AD的,传感器直接输出图像数据
如果只要求小车能寻线慢慢走的话用什么单片机都没关系,像飞思卡尔比赛平均速度每秒3米以上的,51就肯定不行了 拆机二手fifo idt7205 20块钱
如果,你不在乎分辨率 跳着采集数据也行
忽略掉每个像素的PCLK沿信号,直接ip口不间断读摄像头Y口数据,虽然方法不规范,但也行得通 帮你顶一个 楼主的标题好吓人,呵呵
将摄像头的信号硬件二值化后用51做采集是没问题的,这是的摄像头相当于一个二值传感器阵列
不过这里有个问题,就是阈值的选取,楼主也提到了
比较好的办法还是用运放做个动态阈值的电路
难点还是后面的字符识别部分,放在51单片机上实在是难为它了...
本贴被 dreampet 编辑过,最后修改时间:2008-10-15,18:54:19. MARK 潜力贴...有可能发展成为酷贴...标记一下... 哈哈,这个好玩
摄像头的图像传到液晶,并存到SD卡 谁能玩 好帖,先顶一下啊,我也准备用51和摄像头做寻线小车来着,被老师打击了··· lz的思路很好 关键是速度问题,如果不要求高的速度,可以隔点采集数据,图像的精确度不高,想跑快是不可能的,但是绝对可以实现功能。这事自己做飞思卡尔的一点经验 老大,你换摄相头吧,数字输出的 搬个板凳过来学习一下! 玩飞思卡尔不行,玩电子大赛总应该还可以吧。。。它对速度要求不是很高的。 我认为不行,看摄像头的传输什么速度,单片机又是什么速度!想都不敢想啊! 老外说: LZ I服了U. lz:你说的CMOS传感器的资料在哪啊?我这个菜鸟怎么没找到呢? 很有思想!! 如果你想用OV6620这类型的COMS图象芯片,就不需要AD了:)。
不管怎样,图象采集的关键在于PCLK,也就是单象素数据时钟的同步以及图象数据的存储。
从存储要求上看:
1. 采用RGB565或者RGB555,84*48分辨率,每个象素得数据需要两个字节来存储。总的数据大小是 84 * 48 * 2 = 8046字节
2. 采用灰度,每个象素数据需要1个字节来存储。总的数据大小为:84 * 48 = 4032字节
3. 采用黑白图象时,可以将一个象素的数据存储在一个比特上而不是一个字节的空间中。当然,需要进行一些额外的计算。
如果还要进行图象处理,那么大约需要图象数据大小3倍的内存来保证系统的稳定运行。因为图象处理算法会消耗大量的栈空间。
从图象采集的速度上看:
如果使用通用I/O口来采集OV6620的图象数据,关键在于PCLK信号的同步。常用的有两种方法:
1.使用轮循的方式来同步PCLK信号。
2.使用MCU硬件中断的方式来同步PCLK信号。
针对32位arm指令,轮循pclk方式的汇编代码可能具有如下的结构(以灰度图象采集为例):
ldr r1,=STORE_ADDR ;r1中存放存储区域地址,通常是一个数组的首地址
ldr r2,=NUM_OF_DATAS ;一行图象的字节数
add r2,r2,r1 ;当r2等于r1时说明一行图象采集结束
check 周期
ldr r0,=PCLK_SIGNAL;获取pclk引脚数据状态 3
tst r0,#PCLK_MARK ;判断引脚状态 1
beq check 3
ldr r0,=IMG_DATA ;获取图象数据 3
str r0,,#1 ;存储图象数据 3
cmp r2,r1 ;判断一行图象是否采集结束 1
bne check 3
如果使用中断方法,唯一不同的是pclk引脚状态的判断。从外部信号变化到中断发生,通常会有一段3~5周期的延时,这可以在所使用
的MCU的手册中查到,我们这里假设是4周期。在进入中断状态以后需要至少一条的转跳指令和若干保存寄存器的指令,在中断处理结束以后还要加上一条回跳指令。这样计算需要的周期数至少为:4 + 3 + 1 + 3 = 11。而轮循方式只需要7周期而已。
我在每条指令的后面列出了周期数,存储一个象素数据需要的周期总数为 17
一个粗糙的数据是30帧时,OV7640单象素的数据保持时间只有不到100ns。
以arm9的100Mhz的时钟频率计算,17个周期对于arm来说最少也要需要170ns。这还是最好的情况下。
我们假设你的增强型51可以在48Mhz的情况下和ARM9的相同频率具有同样的效率(实际上这是不可能的)。那么17周期的时间大概是 354ns。这需要将OV6620的输出降低到每秒5帧左右。再考虑到图象处理延时造成的丢帧,乐观的考虑最后可能每秒只有1~2帧的效率。
如果能加上一个FIFO的话情况能够有所改善。但是图象采集和处理最好的方法还是使用具有图象接口的芯片例如AT91RM9263。 学习学习~!~!
顶~!~!~! 加油啊 专一的做下去,前途一片大好! 路过 不错 顶 学习学习! 顶!!! 有意思么?做出来没实际意义,那不浪费时间吗?搞算法在vc或matlab里仿真就行了。 想从图像传感器上抓图,看这个帖子,
http://www.ourdev.cn/bbs/bbs_content.jsp?bbs_sn=3507464&bbs_page_no=1&search_mode=3&search_text=fifthboy&bbs_id=9999
用51做图像处理,来寻线很有挑战。
建议用51+FPGA来做,FPGA做图像的预处理,51对结果进行判别。 不知道楼主拿51+摄像头到底要做些什么的应用.如果只是要寻迹小车的话,那是肯定没有问题,我做过类似的应用,pic的8位机,11M的晶体,运算速度足够了,当然外围电路做了很多预处理.但如果要做复杂的图像处理或则比较,建议楼主还是放弃这个想法,毕竟图像处理和识别的算法摆在那里,就是需要那么多的计算量的,即使能勉强做出来,也达不到实用的效果.FPGA+51的方案,实际上已经偏离了楼主的初衷,成本也上去了. 谢谢 极限利用硬件资源,这个想法绝对不错,看完也给我提供了一点解决问题的小思路呢 加油,还是推荐用stc12c系列的
页:
[1]