Hi3516CV610开发板实战：从零搭建智能视觉监控系统

Hi3516CV610开发板实战从零搭建智能视觉监控系统这两年嵌入式视觉方向确实火尤其是海思芯片解禁之后Hi3516系列重新回到开发者视野。我手上这块Hi3516CV610开发板严格来说不算旗舰型号但用在智能视觉监控这个场景里性价比和可玩性都相当能打。这篇文章不打算做芯片参数的罗列想聊的是我实际从拿到板子、搭建交叉编译环境、点亮摄像头、跑通算法、再到把整个系统串起来的完整经历以及那些开发文档里不会明说但一定会踩的坑。如果你正准备用Hi3516CV610做视觉类项目或者手里正好有这块板子不知道从哪下手这篇文章至少能帮你省下一个星期的瞎折腾时间。1. 为什么选Hi3516CV610做智能视觉监控选型背后的真实考量先说结论这个芯片做监控类产品定位非常精准。它不像旗舰级Hi3559那样堆料堆到夸张也不像一些入门级芯片那样连基础ISP都做得磕磕绊绊。CV610的算力、编解码能力、外设接口和成本控制正好卡在智能视觉监控这个场景的甜区。我最早考虑过替代方案比如瑞芯微RV1126和晶晨A311D。RV1126在同价位段也是4K ISP加NPU的方案社区资料也不算少但实际调研下来发现两个问题一是4K分辨率的编码能力在高帧率下掉链子二是它的ISP对Sensor的适配范围没有海思系那么广很多国产Sensor型号需要自己调驱动。A311D的CPU算力确实强但那是偏盒端设备的思路纯视觉监控场景用A311D有点杀鸡用牛刀功耗和体积都扛不住。Hi3516CV610的优势在于这套组合很成熟双核Cortex-A55处理器用来跑业务逻辑和算法调度内置的智能加速引擎做视频分析ISP则负责把Sensor采集的RAW数据变成干净漂亮的YUV图像再配合H.265硬编码器完成码流输出。整个过程里CPU负载很低基本上就是做做控制流这正好符合监控设备7×24小时稳定运行的需求。从实际项目角度看智能视觉监控系统的核心链路无非就是图像采集、视频编码、智能分析、网络传输、云台控制这几块。CV610在这几条链路上都有对应的硬件加速模块不需要额外挂DSP或者协处理器。这点很重要因为开发板做原型容易真正做产品化的时候BOM成本和板上面积都是硬约束。我个人的建议是如果你的项目是固定点位监控、人员检测、区域入侵这类场景CV610完全够用。如果要做自动驾驶那种密集计算的任务或者同时跑多个重型神经网络模型那确实得换更高端的平台但那种项目跟CV610的定位本来就不是一回事。2. 环境搭建与系统烧录交叉编译链、SDK初始化、刷机全流程拿到开发板之后的第一件事不是插电开机而是先把开发环境搭好。很多新手上来就急着上电结果串口乱码、网口不通、SDK编译报错一顿折腾下来心态就崩了。其实这块板子的启动流程和编译流程是有固定套路的捋清楚之后再动手效率会高很多。2.1 交叉编译工具链的选择直接用SDK自带的不要自己折腾Hi3516CV610官方SDK里自带了一套交叉编译工具链路径一般在SDK包的toolchain目录下。我见过不少人非要用自己习惯的交叉编译器比如arm-buildroot-linux-uclibcgnueabihf之类结果链接出来的程序在板子上跑不了要么是一堆未定义引用要么是段错误。说实话这种问题查起来极其浪费时间。实际做法就是解压SDK后先把toolchain.tar.gz安装包展开找到bin目录下的arm-...-gcc工具链然后配置环境变量。我在Ubuntu 20.04上实测直接把toolchain/bin路径加到PATH引入到SDK环境变量里配置编译出来的程序就能正常在板上运行。export PATH/opt/hisi-linux/x86-arm/aarch64-himix100-linux/bin:$PATH export CROSS_COMPILEaarch64-himix100-linux- export CC${CROSS_COMPILE}gcc export CFLAGS-mcpucortex-a55 -marcharmv8.2-a这里有个细节值得注意CV610的CPU是Cortex-A55ARMv8.2-A架构编译选项里带上-marcharmv8.2-a能更好地发挥处理器特性。虽然不带也能跑但实测某些浮点密集的操作性能会差一截。2.2 固件烧录两种方式都试过推荐走网口烧录系统有两种路径一种是通过SD卡启动一种是通过网口使用Hitool工具烧写。SD卡方式适合在没有Wi-Fi和网线的纯离线环境里初始化但问题是后续调试还得频繁拔插SD卡太麻烦了。网口烧写方式是这样的先把开发板设置为烧录模式然后通过HiTool工具把U-Boot、内核、根文件系统一份份刷进Flash。这种方式的好处是只要网线插着后面每次改完内核或根文件系统都能快速刷新不用来回拆板子。我在第一次网口烧录时遇到一个问题HiTool提示升级失败检查了半天发现是PC的网卡IP和开发板的下载模式IP不在同一网段。HiTool默认给开发板分配的烧录IP是192.168.1.10PC端需要把网卡手动改成192.168.1.100之类的同网段静态IP子网掩码255.255.255.0关掉防火墙成功率才会高。烧录启动之后板子会自动跳到正常工作模式IP会回到U-Boot环境变量里定义的数值。2.3 根文件系统的坑挂载和权限比烧录本身更磨人文件系统这块官方给的默认rootfs是Buildroot编译出来的精简版基本的shell命令都有但没有包管理工具。也就是说你想在板子上直接apt install一个软件是不可能的只能自己交叉编译后拷贝进去。如果你之前用过其他开发板习惯了自己在板端操作yum或apt这块板子可能会让你不习惯。我的做法是在SDK里先用Buildroot把rootfs重新编了一版额外加上了openssh-server、tftp-hpa、nfs-common这些调试必备的组件这样后面远程调试和文件传输会舒服很多。另外板子挂载方式也值得优化。开发阶段我习惯通过网络挂载Ubuntu主机上的代码目录也就是在开发板上执行mount -t nfs命令把宿主机的目录直接挂载到板子上的/mnt/nfs这样编译出来的可执行文件不需要一遍遍scp直接在板端运行主机上的二进制文件即可调试效率直接提升一个档次。# 在开发板上执行 mount -t nfs -o nolock 192.168.1.100:/home/ubuntu/workspace/hi3516cv610 /mnt/nfs这里提示一下NFS挂载时一定记得加nolock参数否则内核版本较新或者内核配置里没开NLM支持的时候会报错。还有就是开发板上的NFS客户端工具是busybox版的mount参数写法跟PC上略有差异多试几次就摸透了。3. 视频采集链路Sensor驱动、ISP调试与图像质量优化智能视觉监控的底层是看得清。如果图像质量不过关后面不管跑什么算法都是空中楼阁。CV610的ISP能力我实际用下来是够用的关键是把Sensor驱动正确加载、把ISP参数调到合适的基准上。这一节把从点亮Sensor到出图再到调图的完整过程梳理一遍。3.1 Sensor点亮MIPI配置是第一个拦路虎开发板配套的Sensor一般是SC2335或IMX335这类千元级监控头。第一次点亮Sensor时最容易出问题的就是MIPI接口配置。CV610的MIPI RX支持多路输入但每一路Sensor对应的lane数、时钟频率、数据格式都需要在设备树里精准匹配。我用的Sensor是SC2335MIPI 2-laneRAW10格式。设备树里需要在sensor节点上指定compatible、reg地址一般走I2C地址0x30还要设置reset-gpio和pwdn-gpio两个引脚。很多传感器默认是power down状态如果引脚配置不对sensor的I2C通信能通但不出图这类问题光看内核日志很难定位得用示波器或逻辑分析仪去量Reset引脚的时序。点亮之后用cat /dev/video0这样的方式去验证出图是有问题的因为海思平台不像PC端有完整的V4L2驱动栈。更快的验证方式是用SDK里自带的sample程序比如sample_vio或sample_venc跑起来看终端打印的参数和码率再用海思提供的mpp工具抓一帧RAW数据检查。3.2 ISP调试白平衡、曝光、去噪的基础参数Sensor只是把光信号转成电信号真正决定图像质感的是ISP。CV610的ISP模块支持3A算法——自动曝光、自动白平衡、自动对焦但监控场景一般用固定焦距镜头自动对焦用不上所以主要调的是曝光和白平衡。SDK里提供了isp tuning工具链可以实时调整曝光时间、增益、色温增益矩阵等参数。我一般做法是先把Sensor对着一个标准色卡在白平衡模式下调整R/G/B增益让画面中性灰的位置RGB三通道数值尽量一致。然后把相机对着不同色温的光源分别在3000K、5000K、6500K下记录一组白平衡参数做成一个简单的色温查表。曝光策略上监控场景通常使用室内外混合光照自动曝光算法如果在明亮和暗光之间反复跳变监控画面就会有明显的闪烁感。我的做法是把曝光范围限制在一个合理的区间比如曝光时间从1ms到40ms增益从1x到8x宁可让暗部稍微暗一点也要保证画面过渡平滑。3.3 宽动态和降噪低照度场景的救命稻草夜间监控是刚需宽动态和降噪就显得尤其关键。CV610的ISP内置了WDR宽动态和3DNR三维降噪但默认参数偏保守直接使用效果很平庸。我调整后的经验是WDR的强度别拉满否则会产生鬼影尤其是画面里有快速运动的物体时。实际调试中WDR强度我一般设在中等偏上同时把暗部细节增强打开亮度映射曲线调成S形这样既保留高光区不过曝也能让阴影区看到细节。3DNR的时域降噪强度可以开高一点但空域降噪别开太狠否则画面边缘会有涂抹感。这两项调完之后夜间图像虽然比不了专业安防相机的效果但作为智能分析算法的输入源是完全合格的。3.4 编码参数H.265码率与帧率的权衡采集链路出来的YUV数据最终要交给VENC模块编码。监控场景里码流要推给后端平台所以码率和帧率直接决定了存储成本和网络占用。CV610的H.265硬件编码器支持主档我常用的配置是1080P25fpsCBR模式目标码率2Mbps。这里有个小经验CBR模式下如果场景太复杂码率还是会被撑爆导致后端拉流卡顿。所以我在编码参数里同时设置了VBV缓冲区的最大和最小码率把它控制在1.5Mbps到2.5Mbps之间既能保证画质不过分降低又能防止码率尖峰。VENC_ATTR_H264_S stH264Attr; stH264Attr.u32Profile 2; // High Profile stH264Attr.u32Level 41; stH264Attr.u32PicWidth 1920; stH264Attr.u32PicHeight 1080; stH264Attr.u32FrameRate 25; stH264Attr.u32BitRate 2048; stH264Attr.u32PicWidth 1920; stH264Attr.u32PicHeight 1080;如果项目对存储更敏感比如要求7×24小时录满一个月可以把帧率降到15fps码率降到1.2Mbps在动态不太大的场景里画质依然能接受。不高不低的帧率和码率组合是监控项目里面最容易省钱和最容易踩雷的地方。4. 智能分析在板端的落地人脸检测、区域入侵与算法调度智能视觉监控和传统监控的最大区别就是智。传统方案是摄像头只管录分析全部丢给后端服务器CV610这类芯片则可以把一部分AI推理放到前端做到告警事件在端侧即时触发只把告警片段上传到平台。这样不仅节省了带宽也降低了后端服务器的并发压力。4.1 板端AI推理框架的选型从NNIE到自有加速库Hi3516CV610的智能加速引擎跟早期Hi3516DV300上的NNIE不是同一个东西。CV610的AI引擎可以说是升级换代但我可以负责任地告诉各位SDK里大部分提供的示例代码和模型转换工具没有想象中那么傻瓜化。它的推理框架更接近海思后来在鸿蒙生态里推广的CANN那种思路需要手动管理内存、模型、任务的调度。我当时评估过两条路线一条是直接从海思的推理接口起步把Caffe或ONNX模型转成海思的wk格式然后通过MPP的AI接口做推理调度另一条是用第三方推理框架比如瑞芯微的RKNN生态那种思路在海思上肯定不行所以主要还是得吃透海思自家的工具。最终的落地方式是这样先用TensorFlow训练一个轻量人脸检测模型然后在PC端把模型转为ONNX格式再用SDK提供模型转换工具转成板上推理可加载的格式。转换过程中特别注意模型的输入尺寸和维度顺序海思加速引擎对输入layout要求是NCHWTensorFlow默认可能是NHWC这一点容易在转换时报错或推理结果异常。4.2 模型量化精度和速度怎么平衡嵌入式平台跑AI模型基本绕不开量化这一步。CV610的推理引擎支持INT8量化模型权重和激活值都会从FP32转成INT8。好处是计算速度快、内存占用低代价是精度可能下降尤其是某些敏感的目标类别。我看过很多新手在量化这一步翻车直接拿着训练好的FP32模型一把嗦量化结果精度掉了好几个点就开始怪芯片不行。其实量化是有技巧的。关键一步是准备校准数据集也就是从真实监控场景里采集的图像上截取有目标的画面用这些图像去统计每一层的激活值分布再决定量化的缩放比例。校准数据越贴近真实场景量化损失的精度越小。我在人脸检测模型上做量化时采集了大约500张白天场景和500张夜间场景的图像作为校准数据量化后模型精度只掉了不到2个百分点推理速度则从FP32的约150ms/帧提升到了INT8的约35ms/帧这个性能跑实时监控是绰绰有余的。4.3 多路视频流场景下的任务调度实际监控项目中一块开发板往往不只要处理一路视频。CV610支持多路Sensor输入比如接4个摄像头分别做4路的移动侦测或区域入侵告警。这种情况下板端的算法调度就很重要了。我的做法是用一个中心调度线程去轮询每一路通道的事件队列当某一帧检测到可疑目标后把该帧的图像数据和检测结果交给后处理线程做结构化分析同时触发告警逻辑。因为AI引擎本身是分时复用的4路同时频繁推理会互相抢占资源所以我给每一路分配了不同的推理优先级比如入口通道优先级最高仓库角落通道优先级最低。这里有个重要的架构取舍不是每一帧都需要做完整AI推理。我实际做的是先用VPSS的移动侦测或者区域变化检测做预处理只有当画面中有像素级变化超过阈值时才把这帧交给AI引擎做目标识别。这种两级检测策略在计算资源有限的情况下可以把整体CPU占用率从80%降到40%以下效果立竿见影。4.4 从检测到告警结构化数据怎么往上传AI推理的最终产出不只是画个框更重要的是生成结构化事件数据。我在板端封装了一个告警消息结构体包含摄像机ID、事件类型、时间戳、目标坐标、置信度分数再捆上一张抓拍图通过MQTT或者HTTP POST的方式推给后端平台。CV610板端跑一个轻量级MQTT客户端完全没压力我用的是开源的paho.mqtt.c交叉编译后放进rootfs配置好Broker地址和Topic就能实现告警消息的秒级上下行。抓拍图我选择JPEG格式用硬件编码器把YUV帧转成JPEG单张1080P抓拍图压缩到100KB以内传输效率很高。typedef struct { uint32_t u32ChannelId; uint32_t u32EventType; uint64_t u64Timestamp; float fConfidence; RECT_S stBBox; } MONITOR_ALERT_S;后端平台上订阅这个Topic收到告警后可以把结构化数据入库同时把抓拍图推给管理端或告警大屏整套联动逻辑就闭环了。5. 网络传输与流媒体推流RTSP/ONVIF/GB28181的方案对比与落地监控系统逃不开协议这关。开发阶段自己调试可以用裸流或者RTSP但真正要对接第三方平台、NVR、国标平台的时候协议选型就直接决定项目的交付周期。CV610的硬件编码器出的是标准H.265流所以封装和推流这部分主要工作在软件层。5.1 RTSP拉流本地调试最顺手的方式最简单的推流方式就是基于live555或者海思SDK自带的RTSP server把编码器输出的码流封装成RTSP流。开发板上跑一个RTSP服务器PC上用VLC或者ffplay拉流过程直观方便。我遇到的一个坑是H.265的RTSP流有些播放器默认解不了需要安装扩展编解码器或者用VLC最新版本。另外海思SDK里提供的RTSP server示例主要基于H.264如果直接用H.265封装需要改SDP里的编码参数名和Media Type字段改成H265和HEVC相关的值否则拉流黑屏。这个小问题卡过我一下午记录在案供各位参考。5.2 ONVIF Device Server对接NVR和后端平台的钥匙如果要跟市面上主流的NVR网络硬盘录像机或者VMS视频管理平台对接ONVIF协议几乎是绕不开的。CV610开发板上实现ONVIF的方式有两种用SDK里的ONVIF库——海思平台提供了一部分规范报文模板或者移植开源ONVIF协议栈比如gSOAP生成的ONVIF Server。我选了第二种方式因为初期用官方模板改起来遇到一些扩展字段还是得自行补齐。gSOAP的编译工作本身不复杂把ONVIF的WSDL文件导入gSOAP生成服务端框架然后填充Device Management和Media Service接口实现主要包括GetSystemDateAndTime、GetCapabilities、GetProfiles、GetStreamUri这些核心方法。ONVIF调试过程中最耗时间的是鉴权模式。ONVIF规范里有NONE、DIGEST两种鉴权方式NVR和VMS厂商的实现各不相同。我一开始全用DIGEST结果有些老款NVR死活握手失败后来改成NONE或DIGEST自动协商兼容性好了很多。说实话这块建议在正式交付前的兼容性测试阶段多准备几台常见品牌的NVR轮着测一遍。5.3 GB28181国标接入国内安防项目的硬门槛在国内做安防监控项目跟GB28181打交道几乎是必然的。用CV610对接国标平台的核心在于把板端的媒体流和信令流按照国标规定的SIP协议和RTP/RTCP推送到SIP服务器。我在项目里用的方案是把一个精简的GB28181客户端封装成独立进程负责SIP注册、心跳保活、Invite会话管理以及将H.265码流封装成PS流后通过RTP发送到国标平台。这个进程通过本地socket和主业务程序通信主程序把码流数据交给GB28181进程发送同时接收平台下发的云台控制指令转换后发给电机驱动模块。GB28181对接的坑主要出现在SIP域和设备ID编解码上。设备ID的规则是20位十进制数字前8位是行政区划码如果编码格式没对齐平台就会收不到设备注册或能收到但无法激活。还有一个更常见的坑是SIP消息里的Content-Type和Body格式国标要求的XML字段非常严格任何一个字段大小写不对平台就会拒绝请求。调试时最好在PC端跑Wireshark抓包跟标准报文一行行比对比对着规范文档盲改要快得多。5.4 推流稳定性丢帧策略与码率自适应网络传输里最让人头疼的就是弱网环境下的卡顿和带宽波动。CV610的编码器输出的码率比较平稳但后端网络一旦出现抖动如果推流进程不处理丢包很容易发生丢帧堆积造成延迟越来越大最后直接直到解码器超时断开。我的策略是在推流进程维护一个发送缓冲区当缓冲区堆积超过阈值时优先丢非关键帧只保留I帧和最近的P帧。这样后端的画面可能出现瞬时的花屏或跳变但连接不会断过一会儿网络恢复后会继续流畅播放。这种有损优先级的策略在实际的监控拉流场景里比完全等可靠传输要实用得多。另外需要重视的是RTP的时间戳和序列号。H.265的RTP封包遵循RFC 7798规范每个RTP包的timestamp和sequence必须单调递增如果有重复或乱序丢帧策略又没处理好接收端就会出现IAS误报或者花屏。这块我建议自己在板端做一次模拟弱网测试人为地丢包5%和10%观察接收端画面表现是否可接受而不是等真正上线再暴露问题。6. 端侧联调跑通一个完整的智能监控Demo前面讲的全是模块级的东西这一节把整个系统的联调流程走一遍。从模块到系统很多问题只有在真正组合到一起的时候才会冒出来。6.1 从Sensor到屏幕显示最小可用链路联调的第一步是最小链路——确保Sensor图像经过ISP后能正常显示。我用的是CV610开发板配套的HDMI或MIPI DSI输出接口先跑通VI→VPSS→VO这条通路在屏幕上看到实时预览画面。这个阶段最常见的现象是彩色条纹、画面偏移、颜色不对。多数情况都是MIPI时序配置问题或者VPSS裁剪区域没跟Sensor输出的分辨率对齐。我遇过一次特别隐蔽的问题在1080P模式下画面只有上半部分有图像下半部分全是绿色条纹排查了大半天最后发现是MIPI虚拟通道设错了Sensor的数据发到了VC0但ISP里配置读的是VC1。调试小技巧在海思MPP架构里可以先用sample_comm库里的公共函数简化VI和VPSS的通道配置参数集中在一个结构体里改出问题回退也快比手工写一堆MPP初始化代码效率高一个量级。6.2 各模块串起来VI→VPSS→VENC→AI→RTSP最小链路跑通之后再往链路上加VENC编码和RTSP推流。这一层联调的目的是验证编码器能否正确接收VPSS的输出帧并编码推流同时确认整个时序上没有帧率下降或丢帧。然后是接入AI检测。VPSS在每个通道出帧给VENC的同时可以通过用户态回调把同一帧拷贝一份给AI推理模块。这里要注意的是VPSS的绑定关系是决定系统拓扑的关键VENC和AI分别绑定同一条VPSS通道时要保证它们读的是同一时刻的帧否则会出现画面和检测结果错位的问题比如画面已经到下一帧了框还标在上一帧的目标上。幸运的是海思MPP提供了ChnList和GroupBind的接口可以让VENC和AI从同一个Group的不同通道里取帧两者使用不同的VideoBuffer互相不阻塞。实际帧率我测试下来1080P25fps的码流画质和AI检测帧率能稳定保持在20fps上下CPU占用率不足50%这个状态已经满足实际商用级监控设备的性能要求了。6.3 网络联调和延迟分析联调的最后一步是把推流和告警传到后端服务器然后在管理端验证端到端延迟。我用的测试方案是开发板通过有线网络推RTSP流到PCPC上用ffplay显示画面并记录从运动发生到显示屏出现告警弹窗的时间差。实测下来端到端延迟大约在200ms到400ms之间。这个数字在局域网内算正常水平延迟主要来自编码器缓冲、推流缓冲、网络抖动缓冲和解码显示缓冲。如果需要在广域网里保持低延迟那要考虑用WebRTC或者低延迟流媒体协议替换RTSP这是另一个话题了。联调过程中我踩过的最大坑是AI检测线程和编码线程的共享内存竞争。因为AI模块拿帧和VENC模块拿帧是独立线程如果忘记加锁或者加锁粒度不对会出现帧内容被编码器覆盖后AI才读到的情况检测结果错乱。解决办法是用海思SDK里的VIDEO_FRAME_INFO_S结构拷贝关键帧数据或者用引用计数管理帧内存确保AI推理时帧数据不被释放。7. 开发过程中的经验总结与调试技巧这块内容写到最后希望把我实际踩过坑以后沉淀下来的经验总结成一份可以直接用的清单给后来者避坑。开发节奏上我建议采用先跑通官方sample再做定制的策略。海思SDK里提供了大量sample代码比如sample_vio、sample_venc、sample_ai等每个都能单独编译运行。新手不要一开始就想着写自己的业务逻辑先把这些sample板子上跑一遍观察串口日志和画面效果理解MPP库把模块怎么串联起来再动手改业务层效率会几何级提升。调试工具上务必学会用海思的ncast和sys tools。ncast工具能让你在PC上直接查看板端画面的实时帧做一些简单的画质判断。sys工具则是用来查看MPP各模块实时状态的利器可以看到每个绑定的通道状态、缓冲区使用量以及是否有丢帧或阻塞事件。一套工具用熟很多疑难问题分分钟就能定位到模块而不是瞎猜。软件架构上我强烈建议把网络协议模块和视频业务模块拆开进程跑不要混在一个进程里。我最初图省事全塞一个进程结果RTSP推流的网络波动会拖慢AI检测线程导致告警迟滞。后来把网络模块和主业务进程用本地socket通信互相独立稳定性和可维护性都提升了很多。参考社区上这块芯片问世时间不算特别长海思官方社区和一些国内嵌入式论坛有部分资料。遇到SDK使用问题优先搜索海思官方的Release Note和FAQ文档里面记录了不少编译已知问题。第三方开源库如果能自行交叉编译尽量用ci版本带过来的稳定版本不要在开发板上临时make install一来可能缺少依赖二来也会污染rootfs让后续镜像制作变得杂乱。如果要做产品化我建议在开发板阶段就留意电源树和接口电平的设计因为开发板可用的GPIO有限真机外壳和传感器位置约束下可能要微调硬件设计。把这些考虑前移到开发阶段等到画PCB的时候就不会出现板子功能都验证过了但做不成产品的窘境。最后说一点个人体会Hi3516CV610这套平台最大的价值不是单个模块有多强而是海思把视频、编码、AI这些能力完整地封装在了一套SDK体系里开发者只要按它的抽象逻辑去组合就能快速搭出一个符合监控产品需求的原型机。对我来说这种不是从零发明轮子而是把轮子快速装上整车的开发体验才是这块板子最让人舒服的地方。如果你也正在调研或者已经拿到这块板子不妨从点亮Sensor那一刻开始享受它的上手过程。视觉监控这个方向眼睛看到的世界和芯片处理出来的世界确实是两回事把这两者之间的桥梁架起来本身就是件挺有成就感的事。