【转载】驱动调试常见问题_Camera

本文探讨了嵌入式系统中摄像头传感器可能出现的各种问题及其解决方案,包括I2C总线无响应、图像中出现水平条纹等问题,并分析了产生这些问题的根本原因。

转载自:http://blog.youkuaiyun.com/chi001/article/details/7360206

在嵌入式系统,如手机等平台上使用的Camera sensor通常是由类似I2C这样的总线进行寄存器控制,由CPU端的Controller提供所需的驱动时序,通常支持YUV和RGB等数据格式。有 的Sensor需要由CPU进行图像处理工作,有的Sensor自己会集成图像处理芯片,完成一些基础的图像处理工作,还有些高像素的Sensor甚至自 己完成JPEG的编码工作。因为硬件的多样性,我所遇到的问题可能和你的原因现象都不尽相同,分析内容仅供参考。
 
Sensor端I2C总线没有响应
  • 症状

    所有输入电压和时钟信号都正常,往I2C总线上写入读取寄存器 数据的命令后,sensor没有响应,没有数据从I2C总线上输出。

  • 分析
因为测量发现一切输出信号都正常,所以往往都会怀疑Sensor硬件存在问题,不过99% 的情况,实际的原因总是因为I2C总线的ID值没有设置对,导致设备不响应命令。据我的观察,每次一个新的工程师在调试Sensor的时候几乎都会遇上这 个问题。
之所以这么容易设置错误的原因,是因为通常Camera Sensor的Spec上所写的I2C ID号,还包含了最后一位读写方向位。而这一位在I2C总线的定义中,严格来说,不属于ID的一部分,所以Linux I2C的驱动API中的调用参数里的ID号,通常是不考虑这一位的,读写方向位会在具体的读写操作中,在寄存器中进行设置。 
  • 解决
 
    例如Spec上会写 读写寄存器操作 I2C ID 分别为 0x64和0x65,实际调用API时应该使用0x32作为该设备的I2C ID
图像中有不断变化的细密的水平条纹
  • 症状
    与荧光灯的频闪造成的大面积的滚动水平条纹不同,表现出来 的是一个像素高的水平条纹状躁点,位置不固定,数量比较多,而且随光线强弱有一定的变化
  • 分析
    因为设置某些sensor寄存器的时候,会影响到这些 水平条纹的颜色,所以基本上排除是在数据传输过程中板子对数据造成的干扰,也排除接触不良的可能性,应该是数据在sensor内部已经存在这些水平条纹。
    此外相同的初始化序列,相同的sensor,在厂商的 demo版上也没有发生这种情况,所以也基本排除软件的问题。
    最后,发现原先为了节省硬件成本,将sensor的两 个电压相同的模拟电和数字电由同一芯片输出供给,导致两者之间互相干扰,影响了sensor的正常工作
  • 解决
    将模拟电和数字电分离单独供电
 
图像上有固定的锯齿状垂直条纹
  • 症状
    图像上有明显的垂直条纹,全屏分布,非常细密,好像百 叶窗一样。
  • 分析

仔细看可以发觉该垂直条纹实际上是由于图像上相邻的 两两像素互相错位造成的锯齿状条纹

仔细分析spec可以看到,由于sensor是按字节送 出图像数据,在RGB565模式下,两个字节表示一个像素。而在我所使用的CPU的Camera控制器中,数据是按4个字节也就是一个字为单位处理的,由 于CPU这端是按LSB方式处理数据的,所以在一个字内部,未经调整的话,两个像素的顺序是颠倒过来的。也就是最终由DMA将数据送到内存的连续 buffer中时,像素的顺序是:像素2,像素1,像素4,像素3。。。

  • 解决
    用程序调整像素顺序,为了减少附加计算对CPU的负 担,可以将这一步操作合并在其它类似颜色转换或PACK模式转Planer模式等操作中。
 
大尺寸时容易出现图像错位
  • 症状
当sensor工作在最大分辨率的情况下时,图像容易 出现上下错位的现象。 
  • 分析
