ROS或机器人操作系统作为机器人研究和开发的全面解决方案已经大量销售。所以，我们总是被问到是否使用ROS; 当我们告诉人们“不”的时候，许多人点头表示同意，而其他人则想知道为什么不这样做。由于这个问题对机器人研发工作的未来有些复杂和相当关键，所以我们想深入研究一下我们的推理。

我们不需要使用ROS

我们在2017年2月开始为自己的实际需要开发机器人技术，没有任何机器人技术经验，因此也不知道应该如何去做。我在设计电子和嵌入式软件方面经验丰富，包括电力电子，电动车牵引和图像传感器，但从未涉足机器人领域。

当然，在我开发我们改变游戏规则（主要是降价）集成电子设计的同时，我们也看到了ROS。“每个人都在使用它，所以它必须是好的。” 但事情不仅仅是“好”或“坏” 锤子是钉子的优秀工具，但不是螺丝钉。其他人使用ROS的事实表明，它解决了他们的问题（或者他们认为是这样）。但是，我们相信它回答了我们的吗？

我试图为我的硬件写一个ROS驱动程序。如果学习曲线变得更容易，事情可能会有所不同，但没有什么结果，让我们质疑是否需要这个。

在分析了这种情况之后，我们写下了ROS是什么，以及我们的需求是什么，而且几乎没有什么共同之处。

ROS将现有的传感器，执行器等硬件整合在一起，通常难以使​​用，不兼容，通过将其数据流转换成消息总线，在硬件驱动器和计算单元之间具有兼容的数据类型。它也是一组转换接口，用于运行多个外部（即，不开发用于ROS）的开源计算算法。

ROS还提供了一些工具来帮助研究人员测试出去的东西，并购买新的1000美元或5000美元的机器人硬件。因此，ROS是翻译者，ROS是“共同语言”; 机器人部件之间以及机器人设计人员之间。当你像这样陈述时，所有这些听起来都很棒。

我们的业务完全不同。我们正在设计一个功能强大的机器人平台作为一个完整的集成解决方案，原因如下：

1）以综合方式自行开发所有部件是将机器人的价格降低至少十倍的唯一方法。如果我们要用“机器人组件”来构建我们的机器人，就像其他人似乎正在做的那样，我们的总物料成本至少是5000美元（与其他人一样），至少需要15000美元的市场价格事实上比赛开始的地方）。

2.）将复杂的，单独的模块（不是相互兼容的）连接在一起，对开发时间的使用效率低下，即使在使用ROS等中间件时也是如此; 即使是传说中的“别人”做驱动程序和数据转换。 

3.）我们不会提供“交换零件，测试每个新的机器人零件”的可能性，这不是我们的产品，也不是我们的商业模式。ROS很擅长为此提供一个平台，如果这是我们的业务，我们会使用它。相反，我们正在构建我们自己的组件，将它们尽可能简单地整合在一起，并尽可能高效地将它们集成在一起，并尝试找到性能最佳的组件，以便我们的客户无需进行低级设计工作。然后，我们为社区提供一个完整的平台; 我们希望能够在这个平台上设计真正的应用程序，让您有一个快速的开始，而不是一直重复变量块之间的必要粘合。当然，因为它是开源的，任何人如果愿意，仍然可以修改这个平台，

“ROS方式”效率低下

我开始把我们的机器人与外界隔离开来，事后看来，那太棒了。

让我举一个例子。当负责将LIDAR（旋转激光扫描仪）数据映射到地图上时，我直观地创建了使用几乎零延迟的轮距测量和陀螺仪数据来处理每个LIDAR范围数据点的代码。这是当前的机器人坐标估计，有效地消除了在机器人在采集过程中移动时，如果将LIDAR扫描作为单个固定的“帧”处理将出现的所有拉伸假象。

对我来说，这是一个不费脑筋的事情，但是后来，看看其他人如何在ROS环境中实现这一点，我很惊讶地发现这个问题通常完全被忽略。这是可以理解的，因为虽然这个问题是直接解决在我正在做的集成低层次上（没有额外的代码 - 只是使用最新的信息，因为你已经拥有了所有你需要的CPU）！当您的非实时系统从多个不兼容的硬件设备接收非实时数据时，再加上以“模块化”名义的仿真软件障碍。解决这个激光雷达问题实际上是研究人员撰写完整（和复杂）的论文，就像我后来发现的那样！

