先上图,我的这只小觅相机是长这个样子滴:
这个相机卖相倒是不错,只不过在现在这个时间点(2020年8月初),设计生产相机的公司“小觅智能”估计是凉了。原因就是他们家的官网和开发者网页都打不开了,而且连淘宝都是商品下架。唉,好惨,这样一来所有的技术支持基本就泡汤了,我好倒霉……现在也就只有github代码库和SDK手册两个链接管用了。这里记录一下:
slightech公司的github代码库
小觅相机SDK手册
刚拿到相机,首先当然是照着SDK手册的指导编译SDK。在这个过程中我遇到不少麻烦,但是最终都被解决了,这里记录下。
问题1: 运行指令“make init”时成功,但在运行“make install”时出现错误,卡在编译“synthetic.cc.o”目标文件处,根据报错提示,发现原因是当前电脑上的openCV是4.1的,版本过高,不配套,于是重装openCV3.4.2。
问题2: 编译一直到“make samples”都是正确的,但是运行时报错“openCV2.X不支持BM”。这个报错比较诡异,因为我刚刚才装了3.4.2的版本,怎么会是2.X?看了下SDK给的信息,检测到的openCV版本是2.4.11。于是我通用下面的指令查了一下,显示的是3.4.2。
pkg-config --modversion opencv
很奇怪,这说明刚刚安装的openCV3.4.2没错,但是SDK自动链接到2.4.11版本上去了,这或许说明电脑中同时存在两个版本的openCV.于是我又把所有OpenCV相关的内容删除,并把/usr/local下openCV相关的文件删除,最后上述指令得到的版本号又变成了2.4.9.1,而此时再运行samples下的例程则报错,显示未检测到openCV。很诡异的错误,总结一下就是:安装openCV3.4.2后SDK会使用OpenCV2.4.11,而将openCV从电脑中完全删除后,能检测到2.4.9.1的版本,却无法运行对openCV依赖的SDK。
后来偶然发现电脑同时安装的anaconda里有opencv,且版本正好是2.4.11。不过anaconda管理的都是python包,又怎么会和C++产生这种“莫名联动”呢。百思不得其解,最后无奈上大招解决:换一台空电脑,完全重装!
问题3: 例程get_imu_coorespondence需要USB3.0的接口才能获取数据,否则会报错“Timeout waiting for key frames. Please use USB 3.0 and not in virtual machine.(已放弃 核心已转储)”。
问题4: 例程get_depth_and_points需要安装pcl库,才能显示点云数据。
在遇到上述问题之后(实际上远不止上面罗列到的几个),想来想去,估计步步报错的原因很可能是电脑环境太乱了以至于经常发生环境冲突,于是搞了一台空白机,从操作系统开始安装。需要安装的各软件及其版本号分别如下:
Ubuntu18.04 + 自带GCC + openCV3.4.2(无需opencv_contrib) + 小觅相机SDK2.5.0 + 固件MYNTEYE-S1030-2.5.0.img
编译顺序参考上文给出的SDK使用手册链接即可:
sudo apt-get install git
git clone https://github.com/slightech/MYNT-EYE-S-SDK.git
cd MYNT-EYE-S-SDK # 进入路径
make init # 准备依赖
make install # 编译源码
make samples # 编译例程
现在就可以运行samples中的例程了,这些程序的可执行文件在/samples/_output/bin中,例如运行:
./samples/_output/bin/camera_with_junior_device_api
SDK就在屏幕上显示相机的光学和IR图像,并在terminal中显示IMU数据,如下图所示:
由图2可知,例程camera_with_junior_device_api用3个窗口分别显示左右光学图像、深度图像和disparity图像,同时另在terminal中显示IMU信息,包括时间戳、三轴加速度、三轴角速度和IMU温度等。
同理,运行例程:
./samples/_output/bin/record
即可得到相机的图像数据和IMU数据,并能指定图像帧率和IMU频率。得到的文件结构如下图所示:
由图3可知,例程record分别采集了光学、深度和disparity图像以及IMU运动数据(在文件motion.txt中),另外各类图像的时间戳等信息保存在各自文件夹内对应的文本文档中。
这里需要引入问题5,也就是时间戳的不对应。在前几次实验中,相机和IMU的时间戳相差极大,根本不像是读取字同一系统的时间,例如相机的时间戳往往有19-20位数字:
1844674405593564536
而IMU的时间戳的位数却很少,如:
24833652380
经过前后对比,逐渐确认一点:两种时间戳都是精确到微秒(us)的,也就是说从后面数第七位才是秒数。但问题是这两种时间戳都不是Unix时间戳,Unix时间戳以英国格林尼治时间1970年1月1日凌晨0时(北京时间1970年1月1日早晨8时)作为起始点,到2020年也不过10位秒数,即使精确到微秒也才16位。
为了解决这一问题,首先是查代码和SDK说明手册,查到如下如所示的内容:
图4(1)(2)表明,ImgData和ImuData的timestamp都是std::uint64_t类型数据,且都精确到us级,按理说形式上是应该相同的。
正当无解时,偶尔拔插了USB,再跑代码是时间戳居然就一致了,且位数更加少。经反复多次实验,发现时间戳应当是以相机上电(即USB接入电脑)时间为0秒开始计时,因此时间戳至少应为7位,而像之前所述的19-20位的时间戳是怎么得来的仍然无从知晓。
总地来说这款MYNTEYE-S1030-IR相机还是不错的,同时搭载了双目视觉、双通道深度相机和IMU传感器,并实现了相机的时间配准,同时SDK也比较完备,确实是一款新手友好型SLAM学习工具。
但是问题也是有不少的。第一,光学成像质量较差,例如从图2就能看出成像有明显的白色斑点(虽然并非每次都会出现,但是一旦出现,当次数据就算全都报废了);第二,成像较小,还是752*480的灰度图;第三,公司疑似倒闭,几乎没有技术支持(好惨)。
最后可能就是一个玄学问题:遇到问题记得拔插USB试试,万一它就好了呢/doge.jpg。