1. 為什么要在ROS里折騰GigE相機(jī)搞機(jī)器視覺和機(jī)器人開發(fā)的人繞不開兩個(gè)東西一個(gè)是ROS一個(gè)是工業(yè)相機(jī)。而工業(yè)相機(jī)里GigE接口的機(jī)器視覺相機(jī)又是最常見的一類。你可能會(huì)問USB相機(jī)插上就能用為什么非要用GigE答案其實(shí)不復(fù)雜——傳輸距離遠(yuǎn)、帶寬穩(wěn)定、支持多相機(jī)同步、工業(yè)現(xiàn)場抗干擾能力強(qiáng)。USB線超過5米信號就開始飄GigE網(wǎng)線隨便拉個(gè)幾十米沒問題而且可以通過交換機(jī)做多臺(tái)設(shè)備組網(wǎng)這在產(chǎn)線檢測、移動(dòng)機(jī)器人、多目視覺這些場景里幾乎是剛需。但問題也隨之而來。GigE相機(jī)廠商通常會(huì)提供自己的SDK比如某品牌相機(jī)有自己的API另一品牌又有另一套。你在ROS里想統(tǒng)一管理這些相機(jī)就得找一個(gè)中間層。ROS社區(qū)里最常用的方案是camera_aravis這個(gè)功能包它基于Aravis這個(gè)開源庫Aravis又是一套基于GenICam標(biāo)準(zhǔn)的通用相機(jī)控制庫。換句話說只要你的GigE相機(jī)支持GenICam協(xié)議絕大多數(shù)工業(yè)GigE相機(jī)都支持camera_aravis就能把它接進(jìn)ROS。接進(jìn)來之后ROS里拿到的是sensor_msgs/Image類型的圖像消息。這個(gè)格式在ROS生態(tài)里通用但如果你要做圖像處理——比如跑OpenCV的算法、做標(biāo)定、做深度學(xué)習(xí)推理——你最終需要的是cv::Mat。從sensor_msgs/Image到cv::Mat的轉(zhuǎn)換看起來只是幾行代碼的事但里面涉及的坑不少編碼格式對不對、步長怎么處理、內(nèi)存要不要拷貝、時(shí)間戳怎么對齊。這些問題不踩一遍你很難寫出穩(wěn)定可靠的代碼。這篇文章適合誰看如果你正在做機(jī)器人視覺項(xiàng)目手里有一臺(tái)GigE相機(jī)想在ROS環(huán)境下把它跑起來并且接入OpenCV做后續(xù)處理那這篇內(nèi)容就是給你寫的。我會(huì)從環(huán)境搭建、相機(jī)配置、圖像轉(zhuǎn)換、常見問題排查幾個(gè)維度把整個(gè)流程拆開講清楚。不管你是剛接觸ROS的新手還是已經(jīng)用過USB相機(jī)想升級到GigE的老手都能從中找到可以直接復(fù)用的操作步驟和避坑經(jīng)驗(yàn)。2. 整體方案設(shè)計(jì)與核心思路拆解2.1 為什么選camera_aravis而不是廠商自帶ROS包市面上很多工業(yè)相機(jī)廠商會(huì)提供自己的ROS驅(qū)動(dòng)包但你很快會(huì)發(fā)現(xiàn)幾個(gè)問題。第一廠商的ROS包往往只支持自家產(chǎn)品換一個(gè)品牌的相機(jī)就得換一套代碼項(xiàng)目里如果有多種相機(jī)就非常麻煩。第二廠商包的維護(hù)頻率參差不齊ROS版本一升級可能就不兼容了。第三有些廠商包是閉源的出了問題你沒法調(diào)試。camera_aravis的好處在于它是基于GenICam標(biāo)準(zhǔn)的通用方案。GenICam是工業(yè)相機(jī)領(lǐng)域的一個(gè)通用編程接口標(biāo)準(zhǔn)只要相機(jī)支持這個(gè)標(biāo)準(zhǔn)理論上就能被Aravis識(shí)別和控制。這意味著你不需要為每個(gè)品牌的相機(jī)寫不同的代碼一套流程通吃。而且camera_aravis是開源的代碼在GitHub上可以隨時(shí)查看和修改遇到問題也能自己排查。當(dāng)然camera_aravis也不是沒有缺點(diǎn)。它對某些廠商的私有功能支持有限比如一些特殊的觸發(fā)模式或者高級圖像處理功能可能還是得用廠商SDK。但對于大多數(shù)常規(guī)的圖像采集任務(wù)來說camera_aravis完全夠用。2.2 圖像轉(zhuǎn)換的核心邏輯從ROS消息到OpenCV矩陣ROS里的sensor_msgs/Image消息結(jié)構(gòu)其實(shí)很清晰主要包含以下幾個(gè)字段height、width、encoding、step、data。其中data是一個(gè)uint8[]數(shù)組存儲(chǔ)的是原始的圖像字節(jié)流。encoding告訴你圖像的編碼格式比如mono8、rgb8、bayer_rggb8等。step是一行圖像數(shù)據(jù)的字節(jié)數(shù)這個(gè)值不一定等于width乘以每個(gè)像素的字節(jié)數(shù)因?yàn)榭赡艽嬖谛袑R填充。cv::Mat的結(jié)構(gòu)也不復(fù)雜它有一個(gè)數(shù)據(jù)指針data有行數(shù)rows、列數(shù)cols、類型type還有一個(gè)關(guān)鍵屬性叫step表示每一行占用的字節(jié)數(shù)。你會(huì)發(fā)現(xiàn)這兩個(gè)結(jié)構(gòu)其實(shí)非常相似理論上可以直接把ROS消息的data指針交給cv::Mat來管理實(shí)現(xiàn)零拷貝轉(zhuǎn)換。但實(shí)際操作中零拷貝有它的風(fēng)險(xiǎn)。如果ROS消息在回調(diào)函數(shù)結(jié)束后被釋放而你的cv::Mat還在引用那塊內(nèi)存就會(huì)出現(xiàn)懸空指針。所以是選擇零拷貝還是深拷貝取決于你的使用場景。如果圖像只在回調(diào)函數(shù)內(nèi)部處理完就丟棄零拷貝沒問題如果需要把圖像存起來后續(xù)異步處理就必須深拷貝。2.3 編碼格式的映射關(guān)系這是很多人容易翻車的地方。ROS的encoding字段和OpenCV的type字段并不是一一對應(yīng)的需要手動(dòng)做映射。常見的對應(yīng)關(guān)系如下ROS encodingOpenCV type說明mono8CV_8UC1單通道灰度圖mono16CV_16UC116位灰度圖rgb8CV_8UC3紅綠藍(lán)三通道bgr8CV_8UC3藍(lán)綠紅三通道rgba8CV_8UC4帶透明通道bayer_rggb8CV_8UC1需要額外做去馬賽克處理特別注意rgb8和bgr8的區(qū)別。ROS默認(rèn)使用RGB順序而OpenCV默認(rèn)使用BGR順序。如果你直接把ROS的rgb8圖像當(dāng)成CV_8UC3來顯示顏色會(huì)不對——紅色和藍(lán)色會(huì)互換。解決辦法要么在轉(zhuǎn)換時(shí)用cvtColor做一次顏色空間轉(zhuǎn)換要么在相機(jī)配置階段就讓相機(jī)輸出BGR格式如果支持的話。Bayer格式更麻煩一些。很多工業(yè)相機(jī)為了節(jié)省帶寬原始輸出的是Bayer格式的裸數(shù)據(jù)每個(gè)像素只有一個(gè)顏色分量。你需要用cv::cvtColor配合COLOR_BayerRG2BGR之類的標(biāo)志來做去馬賽克。這一步如果忘了做圖像看起來會(huì)是灰度的而且有網(wǎng)格狀偽影。3. 環(huán)境搭建與相機(jī)接入實(shí)操3.1 安裝Aravis和camera_aravis整個(gè)鏈路是GigE相機(jī) → Aravis庫 → camera_aravis → ROS話題。所以第一步是裝Aravis。在Ubuntu環(huán)境下可以直接通過包管理器安裝sudo apt-get install libaravis-dev aravis-tools裝完之后可以用arv-tool-0.8版本號可能不同來掃描網(wǎng)絡(luò)上的GigE相機(jī)arv-tool-0.8 list如果能看到相機(jī)的廠商名和型號說明Aravis已經(jīng)能識(shí)別到設(shè)備了。這一步非常關(guān)鍵如果這里就看不到相機(jī)后面ROS里肯定也跑不起來?？床坏较鄼C(jī)通常有幾個(gè)原因網(wǎng)卡沒配置好、相機(jī)IP和主機(jī)不在同一網(wǎng)段、防火墻攔截了GVCP協(xié)議。GigE相機(jī)使用的是GVCP和GVSP協(xié)議前者用于控制后者用于圖像流傳輸都需要網(wǎng)絡(luò)暢通。接下來裝camera_aravis。推薦從源碼編譯因?yàn)閍pt里的版本可能比較舊cd ~/catkin_ws/src git clone https://github.com/AravisProject/camera_aravis.git cd .. catkin_make source devel/setup.bash編譯過程中如果報(bào)錯(cuò)找不到Aravis檢查一下libaravis-dev是否裝好以及pkg-config能不能找到aravis的路徑。3.2 配置網(wǎng)卡和相機(jī)IP這一步是GigE相機(jī)特有的USB相機(jī)不需要。你的主機(jī)上通常有兩塊網(wǎng)卡一塊連外網(wǎng)一塊連相機(jī)。相機(jī)的網(wǎng)段和主機(jī)的相機(jī)網(wǎng)段必須一致。比如相機(jī)默認(rèn)IP是192.168.1.100那你的主機(jī)網(wǎng)卡就得配成192.168.1.x。在Ubuntu里可以用nmcli或者直接改/etc/netplan/下的配置文件。我一般用命令行快速搞定sudo ip addr add 192.168.1.10/24 dev eth0 sudo ip link set eth0 up配完之后用ping測試一下能不能通。如果ping不通檢查網(wǎng)線、檢查相機(jī)供電、檢查網(wǎng)卡是否被識(shí)別。有些相機(jī)支持DHCP有些只支持靜態(tài)IP具體看廠商文檔。注意如果主機(jī)有多塊網(wǎng)卡確保ROS和Aravis走的是正確的網(wǎng)卡。有時(shí)候默認(rèn)路由會(huì)干擾GigE相機(jī)的發(fā)現(xiàn)過程可以通過設(shè)置環(huán)境變量ARAVIS_INTERFACE來指定網(wǎng)卡名稱。3.3 編寫camera_aravis的launch文件camera_aravis提供了一個(gè)通用的launch文件模板你需要根據(jù)自己的相機(jī)修改幾個(gè)關(guān)鍵參數(shù)。以下是一個(gè)典型的配置launch node namecamera pkgcamera_aravis typecam_node outputscreen param namecamera_info_url valuefile://$(find my_pkg)/config/camera_info.yaml/ param nameguid value/ param nameframe_id valuecamera_link/ param namepixel_format valuergb8/ param namewidth value1280/ param nameheight value960/ param nameframe_rate value30/ param nametrigger_mode value0/ /node /launch幾個(gè)參數(shù)需要重點(diǎn)說明。guid是相機(jī)的唯一標(biāo)識(shí)符如果留空camera_aravis會(huì)自動(dòng)選擇第一臺(tái)發(fā)現(xiàn)的相機(jī)。如果網(wǎng)絡(luò)上有多個(gè)相機(jī)就必須指定GUID否則可能連錯(cuò)設(shè)備。pixel_format決定了ROS話題里圖像的編碼格式建議設(shè)成rgb8或者mono8避免Bayer格式帶來的額外處理。trigger_mode設(shè)為0表示自由運(yùn)行模式相機(jī)自己按幀率出圖如果設(shè)為1或2就是外部觸發(fā)模式需要額外的硬件信號來觸發(fā)采集。啟動(dòng)之后用rostopic list應(yīng)該能看到/camera/image_raw和/camera/camera_info兩個(gè)話題。用rqt_image_view或者image_view可以可視化確認(rèn)圖像是否正常。4. 圖像格式轉(zhuǎn)換的完整實(shí)現(xiàn)4.1 基于cv_bridge的轉(zhuǎn)換方案ROS官方提供了一個(gè)叫cv_bridge的包專門用于sensor_msgs/Image和cv::Mat之間的轉(zhuǎn)換。這是最省事的方式代碼大概長這樣#include cv_bridge/cv_bridge.h #include sensor_msgs/Image.h #include opencv2/opencv.hpp void imageCallback(const sensor_msgs::ImageConstPtr msg) { cv_bridge::CvImagePtr cv_ptr; try { cv_ptr cv_bridge::toCvCopy(msg, sensor_msgs::image_encodings::BGR8); } catch (cv_bridge::Exception e) { ROS_ERROR(cv_bridge exception: %s, e.what()); return; } cv::Mat image cv_ptr-image; cv::imshow(view, image); cv::waitKey(1); }toCvCopy會(huì)做一次深拷貝并且可以順便做編碼轉(zhuǎn)換。比如原始消息是rgb8你指定目標(biāo)編碼為BGR8cv_bridge會(huì)自動(dòng)幫你做顏色通道交換。這個(gè)方案的好處是簡單、安全不用擔(dān)心內(nèi)存生命周期問題。缺點(diǎn)是每次回調(diào)都有一次內(nèi)存拷貝對于高分辨率高幀率的場景CPU占用會(huì)比較高。如果你追求性能可以用toCvShare來做零拷貝cv_bridge::CvImageConstPtr cv_ptr cv_bridge::toCvShare(msg, sensor_msgs::image_encodings::BGR8);但注意toCvShare返回的是const指針你不能修改圖像數(shù)據(jù)。而且如果做了編碼轉(zhuǎn)換比如RGB到BGRcv_bridge內(nèi)部還是會(huì)分配新內(nèi)存零拷貝只在編碼一致時(shí)有效。4.2 手動(dòng)轉(zhuǎn)換更靈活但更容易踩坑有些場景下你不想依賴cv_bridge比如在嵌入式平臺(tái)上想減少依賴或者想精確控制內(nèi)存分配。這時(shí)候可以手動(dòng)轉(zhuǎn)換cv::Mat rosImageToMat(const sensor_msgs::Image msg) { cv::Mat mat; if (msg.encoding mono8) { mat cv::Mat(msg.height, msg.width, CV_8UC1, const_castuint8_t*(msg.data[0]), msg.step); } else if (msg.encoding rgb8) { mat cv::Mat(msg.height, msg.width, CV_8UC3, const_castuint8_t*(msg.data[0]), msg.step); cv::cvtColor(mat, mat, cv::COLOR_RGB2BGR); } else if (msg.encoding bgr8) { mat cv::Mat(msg.height, msg.width, CV_8UC3, const_castuint8_t*(msg.data[0]), msg.step); } else if (msg.encoding mono16) { mat cv::Mat(msg.height, msg.width, CV_16UC1, const_castuint8_t*(msg.data[0]), msg.step); } else { ROS_WARN(Unsupported encoding: %s, msg.encoding.c_str()); } return mat; }這段代碼有幾個(gè)關(guān)鍵點(diǎn)。第一msg.step必須傳給cv::Mat的構(gòu)造函數(shù)不能省略。如果你用width * channels來算步長遇到行對齊填充的情況就會(huì)出錯(cuò)圖像會(huì)出現(xiàn)斜條紋。第二const_cast是因?yàn)镽OS消息的data是const的但cv::Mat構(gòu)造函數(shù)需要非const指針。如果你不打算修改數(shù)據(jù)這樣做是安全的如果要修改必須先clone()一份。第三RGB到BGR的轉(zhuǎn)換會(huì)觸發(fā)一次內(nèi)存分配和數(shù)據(jù)拷貝如果你不需要顏色正確可以跳過這一步。4.3 Bayer格式的特殊處理如果你的相機(jī)輸出的是Bayer格式轉(zhuǎn)換流程會(huì)多一步。假設(shè)編碼是bayer_rggb8cv::Mat bayer(msg.height, msg.width, CV_8UC1, const_castuint8_t*(msg.data[0]), msg.step); cv::Mat color; cv::cvtColor(bayer, color, cv::COLOR_BayerRG2BGR);不同的Bayer排列方式對應(yīng)不同的轉(zhuǎn)換標(biāo)志COLOR_BayerRG2BGR、COLOR_BayerBG2BGR、COLOR_BayerGR2BGR、COLOR_BayerGB2BGR。用錯(cuò)了標(biāo)志顏色會(huì)偏。怎么知道該用哪個(gè)看相機(jī)文檔或者在ROS話題里用rostopic echo /camera/image_raw/encoding看一下實(shí)際的編碼字符串。實(shí)操心得Bayer去馬賽克是一個(gè)計(jì)算密集型操作在低功耗平臺(tái)上可能成為瓶頸。如果相機(jī)支持硬件去馬賽克盡量在相機(jī)端就輸出RGB或BGR格式把這一步省掉。5. 常見問題與排查技巧實(shí)錄5.1 相機(jī)連不上或頻繁掉線這是GigE相機(jī)最常見的問題。表現(xiàn)是arv-tool list能看到相機(jī)但啟動(dòng)ROS節(jié)點(diǎn)后報(bào)超時(shí)錯(cuò)誤或者圖像流斷斷續(xù)續(xù)。排查思路按以下順序來先確認(rèn)網(wǎng)線質(zhì)量工業(yè)現(xiàn)場電磁干擾大劣質(zhì)網(wǎng)線會(huì)導(dǎo)致丟包再檢查網(wǎng)卡是否開啟了巨幀Jumbo FrameGigE相機(jī)通常建議把MTU設(shè)成9000可以減少CPU中斷次數(shù)然后看相機(jī)的包大小Packet Size設(shè)置如果設(shè)得太大而網(wǎng)絡(luò)不支持就會(huì)丟包。可以在Aravis的屬性里把GevSCPSPacketSize調(diào)小試試。還有一個(gè)容易被忽略的點(diǎn)是網(wǎng)卡的電源管理。有些主板默認(rèn)開啟網(wǎng)卡節(jié)能模式在高負(fù)載下會(huì)降頻導(dǎo)致丟包。可以用ethtool關(guān)掉sudo ethtool -s eth0 wol d sudo ethtool -K eth0 gso off gro off tso off5.2 圖像顏色不對或出現(xiàn)斜條紋顏色不對通常是RGB和BGR搞混了。檢查你的轉(zhuǎn)換代碼確認(rèn)ROS消息的編碼和OpenCV的通道順序是否匹配。如果用的是cv_bridge確認(rèn)toCvCopy的第二個(gè)參數(shù)設(shè)的是BGR8還是RGB8。斜條紋幾乎可以肯定是step的問題。ROS消息的step字段表示一行數(shù)據(jù)的字節(jié)數(shù)它可能大于width * channels。如果你在構(gòu)造cv::Mat時(shí)沒有傳stepOpenCV會(huì)默認(rèn)用width * channels來計(jì)算導(dǎo)致行與行之間錯(cuò)位。解決辦法就是在cv::Mat構(gòu)造函數(shù)里顯式傳入msg.step。5.3 幀率上不去或延遲越來越大幀率上不去有幾個(gè)可能的原因。一是曝光時(shí)間設(shè)得太長相機(jī)在弱光環(huán)境下自動(dòng)增加曝光導(dǎo)致幀率下降?？梢允謩?dòng)把曝光時(shí)間固定在一個(gè)合理值。二是圖像分辨率太高帶寬不夠。GigE的理論帶寬是1Gbps實(shí)際有效帶寬大概在100MB/s左右。1280x960的RGB圖像一幀是3.5MB30幀就是105MB/s已經(jīng)接近極限了。要么降分辨率要么降幀率要么換萬兆網(wǎng)卡。延遲越來越大通常是消息隊(duì)列積壓導(dǎo)致的。ROS默認(rèn)的隊(duì)列大小是1但如果你的回調(diào)函數(shù)處理太慢消息就會(huì)堆積?？梢栽谟嗛啎r(shí)設(shè)置queue_size并且確保回調(diào)函數(shù)里不做耗時(shí)操作。如果確實(shí)需要耗時(shí)處理把圖像拷貝出來放到另一個(gè)線程里做。5.4 常見問題速查表現(xiàn)象可能原因解決方法arv-tool看不到相機(jī)網(wǎng)段不對/防火墻攔截檢查IP配置關(guān)閉防火墻ROS節(jié)點(diǎn)啟動(dòng)報(bào)超時(shí)網(wǎng)卡未指定/相機(jī)被占用設(shè)置ARAVIS_INTERFACE關(guān)閉其他占用程序圖像顏色異常RGB/BGR混淆檢查轉(zhuǎn)換代碼的編碼參數(shù)圖像有斜條紋step未正確傳遞cv::Mat構(gòu)造函數(shù)傳入msg.step幀率低于預(yù)期曝光過長/帶寬不足固定曝光時(shí)間降低分辨率或幀率圖像延遲累積回調(diào)處理太慢減小隊(duì)列異步處理Bayer圖像發(fā)灰未做去馬賽克用cvtColor做Bayer轉(zhuǎn)換避坑技巧在項(xiàng)目初期就把相機(jī)的曝光、增益、白平衡全部手動(dòng)固定不要用自動(dòng)模式。自動(dòng)模式在光照變化時(shí)會(huì)導(dǎo)致圖像亮度波動(dòng)影響后續(xù)算法的穩(wěn)定性。而且自動(dòng)模式的參數(shù)調(diào)整會(huì)占用相機(jī)內(nèi)部處理時(shí)間可能影響幀率。6. 性能優(yōu)化與進(jìn)階技巧6.1 零拷貝轉(zhuǎn)換的正確打開方式前面提到零拷貝有懸空指針的風(fēng)險(xiǎn)但如果你確實(shí)需要極致性能可以這樣做在回調(diào)函數(shù)內(nèi)部完成所有處理不把cv::Mat傳到回調(diào)外面。這樣ROS消息的生命周期覆蓋了整個(gè)處理過程不會(huì)出現(xiàn)懸空。void imageCallback(const sensor_msgs::ImageConstPtr msg) { cv::Mat image(msg-height, msg-width, CV_8UC3, const_castuint8_t*(msg-data[0]), msg-step); // 在這里完成所有處理不要把image傳出去 cv::Mat gray; cv::cvtColor(image, gray, cv::COLOR_BGR2GRAY); // ... 后續(xù)處理 }如果你需要把圖像存下來異步處理那就老老實(shí)實(shí)clone()一份。內(nèi)存拷貝的代價(jià)比起調(diào)試懸空指針的痛苦完全不值一提。6.2 多相機(jī)同步采集GigE的一個(gè)優(yōu)勢是支持多相機(jī)同步。在camera_aravis里你可以啟動(dòng)多個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)綁定不同的GUID。如果要硬件同步需要相機(jī)支持觸發(fā)輸入輸出用一根網(wǎng)線做菊花鏈或者用外部觸發(fā)源同時(shí)觸發(fā)所有相機(jī)。軟件層面可以用ROS的message_filters來做時(shí)間同步#include message_filters/subscriber.h #include message_filters/synchronizer.h #include message_filters/sync_policies/approximate_time.h typedef message_filters::sync_policies::ApproximateTime sensor_msgs::Image, sensor_msgs::Image SyncPolicy; message_filters::Subscribersensor_msgs::Image sub1(nh, /camera1/image_raw, 1); message_filters::Subscribersensor_msgs::Image sub2(nh, /camera2/image_raw, 1); message_filters::SynchronizerSyncPolicy sync(SyncPolicy(10), sub1, sub2); sync.registerCallback(boost::bind(callback, _1, _2));ApproximateTime策略允許時(shí)間戳有一定偏差適合無法做到硬同步的場景。如果相機(jī)支持硬觸發(fā)時(shí)間戳?xí)浅＝咏部梢杂肊xactTime策略。6.3 圖像壓縮與傳輸優(yōu)化如果你需要把圖像通過網(wǎng)絡(luò)傳輸?shù)搅硪慌_(tái)機(jī)器原始圖像會(huì)占用大量帶寬?？梢杂胕mage_transport的壓縮插件把圖像編碼成JPEG或PNG再傳輸node namerepublish pkgimage_transport typerepublish argsraw in:/camera/image_raw compressed out:/camera/image_compressed/接收端用compressed話題訂閱cv_bridge會(huì)自動(dòng)解壓。JPEG壓縮比可以調(diào)到80左右肉眼幾乎看不出差別但帶寬能省十倍以上。不過壓縮和解壓都有CPU開銷在低功耗平臺(tái)上要權(quán)衡。6.4 時(shí)間戳對齊與標(biāo)定做視覺SLAM或者多傳感器融合時(shí)圖像的時(shí)間戳必須和其他傳感器對齊。camera_aravis默認(rèn)使用相機(jī)內(nèi)部時(shí)間戳但相機(jī)時(shí)鐘和主機(jī)時(shí)鐘可能有偏差?？梢栽趌aunch文件里設(shè)置use_ros_time參數(shù)讓ROS用主機(jī)時(shí)間給圖像打時(shí)間戳。但這樣會(huì)引入網(wǎng)絡(luò)傳輸延遲對于高精度應(yīng)用最好還是做時(shí)鐘同步。相機(jī)標(biāo)定用ROS官方的camera_calibration包就行。準(zhǔn)備一塊棋盤格標(biāo)定板在相機(jī)前不同角度晃動(dòng)采集足夠多的樣本。標(biāo)定結(jié)果會(huì)生成一個(gè)YAML文件里面包含內(nèi)參矩陣和畸變系數(shù)。把這個(gè)文件路徑填到launch文件的camera_info_url參數(shù)里后續(xù)做去畸變或者三維重建時(shí)就能直接用。實(shí)操心得標(biāo)定的時(shí)候盡量讓標(biāo)定板覆蓋圖像的各個(gè)區(qū)域特別是邊緣部分。很多人只在圖像中心晃導(dǎo)致邊緣畸變系數(shù)估計(jì)不準(zhǔn)。另外標(biāo)定時(shí)的光照條件要和實(shí)際使用場景接近否則曝光差異會(huì)影響角點(diǎn)檢測的精度。7. 從采集到處理的完整代碼框架把前面所有內(nèi)容串起來一個(gè)完整的節(jié)點(diǎn)大概長這樣#include ros/ros.h #include sensor_msgs/Image.h #include cv_bridge/cv_bridge.h #include opencv2/opencv.hpp class ImageProcessor { public: ImageProcessor() : it_(nh_) { sub_ it_.subscribe(/camera/image_raw, 1, ImageProcessor::imageCallback, this); } void imageCallback(const sensor_msgs::ImageConstPtr msg) { cv_bridge::CvImagePtr cv_ptr; try { cv_ptr cv_bridge::toCvCopy(msg, sensor_msgs::image_encodings::BGR8); } catch (cv_bridge::Exception e) { ROS_ERROR(cv_bridge exception: %s, e.what()); return; } cv::Mat image cv_ptr-image; processImage(image); } void processImage(cv::Mat image) { cv::Mat gray, edges; cv::cvtColor(image, gray, cv::COLOR_BGR2GRAY); cv::Canny(gray, edges, 50, 150); cv::imshow(edges, edges); cv::waitKey(1); } private: ros::NodeHandle nh_; image_transport::ImageTransport it_; image_transport::Subscriber sub_; }; int main(int argc, char** argv) { ros::init(argc, argv, image_processor); ImageProcessor processor; ros::spin(); return 0; }對應(yīng)的CMakeLists.txt需要鏈接cv_bridge、image_transport和OpenCVfind_package(catkin REQUIRED COMPONENTS roscpp sensor_msgs cv_bridge image_transport ) find_package(OpenCV REQUIRED) include_directories( ${catkin_INCLUDE_DIRS} ${OpenCV_INCLUDE_DIRS} ) add_executable(image_processor src/image_processor.cpp) target_link_libraries(image_processor ${catkin_LIBRARIES} ${OpenCV_LIBS} )這個(gè)框架可以直接拿去用把processImage里的內(nèi)容換成你自己的算法就行。如果你用的是Pythoncv_bridge也有對應(yīng)的Python接口轉(zhuǎn)換邏輯是一樣的。8. 一些踩過的坑和實(shí)際體會(huì)最后分享幾個(gè)我在實(shí)際項(xiàng)目里踩過的坑都是文檔里不會(huì)寫的。第一個(gè)坑是相機(jī)的GUID問題。有一次項(xiàng)目現(xiàn)場有兩臺(tái)同型號相機(jī)我launch文件里沒指定GUID結(jié)果每次啟動(dòng)連上的相機(jī)都是隨機(jī)的。調(diào)試了半天才發(fā)現(xiàn)是這個(gè)問題。后來學(xué)乖了每臺(tái)相機(jī)的GUID都記下來在launch文件里寫死。第二個(gè)坑是網(wǎng)卡的巨幀設(shè)置。巨幀能提升吞吐量但需要交換機(jī)和網(wǎng)卡都支持。有一次現(xiàn)場用的交換機(jī)不支持巨幀我這邊網(wǎng)卡開了巨幀結(jié)果圖像流全是花屏。排查了很久才定位到這個(gè)問題。所以開巨幀之前先確認(rèn)整條鏈路都支持。第三個(gè)坑是cv_bridge的編碼轉(zhuǎn)換。有一次相機(jī)輸出的是yuv422格式cv_bridge不支持直接轉(zhuǎn)BGR會(huì)拋異常。解決辦法是先用toCvCopy轉(zhuǎn)成mono8或者原始格式再手動(dòng)做YUV到BGR的轉(zhuǎn)換。這個(gè)格式在工業(yè)相機(jī)里不算少見遇到的時(shí)候不要慌查一下YUV的排列方式手動(dòng)寫轉(zhuǎn)換代碼就行。第四個(gè)坑是時(shí)間戳。camera_aravis默認(rèn)用相機(jī)時(shí)間戳但相機(jī)的時(shí)間戳是從相機(jī)上電開始計(jì)數(shù)的和ROS的ros::Time::now()完全不在一個(gè)量級。如果你用message_filters做同步會(huì)發(fā)現(xiàn)怎么都對不上。解決辦法是在launch文件里把use_ros_time設(shè)為true讓ROS用主機(jī)時(shí)間重新打時(shí)間戳。這些經(jīng)驗(yàn)說到底就是一句話GigE相機(jī)在ROS里的集成難點(diǎn)不在代碼本身而在環(huán)境配置和細(xì)節(jié)調(diào)試。代碼框架是固定的但每個(gè)現(xiàn)場的網(wǎng)絡(luò)環(huán)境、相機(jī)型號、光照條件都不一樣需要根據(jù)實(shí)際情況靈活調(diào)整。把上面這些流程走一遍大部分問題都能覆蓋到。剩下的就是多動(dòng)手、多試錯(cuò)踩過的坑多了自然就熟練了。