5iMX宗旨:分享遥控模型兴趣爱好

5iMX.com 我爱模型 玩家论坛 ——专业遥控模型和无人机玩家论坛(玩模型就上我爱模型,创始于2003年)
楼主: c_nmusic
打印 上一主题 下一主题

共轴双桨自动驾驶直升机

[复制链接]
481
发表于 2008-9-18 11:09 | 只看该作者
争取达到“BIGDOG”的平衡水平:em15:

欢迎继续阅读楼主其他信息

482
 楼主| 发表于 2008-9-21 08:56 | 只看该作者
最近一直在和CMOS传感器芯片做斗争。

前几天是不知道为什么不正确,反正出来的图像就是不对了,完全和实景不搭边。
这两天时知道为什么不正确,芯片输出的速度太快,以至于ARM7来不及接收,结果造成画面数据混乱。

现在不知道怎么解决,除了外加芯片外。:em23:
483
发表于 2008-9-22 00:11 | 只看该作者
给你看一个产品
直升机平衡、位置保持装置。
可以做到松开遥控器飞机原地不动。

我有个问题
飞机处在不同高度时摄像头和地面距离不同。怎样保证位置测量的准确性?
产品网址
http://www.espritmodel.com/index.asp?PageAction=VIEWPROD&ProdID=5847

[ 本帖最后由 kortan 于 2008-9-22 00:12 编辑 ]

HeliCommand_1.jpg (6.95 KB, 下载次数: 45)

HeliCommand_1.jpg

helicommand3a.jpg (15.74 KB, 下载次数: 46)

helicommand3a.jpg

hc_schema_e.jpg (27.13 KB, 下载次数: 47)

hc_schema_e.jpg
484
 楼主| 发表于 2008-9-22 08:43 | 只看该作者
我也是根据这个HeliCommand3D的效果决定采用摄像头的。
那个距离问题并不大,因为这个漂移抑制,都不是完全做到让飞机好像钉死在那里的那种效果。
包括这个HeliCommand3D在内,还是会有小范围的漂移。

也就是说,离地面近,漂移可以检测出来的幅度比较小,有一点漂移马上就可以发现并修正。
离地面远,那么检测幅度会比较大,这样漂移幅度会比较大后才能发现。

我想可以用变焦镜头或者软件自动缩放来尽量减少这种影响吧,不过电路和程序就复杂了。
目前我还是打算先做成简单的,毕竟目前的需求就是1-2米高度就可以了。
485
 楼主| 发表于 2008-9-22 11:29 | 只看该作者
终于透过调试了5天的OV7640摄像头看到我的GP电池了。
真不容易啊,好多好多障碍啊。:em24:

下面再来看看这个颜色问题。

Image1.jpg (54.15 KB, 下载次数: 38)

Image1.jpg
486
发表于 2008-9-22 16:18 | 只看该作者
达达达达人
487
发表于 2008-9-22 17:05 | 只看该作者
原帖由 c_nmusic 于 2008-7-25 17:36 发表
花了一点时间,找了一个读取摄像头的VC代码,稍加修改了一下,自己能在画面上叠加一些信息。



目前的效果,可以画线,写文字,什么都可以做到。

http: ...

您好,可否分享一下在哪里找到的代码呢,当然能给改好的就好了,谢谢啦
叠加信息我们自己做,谢谢
488
 楼主| 发表于 2008-9-22 20:03 | 只看该作者
http://www.codeproject.com/KB/audio-video/DXCapture.aspx

这个是原始的。

附件是我修改后的,可以直接编译。因为是实验阶段的,所以代码非常乱。
而且这个版本有些BUG,在有的机器上图像没有在窗口里出现,而是在一个浮动的Active Movie窗口里出现了。而且也没有层叠的图画了。

解决的方法我提示一下,就是换用VMR9,然后非常关键的IFilterGraph要用IFilterGraph2,使用新的RenderEx函数就可以了。

还是留一点东西自己动手吧,呵呵,你们实在搞不定了我再告诉你们最后的答案。:em15:

DXCapture_demo.rar

48.79 KB, 下载次数: 77

489
 楼主| 发表于 2008-9-22 21:18 | 只看该作者
真的是非常郁闷,这个摄像头目前看来用到飞机上抑制漂移还有问题。

