快一年沒用ROS了，不過盡管如此，如果有人問之前寫的ROS博客問題，還是會很仔細得回答，結合這些問題，加上之前的一些經歷和經驗，進行一個簡單的整理和總結，

目錄

1 機器人

2 ROS

2.1 ROS初探

2.2 ROS的簡單開發及其理解

2.2.1 ROS核心框架

2.2.2 catkin workspace

2.2.3 ROS的擴展

2.3 ROS的運用開發

2.4 ROS開發心得

3 未來展望

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框架時，其實也有一些不足的地方，比如

1. ROS節點相互之間通信時如何知道另外一個節點的狀態，是宕掉了還是正常，因為它強依賴于于中心節點ROS Master，本身在系統中頻繁創建話題就不是一件很好的事，會造成多少記憶體碎片，在使用ros::Subscriber sub = n.subscribe("chatter", 1000, chatterCallback)時，這個1000是佇列訊息的快取數目，如果是影像或者點云比較大的資料，就不要隨便寫1000了，不然記憶體會被消耗光，
2. 系統中存在大量話題和資料時，本地傳輸的資料延時大而不確定，遠程傳輸的資料更是受帶寬和處理性能的影響，對于機器人的控制而言，想要達到精確更多，通信延時就要做得更小，而ROS這種通信機制實時性和穩定性不太好，
3. ROS的msg采用md5碼去進行校驗，如果一個人改了沒通知另外一個人，經常導致另外一個人的包運行不起來的尷尬局面，
4. ROS與可視化界面通信時，有時不知道是界面還是ROS機制問題，界面會莫名閃退（rviz就經常出現這樣的問題），
5. 關于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，

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技術，這里面主要涉及三大塊：

1. 建圖，比如gmapping，hector_slam，cartographer這幾個演算法，通過采集點云資料進行地圖構建，這里的點云資料一般是一個特定平面的，如何sick tim571，倍加福R2000，鐳神這些傳感器都能實作該功能，并提供好了對應的ROS包，或者通過kinect，realsense三維傳感器將其轉換為二維的資料，不管是哪種傳感器，不同于介面，激光雷達一般是網口形式，和運行的Ubuntu電腦組成一個局域網，而三維點云一般是通過USB或者串口通信使ROS獲取到資料，所以使用ROS的這點好處就在于，不用太關注于硬體介面甚至物理介面的定義，對于ROS使用建圖包，我在《ROS中slam_gmapping、map_server原始碼解讀及其librviz的使用》中有詳細說明，
2. 定位， 常用的是AMCL演算法，也就是針對上述建圖得到的機器人當前在地圖中的位置坐標資訊，因為是二維地圖，得到的資料是x,y坐標和方向角，AMCL包一般和導航的包是合在一起的，這里單獨列出來是為了說明還有其他定位方式，比如光反射導航定位、超聲波導航定位、wifi定位等，有篇總結比較好的博客《自主移動機器人常用的導航定位技術及原理》可以參見一下，
3. 導航和路徑規劃，也就是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開發程序中會經常用到：

1. 跟ROS核心框架相關的東西，可以在https://github.com/ros上面找到原始碼，
2. 運用ROS進行一些可視化分析，圖形界面操作等，可以在https://github.com/ros-visualization上面找到原始碼，主要是ros和qt或者pyqt的結合使用，非常有幫助，
3. ROS主要是為了解決機器人的控制問題，其中導航開源庫可以在https://github.com/ros-planning/navigation查看，機械臂規劃則對應的是moveit包，
4. 做機器人少不了傳感器，也就是機器人的感知系統，在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于深圳