ROS与机器人

admin 管理员组

文章数量: 887021

快一年没用ROS了，不过尽管如此，如果有人问之前写的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/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/IDEs，选取一个自己喜欢的即可。如果是C++编程，我比较推荐QtCreator，如何配置可参见《三种方法在ROS中加载Qt库进行GUI设计》；如果是Python编程，参见《在ROS中利用PyQt写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/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/WelinLee/ROS_QT_GUI的ros_cmake工程。

其次，我们需对ROS编程的命名空间和命名规范有一定了解，这里不是指C++的命名空间或者作用域，而且ROS节点间通讯时要注意的一个细节。比如有些节点名字前有“/”或者“~”，具体可参见http://wiki.ros/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协议和控制某些型号的电机驱动器，这些模块直接插上去就可以用。此外，对外还提供了各种各样的接口（TCP server，web，modbus master等）用于二次开发。于是客户更侧重于应用层，也就是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等都是常用的工具。三是window和linux下相互间远程，相互间传文件等，从中可以学到不少东西。

关于ROS的开发，尤其是那些复杂的算法，我个人觉得更多得还是去实践和应用，很少有去重构和再写一个新的算法，大部分人的工作是提取出一些关键信息进行可视化操作或者改进和优化。比如下面的技术问题：

最后总结关于开发ROS一些比较好的资料，在ROS开发过程中会经常用到：

1. 跟ROS核心框架相关的东西，可以在https://github/ros上面找到源码。
2. 运用ROS进行一些可视化分析，图形界面操作等，可以在https://github/ros-visualization上面找到源码，主要是ros和qt或者pyqt的结合使用，非常有帮助。
3. ROS主要是为了解决机器人的控制问题，其中导航开源库可以在https://github/ros-planning/navigation查看，机械臂规划则对应的是moveit包。
4. 做机器人少不了传感器，也就是机器人的感知系统，在https://github/ros-perception可以查看大量的源码，如与opencv的配合使用，点云库PCL的使用，激光、IMU数据的采集等。

2.4 ROS开发心得

通过前面三节关于ROS开发的描述，我们会发现用ROS去做一个机器人要掌握非常多的东西，比如Linux相关指令，cmake语法，各种环境变量的设置和第三库的加载，C++/python，boost/STL库的使用，日志记录和分析，各种小工具的使用，各种通信协议的了解，组网，如何搭建一个仿真环境，软件版本管理和打包，研究或者测试相关算法等，而且还有不断不断新的东西去探究。这么看好像确实比纯粹的做前端开发，手机端应用开发，游戏开发，自动化软件开发似乎要有意思和挑战一点。因此，稍微有点想法和想做事的人找十个、二十个人的志同道合伙伴就成立了机器人公司，也不断赶上机器人的风口浪尖。所以我觉得ROS的出现让机器人越来越好开发，并让很多人认识到机器人开发是怎么一回事，知道该如何去开发。同时另一方面，我觉得ROS的出现又降低了机器人开发的门槛。为什么这么说呢？以前可能会觉得做机器人是一件很高大上、及其难上手的事。现在光深圳一个城市就有大量的机器人公司，而不像某些东西比如芯片、精密传感器、PLC、CT等，可能全球就那么几家或者几十家能做，也就是说你看到这个东西后都不知道怎么去做，连它的系统架构和生产工艺都不清楚，而这些才是具有核心竞争力和有挑战的东西。

对于研发一款机器人确实要打磨非常久的时间，要下狠功夫。比如2.3节画的AGV系统框图，每一个环节，软硬通信、工业PC的性能测试都需要做大量的老化测试。印象中我测试过的工控机厂家就有安勤、IEI、研华；工业路由有NEXCOM、MOXA、ORing；电机与驱动器有步科、Motec。这里面尤其是工业路由，因为AGV的调试一般是独立的单个车体，又是到处移动的，活动区域范围比较大，很难用有线连接去测，所以部署的网络可靠性要求非常高，特别是涉及多个AGV运行时。另外我觉得室内激光导航也有它的局限性或者技术瓶颈，更适用于比较规则的静态场景，而对于有桌子、椅子和人员的场景，会导致建图精度不高，地图和前几天比也存在差异导致定位不准因为某些障碍物信息的移动。对于比较大的区域，每次重新扫图再设计路径，添加位置信息等也是一件比较痛苦的过程。此外每次slam扫出来图我都觉得很别扭，觉得客户体验性不友好，总有人看不出地图上的信息对应实际中的位置。

其次DevOps（Development和Operations），过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合，可以理解为一种开发模式。这是一个2009年就出现的概念，到现在已涵盖了非常丰富的内容，包括组织文化、自动化、精益、反馈和分享等不同方面。别小看这一个过程，当产品做到一定阶段尤其是上市后就必须得考虑的事情。不然就跟下馆子吃饭一样，今天这个火就赶紧做这个，明天那个火就去换另一个，一直都是一次性的，没有一个持续、稳定、可迭代的产品。这种开发模式在大厂尤其是互联网公司运用非常广泛，其实就是一种研发方式的转变，以前比较流行的是瀑布开发。即研发人员根据需求在约定的时间点进行交差，迭代的频率是1个月1次，或者1个季度1次，研发聚焦于功能开发。在功能开发完成后交付测试团队进行测试，测试团队经过反复的测试与问题修复后，交付运维团队进行上线，此后生产环境的可用性、稳定性等工作由运维负责。这种开发模式存在的问题是需求不能得到快速验证，很有可能团队花费半年的时间开发出来的东西早已经不适合市场了，也还有种可能是在开发阶段研发需求理解不到位，等到后期验证时发现有问题再去做调整耽误整体工期。目前比较流行的开发方式是敏捷开发模型，用于针对频繁的需求变化，要求快速开发。比较流行案例则是Scrum、XP极限编程。在新迭代（一般2-6周）开始前，产品经理将需求拆分成具体的开发任务，研发人员进行任务认领，每天的站会进行任务review，直到开发完成，发布新的可用版本。关于这些理论，比较好的实践工具是微软的Azure和TFS(Team Foundation Server)。

最后要做好一个机器人产品，研发、生产、供应链管理和售后服务这四个环节缺一不可。很多机器人创业公司更多得投入在研发和试验阶段，就算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于深圳

本文标签： 机器人 ROS