为了用最少的芯片,我直接把ARM7和摄像头接到了一起,然后降低摄像头的时钟速度来使用慢速的ARM7捕获摄像头的数据。
目前静态图片,虽然颜色不正常,但用来做比较没什么大问题。要不正常都不正常,反正程序不会去理会颜色好不好看。

可由于降低了频率,造成摄像头的曝光时间出了问题。直接影响就是如果摄像头在运动中拍照,那么照片上就会出现拖尾的效果,好像再拍夜景。
尝试关闭自动曝光换成手动,也不行。估计是时钟太低,以至于传输完一遍数据要花差不多1秒钟,只要在这1秒里有移动,那么画面就花了。

这个是无法接受的,看来现在只有上专用芯片这一条路了。

幸好我已经预见到了,定的4片OV528已经到了,用这个芯片不光可以取得快照,还可以直接照成JPG。配上SD卡就可以保存了。
看来下面又要研究芯片了,这个OV528我以前买过开发板,也许可以借鉴一些。
490
 楼主| 发表于 2008-9-23 19:56 | 只看该作者
成功修正颜色问题,原来芯片手册上说的RGB565格式,其实应该是GBR565。
我把颜色对调了,图像就正确了。

Image1.jpg (38.48 KB, 下载次数: 35)

Image1.jpg
491
 楼主| 发表于 2008-9-23 21:25 | 只看该作者
总结一下研究OV7640的一些经验,希望对后来人有些帮助。

1、OV7640的寄存器设置,不用管那个SCCB那些资料,写操作就是完全标准的I2C协议,用器件的I2C或者IO口模拟能用的I2C代码就可以了。唯一需要注意的是器件地址。芯片手册上说42是写,43是读。这个42、43是包含I2C7位地址+1位读写操作的16进制数,说白了OV7640的实际I2C地址就是0x21。OmniVision搞这种猫腻还不就是为了避免I2C的专利授权。
2、OV7640返回的RGB565格式的图像可以直接拿来显示,唯一需要注意的就是那个数据,并不是按照R5位,G6位,B5位的格式传输的。芯片手册上的那个Timeline写的有错误。根据这个出来的图像颜色不正确。正确的顺序是高位先5位G,然后6位B,最后5位R。
3、OV7640初始化。我只用了最最基本的几个寄存器。
        // 配置摄像头
        // 可用的RGB565配置,QVGA
        Delay(MCK/50);
        
        if (!I2CCameraConfig(0x14,0x4|(1<<5)))                        // 输出格式QVGA(320*240)
        {
                GoError();
        }
        
        Delay(MCK/50);

        if (!I2CCameraConfig(0x12,(1<<3)|(1<<2)))                        // RGB格式输出
        {
                GoError();
        }
        
        Delay(MCK/50);
               
        if (!I2CCameraConfig(0x1F,1|(0<<2)|(1<<4)))                // RGB565格式,默认RGB4:2:2格式
        {
                GoError();
        }
最后还有降低时钟频率。
        if (!I2CCameraConfig(0x11,0x19))        // 320*240 0x19正好符合52Mhz的ARM7的采样速度
        {
                GoError();
        }

然后就可以输出图像了。这个0x19是我用示波器量出来的,52Mhz或者更高主频的ARM7芯片在这个分频数下可以通过查询IO口的状态正确地根据PCLK上升沿读出图像数据。

这里有一点要注意:这个0x19只针对QVGA分辨率,如果对于VGA分辨率,示波器显示PCLK的上升沿后的正脉宽非常窄,ns级别,ARM7芯片是无法正确捕获到数据的。

4、关于一个HREF里PCLK的数量。这个芯片手册里有误,实际情况是,只要没有采用Raw-RGB格式输出数据,其它任何格式里,一个HREF里包含的PCLK都是宽度像素的2倍。也就是说都是2个BYTE表示一个象素点。这点在OV7660的芯片手册里写的非常清楚,实际情况也是如此。那些什么RGB4:2:2(GRB4:2:2)格式,不是说只有1个字节,里面G占4位,R和B各占2位。而是2个字节一起看,G占8位,R和B各占4位。这个和YUV4:2:2是一样的。只不过YUV4:2:2要求更多一些,要4个字节才能表示出2个像素。至于Raw-RGB到底传回了哪个像素的值?再简单不过,一个BYTE对应传感器上一个点,Google上搜一个bayer pattern,看看那个传感器的颜色分布就知道到底是哪个点了。