跟踪程序可以看到这时候CPU的Camera控制器 的FIFO缓存发生了溢出现象,也就是说DMA来不及将FIFO中的数据传送到内存中,该例中sensor在最大分辨率的情况下,输出数据的时钟工作在 24MHZ,理论上说,DMA应该是来得急传送数据的,但是可能因为内存带宽还会被其它设备如CPU占用,导致来不及写入内存,使得DMA没有最大负荷的 工作,所以来不及将FIFO中的数据读出,导致部分数据丢失,图像错位。
  • 解决
某些情况下,改变DMA传输的启动阙值可以解决该问 题,但是有些情况是无效的
考虑到最高分辨率仅在拍照的时候使用,预览的时候并不使 用该分辨率,所以,在不影响预览桢数的情况下,可以在拍照的一瞬间改变分辨率的同时,修改sensor的时钟频率,降低到一个不会导致FIFO溢出的频率
另外,在截获最高分辨率的图像的同时,尽量不执行其它的 内存相关操作。截获完图像马上切换回预览用的分辨率。通过这些办法,减少发生FIFO溢出的可能性。
读取到的数据显示出来的时候是花屏
  • 症状
读取到的数据显示出来的时候是花屏,但是明显是随着所 拍摄的对象的变化而变化的。 
  • 分析
具体来说,常见的情况包括:
显示的数据是完全的花屏,或者可以看出物体大致轮廓, 但颜色完全不对,例如一片绿色。这种情况往往是因为图像数据格式不匹配,例如没有处理YUV2RGB,YUV的各个分量采样顺序与软件计算的取值顺序不匹 配等。
如果花屏的具体表现是图像不断变换,没有规律,通常 有可能是数据接收的触发边沿有误,导致没有正确的接收数据。
另外有一次,花屏的时候,仔细观察花屏的图案,发现有部 分错位重复的图案的迹象。因此分析可能是Sensor的物理layout,其长宽比例与LCD刚好相反,仔细查看Spec得到确认。
  • 解决
具体情况具体处理了。

转载于:https://www.cnblogs.com/hao507/articles/2806607.html

chmod 777 /dev/ttyACM0 //给px4串口777权限 roslaunch realsense2_camera rs_camera.launch //打开realsense相机 roslaunch mavros px4.launch //运行px4的mavros结点,为了读取imu数据,传给vins进行位置估计 roslaunch vins fast_drone_250.launch //启动VINS rostopic echo /vins_fusion/imu_propagate //晃一晃,检查visn有没有飘 //上述步骤都是为了给规划器提供必要的话题和信息,由于我们更加关注规划部分的算法,就不详细查看上述这些步骤 //下面启动控制器 runctrl.launch //这一步主要是启动px4ctrl结点 -> 启动px4.ctrl结点 -> 将 vins_fusion/imu_propagate 映射为odmo -> 将 position_cmd 映射为cmd -> 载入参数文件 px4ctrl/config/ctrl_param_fpv.yaml sh shfiles/takeoff.sh //自动起飞 -> 向takeoff_land话题发布数据:takeoff_land_cmd:1 // px4.ctrl结点订阅到这个数据会跳转到自动起飞状态 roslaunch ego_planner single_run_in_exp.launch // 规划器部分的入口 -> 配置飞机id、地图大小、订阅vins_imu数据映射为odmo_topic -> 载入参数文件advanced_param_exp.xml、配置一些的参数 /*****************************规划器部分的入口**********************************/ -> advanced_param_exp.xml启动了ego_planner_node结点,命名为/drone_id_ego_planner_node //轨迹服务器,大致思路是将规划器产生的轨迹转化为控制指令 -> 启动ego_planner/traj_server 结点,命名为/drone_id_traj_server roslaunch ego_planner rviz.launch //打开rviz,订阅和发布一些话题,使规划可视化 ———————————————— 版权声明:本文为优快云博主「pjr11111」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.youkuaiyun.com/qq_41069236/article/details/130848882意思
最新发布
08-15
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值