快一年沒用ROS了，不過儘管如此，如果有人問之前寫的ROS博客問題，還是會很仔細得回答。結合這些問題，加上之前的一些經歷和經驗，進行一個簡單的整理和總結。
目錄
1 機器人
機器人的研究在各大實驗室和研究所裏面一直都是一個很火的話題，所涉及到的細分領域也非常多。它前沿、高端、有挑戰性，而且經常是多學科的結合，更容易碰撞出創新的火花。後來公司開始不斷投入去開發並做成產品上市我覺得跟兩個因素有關：
一、2015年兩會提出了“中國製造2025”的概念，以提高製造業的智能性。緊接着，2015年3月31日，“OFweek 2015中國機器人產業高峯論壇”又在深圳成功舉辦，以推動機器人事業的進一步發展。機器人是製造業的重要力量，因此大量的公司成立了機器人研究院，大量的機器人創業公司湧現。
二、ROS在海內外的大力推廣，ROS的出現確實減少了做機器人的很多障礙。而且由於它的開源，有大量的算法、驅動程序在ROS社區（wiki.ros，GitHub等）可以找到，幾乎成了做機器人的優秀範本。所以對於開發者而言，可以更關注於想要實現的東西；對於研究人員而言，可以更好地去優化算法。下面着重講用ROS的開發心得。
2 ROS
2.1 ROS初探
剛開始入手ROS的時候確認有點麻煩，第一它運行在Ubuntu環境。雖說現在ROS2.0可以在Windows下運行了（ROS探索總結（五十五）—— Windows版ROS安裝試用），不過還是用Ubuntu比較原生態，而且Ubuntu系統免費，實時性也相對高點。可能有的人一看linux編程就望而卻步，其一沒Windows下的可視化操作方便，目錄結構和文件屬性也很有差別；其二沒有宇宙第一強IDE Visual Studio，很多斷點調試都非常麻煩。實際上關於Ubuntu系統的安裝教程網上有很多，實在不行可以在Windows下安裝虛擬機。關於操作系統的使用，大多是以命令行或者腳本的形式進行，《鳥哥的linux私房菜》這本書可以看看。常用指令主要就那些（應該不會有太多人再去深究指令背後的含義吧，這個就涉及到linux內核了，越挖越深可能偏離方向了），再不懂的指令邊遇到邊查邊學也很快。其實對於軟件開發人員，能寫腳本是一項很重要的技能，而且老外都非常喜歡用指令去操作，而且我看到很多大廠的開發在Windows下也做了很多腳本工具，進行編譯、調試、測試等，它能批處理很多東西，減少很多重複性的事情，所以儘可能得學會多用指令或者腳本去操作。
安裝並大致瞭解完linux操作系統，就可以安裝ROS了，安裝指引參見http://wiki.ros.org/ROS/Installation，基本也是依葫蘆畫瓢地操作。不過在使用ROS前，可以在 ROS官網上看看，瞭解一下ROS大概是怎麼一回事。或者參考古月居的博客，他的博客有對ROS的系統講解，以及很多技術分享。爲了更快得安裝ROS，我們一般會切換至國內的鏡像源比如清華大學的。ROS的安裝大概需要半個小時左右，安裝完後便可以開始ROS之旅了。不過在開始之前，我們還可以再細想一些問題，比如/etc/apt/sources.list是幹啥的，下載的安裝包都去哪了？/etc/apt/sources.list 是包管理工具 apt 所用的記錄軟件包倉庫位置的配置文件，同樣的還有位於 /etc/apt/sources.list.d/*.list 的各文件。通過apt-get命令下載的軟件包，會放在/var/cache/apt/archives 目錄下。而deb格式是Debian系統(包含Debian和Ubuntu)專屬安裝包格式，配合APT軟件管理系統，是Linux下非常流行的一種安裝包。瞭解這個對後面Linux下的軟件發佈和部署會有一定幫忙。
2.2 ROS的簡單開發及其理解
ROS的初級之旅主要從ROS tutorial開始，幾乎也是依葫蘆畫瓢似的創建消息，廣播話題，寫服務等。市面上大部分教材、博客也是以這裏爲例並加以拓展。關於代碼的編寫，有太多方式，最簡單粗暴的當然是用記事本（gedit），但是爲了方便跳轉和可讀性，wiki上還有專門介紹IDE的http://wiki.ros.org/IDEs，選取一個自己喜歡的即可。我比較推薦QtCreator，關於如何配置可參見《三種方法在ROS中加載Qt庫進行GUI設計》，關於這個配置我還是探索了比較久的時間。
如果自定義消息發佈，保存加載參數，寫服務，用一些指令查看ROS狀態比如rostopic, rosnode, rosparam, rossrv, rosservice，用一些可視化小工具進行分析、監控比如rqt_graph, rqt_reconfigure, rqt_plot, rivz, rqt_console等，那麼說明ROS的學習進展得不錯。我相信每個人在使用編寫或使用上述工具的時候都會遇到不同的問題和坑，不過有問題不怕，關鍵是去解決它，並享受解決的過程。
我們還可以再細想兩個問題，1. ROS的核心框架是什麼，它是如何實現這些機制的（話題、服務等）。2. catkin_make是什麼，起什麼作用。
2.2.1 ROS核心框架
對於第一個問題，我也沒仔細研究過源碼，核心代碼基本由python和C++組成，運用了xmlrpc機制，每個運行的節點可以理解成一個進程。進程間通訊有些是共享內存的方式（比如message_filter），有些應該是通過socket。不過ROS的核心框架也就是ros-base主要由Willow Garage公司和一些開發者設計、提供以及維護，它提供了一些分佈式計算的基本工具。
sudo apt install ros-melodic-ros-base分佈式計算框架可以理解爲ROS的所有節點運行時需要一個主控制器ROS Master（通過roscore指令開啓），ROS Master 通過RPC（Remote Procedure Call Protocol，遠程過程調用）提供了登記列表和對其他計算圖表的查找。沒有控制器，節點將無法找到其他節點，交換消息或調用服務。節點與節點之間的連接是直接的，控制器僅僅提供了查詢信息，就像一個DNS(Domain Name System)服務器。
ROS的框架還是挺複雜的，光看一些理論性的介紹可能還有點概念，但真正去實現裏面肯定還有不少細節問題。
真正在應用ROS框架時，其實也有一些不足的地方，比如
- ROS節點相互之間通信時如何知道另外一個節點的狀態，是宕掉了還是正常，因爲它強依賴於於中心節點ROS Master。本身在系統中頻繁創建話題就不是一件很好的事，會造成多少內存碎片。在使用ros::Subscriber sub = n.subscribe("chatter", 1000, chatterCallback)時，這個1000是隊列消息的緩存數目，如果是圖像或者點雲比較大的數據，就不要隨便寫1000了，不然內存會被消耗光。
- 系統中存在大量話題和數據時，本地傳輸的數據延時大而不確定，遠程傳輸的數據更是受帶寬和處理性能的影響。對於機器人的控制而言，想要達到精確更多，通信延時就要做得更小，而ROS這種通信機制實時性和穩定性不太好。
- ROS的msg採用md5碼去進行校驗，如果一個人改了沒通知另外一個人，經常導致另外一個人的包運行不起來的尷尬局面。
- ROS與可視化界面通信時，有時不知道是界面還是ROS機制問題，界面會莫名閃退（rviz就經常出現這樣的問題）。
- 關於ROS的動態參數保存問題，比如在rqt_reconfigure上調好的參數如何在重啓roscore後加載調試後的參數。我曾花費過很久的時間，參見《在ROS中處理yaml文件》和《ROS動態調參(dynamic reconfigure)客戶端服務端之C++ Python實現》，但也沒有很好地解決。很多功能可能僅適用於給開發者用，但當作產品去使用還是有很多地方值得去優化。
2.2.2 catkin workspace
對於第二個問題也是非常重要和關鍵的，就好比如何去創建一個VS的sln工程並編譯運行，如何去創建一個pro的Qt工程，如何去創建一個nodeJS工程等。catkin_make作用於ROS的一個工作空間(workspace)，workspace包含了一個standalone的ROS包，參見http://wiki.ros.org/catkin/workspaces，即定義一種ROS開發的規範，或者一個ROS的工程裏面應包含哪些東西。
catkin_make可以理解爲對cmake的又一次封裝，在編寫CMakeLists.txt時加入了適配ROS框架的語法，比如catkin_package，add_message_files等，其餘大部分都跟cmake語法相同。所以除了用IDE去建立工程，學會用cmake也是開發ROS的一個必備技能。最初C++程序直接用g++編譯就好，當程序規模越來越大時，就有很多文件夾和源文件，輸入的編譯指令也越來越長，尤其是涉及依賴系統庫，第三方庫，自定義庫時就更需要一個高效方便的工具。因此採用makefile的方式編寫一些規則來處理編譯問題，但對於一個大工程，編寫makefile是件複雜的事，於是又有了cmake工具。它讀入所有源文件之後，自動輸出各種各樣的makefile或project文件，隨之而來也就是編寫CMakeLists.txt文件，依照的規則就是cmake。cmake跨平臺，我想這也是ROS基於cmake編譯的原因之一。我曾試過用cmake加make編譯ROS工程，也是可以的，參見https://github.com/WelinLee/ROS_QT_GUI的ros_cmake工程。
其次，我們需對ROS編程的命名空間和命名規範有一定了解，這裏不是指C++的命名空間或者作用域，而且ROS節點間通訊時要注意的一個細節。比如有些節點名字前有“/”或者“~”，具體可參見http://wiki.ros.org/Names。
| Node | Relative (default) | Global | Private |
| /node1 | bar -> /bar | /bar -> /bar | ~bar -> /node1/bar |
| /wg/node2 | bar -> /wg/bar | /bar -> /bar | ~bar -> /wg/node2/bar |
| /wg/node3 | foo/bar -> /wg/foo/bar | /foo/bar -> /foo/bar | ~foo/bar -> /wg/node3/foo/bar |
2.2.3 ROS的擴展
ROS除了本身框架性的東西以外，最大的特色就是能融合很多其他的東西，形成一個完整的機器人開發生態圈，難怪ROS名爲機器人操作系統，使命是powering the world's robots也是毫不誇張的。ROS的擴展即ROS universe，是全球範圍的代碼，有不同國家的ROS社區組織開發和維護。有的是庫代碼，如OpenCV、PCL等；庫的上一層是從功能角度提供的代碼，如人臉識別，導航等，調用下層的庫；最上層的代碼是應用級的代碼，讓機器人完成某一確定的功能。ROS真的是包羅萬象，各種庫、功能性框架都能融入進來，使其越來越強大。使用第三方庫一般有兩種方法：
- 一種是通過cmake方法添加，有些庫比如Qt、OpenCV、PCL等，可能直接下載ROS的時候就已經嵌套進去了，直接通過ROS的環境變量就能依賴到這些庫。但我更傾向於ROS框架保持不變，其他庫再另外下載安裝。因爲通過ROS下載的第三方庫一般不完整或者版本不對導致開發受限等，最好直接安裝第三方庫然後通過cmake找第三方庫在本機所安裝的位置(find_package)，這樣庫和庫之間相對關係就很明確，ROS的基本框架也沒被填充太多，也能保持得比較乾淨，更不會被找不到環境變量所困擾。ROS和第三方庫相互依賴的問題，估計困擾過不少人，我經常被花大量的時間在庫依賴問題上。
- 另一種是讓第三方庫增加一些接口來適配ROS框架，也就是做成ROS包。有些廠商比如激光雷達或者一些CAN總線協議，直接就提供了ROS接口，可以很方便的使用。可以說，基本上大部分成熟的算法（機械臂正逆解、SLAM導航、點雲、圖像處理等），傳感器接口（sick、kinect等），通信協議（EarthCAT、CANOpen、USB等）都可以在ROS wiki和GitHub上找到。
2.3 ROS的運用開發
通過對2.2節的學習和實踐，我們對ROS的開發，嚴格說應該是對機器人的開發有一定概念和了解，知道該如何去做搭建機器人框架。一般來說市面上機器人的開發分兩個主流，一個是移動機器人（AGV），主要應該是酒店送餐，餐廳導航+送餐，倉庫物流，銀行業務處理等；一種是協作機器人，六自由度，用於抓取、焊接等。當然還有這兩種的結合形成可搬運加抓取的複合機器人，一些小的方向還有人形機器人、無人機等。
以開發AGV爲例，對於AGV來說尤其是室內運用的場景，最重要的就是地圖構建和導航，也就是SLAM技術。這裏面主要涉及三大塊：
- 建圖，比如gmapping，hector_slam，cartographer這幾個算法，通過採集點雲數據進行地圖構建。這裏的點雲數據一般是一個特定平面的，如何sick tim571，倍加福R2000，鐳神這些傳感器都能實現該功能，並提供好了對應的ROS包，或者通過kinect，realsense三維傳感器將其轉換爲二維的數據。不管是哪種傳感器，不同於接口，激光雷達一般是網口形式，和運行的Ubuntu電腦組成一個局域網，而三維點雲一般是通過USB或者串口通信使ROS獲取到數據。所以使用ROS的這點好處就在於，不用太關注於硬件接口甚至物理接口的定義。對於ROS使用建圖包，我在《ROS中slam_gmapping、map_server源碼解讀及其librviz的使用》中有詳細說明。
- 定位， 常用的是AMCL算法，也就是針對上述建圖得到的機器人當前在地圖中的位置座標信息，因爲是二維地圖，得到的數據是x,y座標和方向角。AMCL包一般和導航的包是合在一起的。這裏單獨列出來是爲了說明還有其他定位方式，比如光反射導航定位、超聲波導航定位、wifi定位等，有篇總結比較好的博客《自主移動機器人常用的導航定位技術及原理》可以參見一下。
- 導航和路徑規劃，也就是move_base包，裏面還包含局部路徑規劃，全局路徑規劃，dwa路徑搜索和costmap_2d。關於這些包之間的調用，網上有太多這樣的圖，我就沒必要再貼一遍了。costmap是David V. Lu提出的算法，即代價地圖，其核心思想是對所建立的地圖包括機器人本身都要進行一定的膨脹，也就是預留一定空間要考慮機器人的體積大小，不然行駛時，尤其是轉彎，機器人會碰撞到障礙物。關於costmap的應用，尤其是添加自己想要的layer，賀一家博士有很好的實踐，參見《ROS 教程之 navigation ：在 catkin 環境下創建costmap layer plugin》。
有了上述這幾個包，機器人就能跑起來了嗎？答案肯定是否定的，不過至少這些包可以在Gazebo和rviz中仿真了，看起來效果還是挺不錯的。不過仿真和實際差別還是太大了，比如真實環境中激光雷達採集到的數據，真實環境中所建立的地圖等。此外，搭建一個小型的機器人系統從硬件選型到調試成功也會經歷一段非常痛苦的過程。爲了快速上手或者驗證，可以從一些現成的機器人入手，比如TurtleBot。不過這些更多適用於實驗室研究，比如算法的驗證等。對於真正的開發機器人產品，也具有一定的參考價值。
一般而言，AGV的系統架構圖如下：
可以看到主要核心控制是運行在Ubuntu的工業級電腦上，激光雷達基本是現成的模塊，語音系統一般是選配的模塊，這種模塊也挺多，比如科大訊飛等，根據項目需求來。同等重要的還有傳感器採集模塊，也就是ARM層或PLC層，這一層主要用於採集外圍的數據包括電機驅動並上報給ROS層，所以這個工作量也非常大，涉及到的通信協議也比較多。至關重要的就是ARM層和PC之間的通信，無論是傳輸速率還是協議的穩定性都有待大量的驗證，曾經因爲通信協議的問題導致的粘包也是相當難定位的。所以儘量不要採用自有協議，用穩定的modbus 232，CANopen總線等是比較好的選擇。關於和硬件通信方面的問題，引用一個老外的話，我覺得遵循這個原則是比較穩定的，尤其是在加載硬件初始化的過程中。
A way to enable a correct sync -> the HW should wait to send the ackknowledge until they really finished the write procedure. That's it what an acknowledge to a write call should stand for: "Understand, verified, operation done". With this double sync solution we can track all misbehavior and implement correct reaction to that in the system software.
其次，AGV一般是兩輪或者四輪的結構，驅動器和電機的選擇也是非常重要的，不然里程計導致的累計誤差會影響建圖和定位精度。現在有專門只做AGV控制器的公司，也就是圖片中的ROS層和ARM層這一塊（注：就不一定是採用的ROS框架了），控制器本身就預留有IO，還能適配某些485協議和控制某些型號的電機驅動器，此外其他模塊直接插上去就可以用，對外也提供了各種各樣的接口用於二次開發。於是客戶更側重於應用層，也就是HMI這一塊，比如手機端應用，web端顯示，PC端的軟件等，這種二次開發一般採用C/S或者B/S的架構。我看到一個比較好的AGV調試人機交互界面例子是Ros_Qt5_Gui_App（在GitHub上搜ros qt gui就排在我前面一位）。
最後就是結構問題，我不知道是不是因爲騰訊、阿里巴巴、網易、字節跳動等這些互聯網巨頭公司的影響，我們越來越看重軟件的開發，覺得ROS層和嵌入式層的開發纔是關鍵。其實對於製造業產品，工業設計和結構設計非常重要，軟件設計再好，結構沒設計到位哪怕是一點尺寸的偏差都會導致機器運行不穩定。在ROS中urdf模型文件的定義也跟設計的結構有關（尺寸、位置等）。另外，結構設計需要考慮是否容易安裝、維護、部件的更換、AGV平衡性、精度、美觀等等，也不是一件容易的事。
關於開發的調試，ROS上手容易但調試難，一是缺少單步調試，我目前看到的方法是使用GDB調試器，不過感覺還是挺麻煩的，用得人不太多，更多的bug調試還是通過日誌查看的。二由於ROS中設計的各種通信接口，串口調試工具，TCPView，wireshark，CAN analyzer等都是常用的工具。
關於ROS的開發，尤其是那些複雜的算法，我個人覺得更多得還是去實踐和應用，很少有去重構和再寫一個新的算法，提取出一些關鍵信息進行可視化研究或者改進和優化。比如下面的技術問題：
最後總結關於開發ROS一些比較好的資料，在ROS開發過程中會經常用到：
- 跟ROS核心框架相關的東西，可以在https://github.com/ros上面找到源碼。
- 運用ROS進行一些可視化分析，圖形界面操作等，可以在https://github.com/ros-visualization上面找到源碼，主要是ros和qt或者pyqt的結合使用，非常有幫助。
- ROS主要是爲了解決機器人的控制問題，其中導航開源庫可以在https://github.com/ros-planning/navigation查看，機械臂規劃則對應的是moveit包。
- 做機器人少不了傳感器，也就是機器人的感知系統，在https://github.com/ros-perception可以查看大量的源碼，如與opencv的配合使用，點雲庫PCL的使用，激光、IMU數據的採集等。
2.4 ROS開發心得
通過前面三節關於ROS開發的描述，我們會發現用ROS去做一個機器人要掌握非常多的東西，比如Linux相關指令，cmake語法，各種環境變量的設置和第三庫的加載，C++/python，boost/STL庫的使用，日誌記錄和分析，各種小工具的使用，各種通信協議的瞭解，組網，如何搭建一個仿真環境，軟件版本管理和打包，研究或者測試相關算法等，而且還有不斷不斷新的東西去探究。這麼看好像確實比純粹的前端開發，手機端應用開發，遊戲開發，自動化軟件開發要有意思和挑戰一點。因此，稍微有點想法和想做事的人找十個、二十個人的志同道合夥伴就成立了機器人公司，也不斷趕上機器人的風口浪尖。所以我覺得ROS的出現讓機器人越來越好開發，並讓很多人認識到機器人開發是怎麼一回事，知道該如何去開發。同時另一方面，我覺得ROS的出現又降低了機器人開發的門檻，爲什麼這麼說呢，以前可能會覺得做機器人是一件很高大上、及其難上手的事。現在光深圳一個城市就有大量的機器人創業公司，有大量的公司成立機器人事業部或研究院，而不像某些東西比如芯片、精密傳感器、PLC、CT等，可能全球就那麼幾家或者幾十家能做，也就是說你看到這個東西后都不知道怎麼去做，連它的系統架構和生產工藝都不清楚，這些纔是具有核心競爭力和有挑戰的東西。
對於研發一款機器人確實要打磨非常久的時間，要下狠功夫。比如2.3節畫的AGV系統框圖，每一個環節，軟硬通信、工業PC的性能測試都需要做大量的老化測試。尤其是工業路由，因爲AGV的調試一般是獨立的單個車體，又是到處移動的，活動區域範圍比較大，很難用有線連接去測，所以部署的網絡可靠性要求非常高，特別是涉及多個AGV運行時。另外我覺得室內激光導航也有它的侷限性或者技術瓶頸，更適用於比較規則的靜態場景，而對於有桌子、椅子和人員的場景，會導致建圖精度不高，地圖和前幾天比也存在差異導致定位不準因爲某些障礙物信息的移動。對於比較大的區域，每次重新掃圖再設計路徑，添加位置信息等也是一件比較痛苦的過程。此外每次slam掃出來圖我都覺得很彆扭，總覺得客戶體驗性不友好，總有人看不出地圖上的信息對應實際中的位置。
其次DevOps（Development和Operations），過程、方法與系統的統稱，用於促進開發、技術運營和質量保障（QA）部門之間的溝通、協作與整合，可以理解爲一種開發模式。這是一個2009年就出現的概念，到現在已涵蓋了非常豐富的內容，包括組織文化、自動化、精益、反饋和分享等不同方面。這個概念在大廠尤其是互聯網公司運用非常廣泛，也就是一種開發模式的轉變，以前比較流行的是瀑布開發。即研發人員根據需求在約定的時間點進行交差，迭代的頻率是1個月1次，或者1個季度1次，研發聚焦於功能開發。在功能開發完成後交付測試團隊進行測試，測試團隊經過反覆的測試與問題修復後，交付運維團隊進行上線，此後生產環境的可用性、穩定性等工作由運維負責。這種開發模式存在的問題是需求不能得到快速驗證，很有可能團隊花費半年的時間開發出來的東西早已經不適合市場了，也還有種可能是在開發階段研發需求理解不到位，等到後期驗證時發現有問題再去做調整耽誤整體工期。目前比較流行的開發方式是敏捷開發模型，用於針對頻繁的需求變化，要求快速開發。比較流行案例則是Scrum、XP極限編程。在新迭代（一般2-6周）開始前，產品經理將需求拆分成具體的開發任務，研發人員進行任務認領，每日站會進行任務的review，直到開發完成，發佈新的可用版本。
最後要做好一個機器人產品，研發、生產、供應鏈管理和售後服務這四個環節缺一不可。很多機器人創業公司更多得投入在研發和試驗階段，就算demo做得非常漂亮，爲什麼還是很難出機器人產品呢？原因一可能在於市場需求還沒那麼大。原因二我覺得在於研發和後面三個環節脫離太遠，或者還沒走到那一步。比如從研發到生產這個transfer的過程是個非常重要的指標。產品研發的好不好做一個試驗就行，讓研發人員親自去組裝10臺他所研製的設備，如果他覺得安裝還比較順利，且這10臺運行的相關性差不多，並能連續運行72小時以上無故障，說明產品無論是設計還是可靠性都還不錯。
引用古月居的話總結一下用ROS開發機器人：機器人做的好，不一定是因爲你用了ROS，機器人做不好，也不一定是因爲你沒用ROS。假如我們是詩人，那ROS就是一本字典，裏邊爲我們提供了很多美麗的字符，當然也有很多遣詞造句，但是你寫詩總不能照搬原句，能不能寫出好詩，還是要看詩人的才華。這也是爲什麼古月居着手於ROS推廣和培訓的原因，ROS就有點類似於老師，帶你進入機器人世界，但師傅領進門，修行靠個人。
3 未來展望
關於機器人的展望就有太多太多文章了，我不是一個喜歡講宏觀性東西的人，更多的側重於技術細節，talk is cheap, show me the code。其實就AGV而言就有非常多，比如單個AGV的導航方式的研究，讓一個控制器就能適配多種導航方式；多AGV的調度研究，同時關聯工廠或者倉庫的物料信息；跨樓層，跨樓宇之間AGV的運輸問題。總之有太多細分領域值得去挖掘、思考，有太多技術值得去突破，而且涉及到的行業也不僅限於一個、兩個。AGV廠商不能僅限於單賣一款或者一個型號的產品，是很難推廣的，要具有提供一整套解決方案，形成一個AGV生態圈。也就是說，AGV產業發展了十幾年，也沒有特別統一的標準，市面上魚龍混雜，各成一派，前面還是一片藍海。我相信未來一定能出現推動整個行業發展的機器人或者AGV的一個巨頭公司，就類似於蘋果引領手機行業發展、西門子引領工業控制方向、谷歌引領互聯網發展方向、特斯拉引領新能源汽車方向。
關於整個機器人行業的動態，哪個公司出了什麼產品，得到了什麼投資，有哪些新的應用，可以看看高工產業研究院出的高工機器人期刊或者叫公衆號，裏面講得非常詳細，分析也很到位。
LWL於深圳