5、关于Bayer-pattern的解析。实际是只有采用Raw-RGB形势,才需要自己根据传感器的颜色阵列去推敲缺失的颜色。别的格式里都可以直接使用另外2种颜色。如果非要在RGB565下做Bayer-pattern解析也可以,就是感觉有些画蛇添足了。

下面给出我现在正常使用的QVGA的图像数据获取代码:
                // 等待VSYNC信号。
                while (!(AT91F_PIO_IsInputSet(AT91C_BASE_PIOA,VSYNC )));
               
                // VSYNC信号等到,表明新一帧图像开始。
                        
               
                nIndex = 0;
                pDataCachePointer = pDataCache;
               
                // 等到HREF,表明行数据开始。

                while (!(AT91F_PIO_IsInputSet(AT91C_BASE_PIOA,HREF )));                        
               
                AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED1 ) ;               
                for (i=0;i<240;i++)
                {
                        // 下面获取数据,QVGA 320像素宽,所以需要获得320*2=640个BYTE的数据。
                        for (j=0;j<320*2;j++)
                        {                        
                                while (!(AT91C_BASE_PIOA->PIO_PDSR & PCLK));
                                
                                AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0);
                                nData = AT91C_BASE_PIOB->PIO_PDSR;
                                AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0);
                                                               
                                nData = nData >> 22;
                                nData &= 0xFF;
                                *pDataCachePointer = (BYTE)nData;
                                pDataCachePointer++;
                                nIndex++;
                                
                                while ((AT91C_BASE_PIOA->PIO_PDSR & PCLK));
                        }
                        
                        // 这时候HREF应该为低了。
                        if (AT91F_PIO_IsInputSet(AT91C_BASE_PIOA,HREF))
                        {
                                // 出现错误,说明要么HREF提供了超过我们需要的像素信息,要么我们获取太慢,第二行的图像数据已经过来了。
                                while (1)
                                {
                                        AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0|LED1);//亮灯提示错误
                                }
                                
                                
                        }
                        while (!(AT91F_PIO_IsInputSet(AT91C_BASE_PIOA,HREF )));                        

                }
                AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED1) ;
               
我用的是AT91SAM7SE512的MCU,外扩一个16MB的SDRAM。晶振20Mhz,PLLRC的2个电容和1个电阻都是公板的配置,PLL分频DIV=5 MUL=25,算下来时钟是52Mhz。

下面是PC上显示图像部分里的RGB565转RGB888的代码。
COLORREF CSliderScanDlg::TranslateRGBData(BYTE nByte1,BYTE nByte2)
{
WORD wData = 0;
wData = (nByte1<<8)|nByte2;
int  R = 0;
int  G = 0;
int  B = 0;

// RGB565应该是 GBR565
G = (wData & 0xF800) >> 11;   
B = (wData & 0x07E0) >> 5;
R = (wData & 0x001F);

  //增大亮度
G <<= 3;
B <<= 2;
R <<= 3;
   return RGB(R,G,B); // 返回的图像颜色信息就可以直接在Windows的绘图API中使用了。
}

那个扫描起始列和行,都是默认配置。目前QVGA大约能做到1FPS吧,VGA没兴趣尝试了。
由于增加了OV7640的时钟分频数,所以曝光、白平衡什么的速度都很慢了,拍静态的还可以,动态的就别想了,肯定一片模糊。

这种方案毕竟简单,省却了一个专用压缩芯片或者一个CPLD。如果在设置好比较小的扫描行和列,速度还可以提高些。

别的那些寄存器我还没有完全搞懂有什么用,反正目前已经可以出正确图像了,大家有兴趣可以继续研究。OmniVision写的那么简单,真让人头疼。
我看的是Google上搜到的1.7版本的OV7640芯片手册,里面确实纠正了以前1.3版本的很多错误,有些错误是关键性置的,比如0x1F寄存器里的RGB565还是RGB555的输出格式选择。

希望对大家能有参考价值,如果各位发现错误,欢迎指出。

[ 本帖最后由 c_nmusic 于 2008-9-23 21:50 编辑 ]
492
发表于 2008-9-23 23:43 | 只看该作者
在不同高度下用摄像头检测位置会有很大的误差,位置检测不准确控制起来就十分困难了。因为你不光要知道向那个方向漂移,还要知道漂移了多少。

