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