For our price segment, expensive computers are also out of the question; we need to run everything on a Raspberry Pi 3. And we want our product to be feature-rich, agile, quick, and energy efficient. Even from the environmental point alone, we cannot afford to convert tens of watts of power into heat by running inefficient code, inside the millions of robots we are going to swarm this planet with.

因此，当其他厂商将100至1000美元的传感器和执行器模块组装在一起时，一些通过高延迟的USB，并且在昂贵的计算机内部复杂的消息传递体系结构中处理数据总是为时已晚，我们的解决方案直接使用$ 100组件模块，全部连接到单个微控制器，运行简单的低级别实时代码，无操作系统，并提供机器人的主要“中枢神经”系统，使用200mW的功率来做到这一点。

低效率不仅在成本或功耗方面。在看过使用ROS的项目后，我们发现程序员需要一遍又一遍地解决同样的问题：如何在ROS系统中“粘合”这些部分; 如何提供适销售的用户界面而不是演示/研究应用程序。

我们已经从零开始发展了所有的事情，并且已经达到了相同的实际功能水平，并且通过一个三个半月的团队，比使用ROS两年来一组10人达到的水平要高出三到三年（基于我们所拥有的在分析市场时看到）。很多艰苦的工作仍然领先，尤其是在软件方面，但它是伟大的，当演示实际上在具有实际可制造性设计中，所有可用的CAD / CAM原型运行，与我们的市场价格的目标兼容的BOM成本即使在10个单位的批次。

我们从来不打算用演示特定的（昂贵的，不可制造的或其他无用的）硬件来演示演示。

ROS不是问题，但也不是答案

我喜欢通过识别问题，找到问题的根源，然后修复它或完全重做。

通过价格合理的移动机器人，这个问题很容易识别：昂贵，难以使用，通常不可靠的组件，缺乏编程技巧，资源或团队协调来构建完整的系统，可用于真实的“客户案例”。

我不知道ROS项目是否正在按照这些思路进行思考，但至少他们显然正在解决同样的问题 - 正确的问题。然而，他们并没有解决根本原因 - 我想很多“ROS思想家”似乎都喜欢这种方式。

今天机器人的基础往往是一个太复杂的系统。ROS位于复杂而昂贵的系统的顶端，增加了更多的复杂性，并以某种方式成功地解决了这个难题。看到一些伟大的演示，我印象深刻。

在我们看来，复杂性问题的答案必须是去除复杂的部分而不是管理它们。但是，如果我们删除作为移动机器人基础的部件，我们什么都没有了。所以我们别无选择，只能从头开始重做一切。

尽管从头开始听起来像是一项艰巨的任务，但请记住，这正是ROS的前提：让我们设计和实现这个庞大的软件，以便每个人都可以在以后重用。

在我们的例子中，通过顽固的简化，做“一次大事”是可能的。我们以最基本的形式简化每个问题。如果事情看起来很复杂，而不是增加复杂性，我们必须深入挖掘，直到我们处于可能的最低水平，以解决复杂性的原因。我们想要得到正确的基础。

基础是机械和电子。（包括低级固件）

ROS是中间件。这也是我们为什么不与ROS竞争的原因。这就是为什么我们不重做他们的工作，为什么我说我们所做的90％没有被ROS回答。我们认为我们不需要中间件 - 我们的“堆栈”只是时序关键的低层（嵌入式）和高层次的计算。

我们将与ROS兼容（无论如何 - 请告诉我们！）

最后，我们发现，ROS是一个拥有大型社区的主管系统，显然已经在许多机构和公司中找到了自己的位置。我们鼓励大家做出自己的，明智的决定。我们都有我们的动机。永远不要盲目信任任何意见 - 根据您的技术分析做出技术决策，使其适用于您的业务模式。

所以，我们从来都不想阻挠任何人，对于那些流利的ROS，或者从“ROS方式”中获得灵感，我们都想帮助和加入这个运动。