我有一篇英文的基于摄像头的直升机自动驾驶的论文。其中给出了用摄像头的数据估算出高度的方法。有了高度就能准确地估算出位置。比较复杂,没看太明白。如果有兴趣我发给你!
还有你有没有考虑过用GPS?到室外去飞。

佩服你的C/C++开发能力  给你推荐一个论坛。
http://www.ouravr.com/bbs/

其中的四轴飞行论坛是我见到的国内最专业的四轴飞行器论坛。
我最近一直在那里混,打算制作自己的四轴飞行器。
四轴飞行器最终可以做成自动驾驶的。我们已经有了一些框架。非常希望你能参与进来。
我的e-mail kortan@163.com  qq 1998585

[ 本帖最后由 kortan 于 2008-9-23 23:51 编辑 ]
493
 楼主| 发表于 2008-9-24 09:03 | 只看该作者

回复 494楼 的帖子

你说的问题我确实想到了,不过目前的需求就是在离地高度不高的情况下实现大致稳定的漂移控制。
而且目前只需要知道有没有飘,往那个方向飘了,所以目前应该可以适应。
距离地面的高度飞机上有光传感器来维持,预计1.5m就可以了。所以目前摄像头的数据不会差太多。

GPS我已经做了一块板,可惜天线部分有问题,内置的陶瓷天线收不到信号,郁闷。:em23:

四轴等我现在的摄像头部分差不多了,也要开始研究呢。准备买华科尔的UFO来当原形改造。

[ 本帖最后由 c_nmusic 于 2008-9-24 09:04 编辑 ]
494
 楼主| 发表于 2008-9-24 11:49 | 只看该作者
新的电路板到了,这回吸取了以前的教训,涉及到大电流的地方尽量宽布线。同时5V,3.3V,MCU部分的电路地线都分开,通过电感直接接到电池的地上。希望能通过这些措施减少地干扰。
整个电路板....黑呼呼的。:em15:

用了10多个电感,真是从一个极端走向另一个极端。


正面



背面,本来背面的电源和地线我都画了镀锡层,可制版商居然没给我做出来。:em17:
495
 楼主| 发表于 2008-9-24 13:19 | 只看该作者
以前无线模块干扰陀螺仪数据的问题,看起来果然是地线干扰造成的。
现在通过将无线模块的地线分开后,这个干扰也消失了。
我可以放心地发送数据了:em15:
496
发表于 2008-9-24 13:36 | 只看该作者
如果高度固定了相当于你知道漂移的位移了。应该能行。
不知道漂移的距离我认为是控制不住的。
497
 楼主| 发表于 2008-9-24 13:43 | 只看该作者
让实践来检验一下吧。:em15:
498
 楼主| 发表于 2008-9-24 16:18 | 只看该作者
新的驱动板看起来不错,那么多电感没有白用。飞机在最大马达情况下,无线数据接收依旧稳定,没有出现误码。:em24:
下面准备换上艾特的原装马达,看看拉力情况。ESKY的马达看起来力量不够大。
499
发表于 2008-9-27 01:17 | 只看该作者
从08年9月26日坚持看到08年9月27才把楼主的强帖看完。

真是强人,有耐心,有信心,有技术,更有。。。。。。

期待楼主能够成就所想!

保持关注!
500
 楼主| 发表于 2008-9-27 09:09 | 只看该作者
OV528的摄像头板已经送去做了,估计十一以后才能拿到了。
只有一个芯片手册,好在还有一个开发板可供参考。虽然做这个开发板的人极力否认用的是OV528,但芯片个个引脚的接法都和OV528完全一样,芯片大小什么的也完全一样。

下面继续研究一下软件部分,中控的启动有些不大稳定。然后就是一般接收机输出的PPM信号的解码,应该不会太复杂吧,舵机我已经可以驱动了,只是把信号由编码换成解码而已。

然后开始准备下一个针对四轴和450电直用的中控,准备把陀螺仪、加速度计、磁阻传感器、MCU都放到一起。做成和一般锁尾陀螺仪一样的一个小盒子,这样用起来就很方便了。现在的板子我测试了,想稳定装到450上有难度。顺便再加点弹簧,看看陀螺仪和加速度计能不能减少些震动。
您需要登录后才可以回帖 登录 | 我要加入

本版积分规则

关闭

【站内推荐】上一条 /1 下一条

快速回复 返回顶部 返回列表