为此，我们决定（从第一天起）为我们的硬件提供ROS驱动程序。另一方面，我们从不善于满足别人的软件需求（而不是我们自己的需要）。我们自己对ROS体系结构的经验太少，所以如果ROS开源社区的某个人能够获得灵感来帮助我们，那么这可能是一个双赢的局面 - 我们已经有了一些联系，人们显然希望这样做， ROS社区的积极动力。

我们将把所有的软件作为开源发布，没有任何限制，所以我100％确定普鲁的产品也将在ROS社区大受欢迎，即使我们现在不在内部使用ROS。

We don't need to use ROS

We started doing robotics for our own, practical need, in February 2017, with no experience in robotics whatsoever, and hence, no idea how it "should" be done. I was experienced in designing electronics and embedded software, including power electronics, EV traction, and image sensors, but never in the field of robotics.

Naturally, while I was developing our game-changing (mostly price-dropping) integrated electronic design, we looked at the ROS. "Everybody's using it, so it has to be good." But things are not just generally "good" or "bad"; a hammer is an excellent tool for a nail but not for a screw. The fact that others use ROS shows that it solves their problem (or they think it does). But do we believe that it answers ours?

I tried to write a ROS driver for my HW. If the learning curve would have been easier, things could be different, but nothing came out of it, making us question whether we need this at all.

After analyzing the situation, we wrote down what ROS is, and what our needs are, and found little in common.

ROS is there to integrate the multitude of existing sensor, actuator, etc. hardware, often hard to use and incompatible as is, by converting their datastreams into a message bus, with compatible datatypes between the hardware drivers and calculation units. It's also a set of conversion interfaces to run several external (i.e., not developed for ROS) open source computation algorithms.

ROS also offers tools to assist researchers in testing out things when they go out and buy a new $1000 or $5000 piece of robot hardware. So, ROS is a translator, and ROS is "the common language"; both between the robot parts, and between the robotic designers. All of which sounds great when you state it like this.

Our business is entirely different. We are designing a capable robotic platform as a complete, integrated solution, for several reasons:

1.) Developing all the parts by ourselves in an integrated fashion is the only way to drive the price of robotics down by a factor of at least ten. If we were to build our robots using "robotic components," as almost everybody else seems to be doing, our total Bill-Of-Materials would be at least $5000 (like with everybody else), necessitating at least $15000 market price (which is indeed where the competition starts).

2.) Connecting complex, separate modules (not designed to be compatible with each other) together is an inefficient and weak use of development time; even when it's done using a middleware such as ROS; even if it's the legendary "someone else" doing the drivers and data conversion. 

3.) We are not going to offer a "swap parts, test each new robotic component out" possibility at all, that's not our product, nor our business model. ROS is great at providing a platform for that purpose; we would use it if this were our business. Instead, we are building our own components, integrating them together efficiently at the lowest level - as simply as possible - and trying to find the components that perform the best, so that our customers don't need to do the low-level design work. Then, we provide a complete platform to the community; we hope to give you a jump start in designing real applications on this platform, instead of reinventing the necessary glue between variable blocks all the time. Of course, because it's open source, anyone can still modify the platform if they wish, but it's not a puzzle that requires solving before anything can be done.

The "ROS way" is inefficient

I started implementing our robot a little bit in isolation from the outside world; in hindsight, that was great.

Let me give you an example. When tasked with getting LIDAR (rotating laser scanner) data out for mapping, I intuitively created code that uses almost zero-latency wheel odometry and gyroscope data to process each LIDAR range data point. That is the current robot coordinate estimate, efficiently eliminating all stretching artifacts which would appear if a LIDAR scan was handled as a single stationary "frame" while the robot moves during the acquisition.

For me, this was a no-brainer, but later, looking at how others have implemented this in a ROS environment, I was horrified to see that the issue is typically just ignored entirely. It is understandable because while this problem is straightforward to solve on the integrated low level I was working on (no extra code - just use the newest information since you have all you need in the same CPU already!), it's much more difficult to do when you have a non-realtime system receiving non-realtime data from multiple incompatible hardware devices, plus artificial software barriers in the name of "modularity". Solving this lidar issue in difficult ways is actually something researchers write complete (and complicated) papers about, as I found out later!

For our price segment, expensive computers are also out of the question; we need to run everything on a Raspberry Pi 3. And we want our product to be feature-rich, agile, quick, and energy efficient. Even from the environmental point alone, we cannot afford to convert tens of watts of power into heat by running inefficient code, inside the millions of robots we are going to swarm this planet with.

So while others were putting together $100-$1000 sensor and actuator modules, some through high-latency USB, and processing the data always too late in a complex message passing architecture inside an expensive computer, our solution directly uses the $1 components found inside those $100 modules, all connected to a single microcontroller, running simple low-level real time code with no operating system, and providing the primary "central nerve" system of the robot, using 200mW of power to do that.

The inefficiency is not only in the cost or power consumption. Having looked at projects utilizing ROS, we have identified that programmers are needed to solve the same problems over and over again: how to "glue" the parts together in the ROS system; how to provide marketable user interfaces instead of demo/research applications.

We have developed everything from scratch, and have reached the same level of actual functionality with a team of three in six months than what it usually takes for a group of ten people to achieve in 2-3 years using ROS (based on what we have seen while analyzing the market). A lot of hard work is still ahead, especially in the software side, but it's great when the demos are actually running on prototypes that have actually manufacturable design inside, with all the CAD/CAM available, with BOM cost compatible with our market price goal even in 10-unit batches.

We never aim to just produce a demonstration using demonstration-specific (expensive, non-manufacturable, or otherwise useless) hardware.

ROS is not the problem, but neither the answer

I like to work by identifying a problem, finding the root cause to it, and then either fix it or completely redo it.

With affordable mobile robotics, the problem is easy to identify: expensive, hard to use, often unreliable components, and lack of programming skills, resources or team coordination to build a complete system, usable in real-world "customer cases."

I don't know if the ROS project was thinking precisely along those lines, but at least they are apparently solving the same problem - the right problem. However, they are not fixing the root cause - I guess many "ROS thinkers" actually seem to like the way it is.

The foundation for robotics today is often a system that is way too complex. ROS sits on the top of the complex, expensive system, adding a lot more complexity to it, and somehow succeeds to manage that puzzle; I'm impressed how well it works, having seen some great demos.

In our opinion, answer to the complexity problem must be to remove the complex parts instead of managing them. But if we remove the parts being the foundation of mobile robotics, we have nothing left. So we have no choice but to redo everything from scratch.

While doing everything from scratch sounds like a daunting task, please remember that's exactly what the premise of ROS was: let's design and implement this massive software thing once so that everyone can reuse it later.

In our case, doing the "massive thing once" is made possible by stubborn simplification. We simplify each problem in its most basic form. If something seems complex, instead of adding to that complexity, we must dig deeper until we are at the lowest level possible to fix the cause of that complexity. We want to get the foundation right.

The foundation is in mechanics and electronics. (Including low-level firmware.)

ROS is middleware. This is also why we don't compete with ROS at all. This is why we are not redoing their work, and why I said that 90% of what we do is not answered by ROS. We think we don't need middleware - our "stack" is just timing-critical low level (embedded) and computational high-level.

We'll be ROS compatible (whatever that means - please tell us!)

Finally, what we have found out, is that ROS is a competent system with a large community, and apparently has found its place in many institutions and companies. We encourage everybody to make their own, informed decision. We all have our motives. Never trust any opinion blindly - make technical decisions based on your technical analysis, so that it applies to your business model.

So, naturally, we don't ever want to discourage anyone, and for those fluent in ROS, or getting their inspiration from the "ROS way," we want to help and join the movement.

For this reason, we decided (from day one) to provide a ROS driver for our hardware. On the other hand, we never are very good at trying to fulfill the software needs of others (instead of our own need). We have too little experience in the ROS architecture ourselves, so it's probably a win-win situation if someone in the ROS open source community gets the inspiration to help us - we have already had a few contacts, people apparently want to do that, showing the positive drive in the ROS community.

We are going to publish all the software as open source, without limitations, so I'm 100% sure Pulu products will be a big hit in the ROS community as well, even if we don't use ROS internally right now.