Recently, Amu Lab launched the mavros offline training course. Some friends began to ask: Which is better, ros system or pixhawk? When I was asked this question suddenly, I was a little confused.
The editor personally thinks that to answer this question, it is necessary to have a deep understanding of both systems, and to have a say in products and projects. But such people are so rare. It's a pity that I haven't met such a person near me. If you read this article and you can answer that question, please contact Amu Lab. If your answer can satisfy everyone, Amu Lab can send a small gift.
The editor uses a non-professional statement, ros and pixhawk are two different system platforms, and the purpose of the design is different. It's like asking which is better rice or oranges? Of course, it depends on your own situation. To solve the hunger problem, I recommend rice. As a snack, I recommend oranges. It is also possible for a small partner to reverse the order, but the result is obvious. Finally, back to the question, which is better, ros system or pixhawk? As noted below, many issues are not a simple "good" or "bad" judgement. It depends on our purpose of use and our own situation, and then study this system to find the best answer.
Regarding ros, the editor found a good article and reprinted it for everyone to read.
The original author is Miika of Pulu Robotics, a senior embedded engineer. He insists on developing software from scratch and advocates solving the complexity of robot software from the bottom. If your system is biased towards embedded, this article is worth a look.
The following was compiled by Top Liu and Relay Zhang from the Eco Robotics Lab
ROS or Robot Operating System has been widely sold in the market as a comprehensive solution in robot research and development. So, we are also always asked if we use ROS. When we tell people "No", many people nod their heads in understanding, but many also express confusion and wonder why not? Since this question is somewhat complex, but crucial to future robotics research and development, we would like to explore our views in depth.
We don't need to use ROS
We started developing robotics based on our actual needs in February 2017, we don't have any robotics experience and therefore don't know how to do it. I am experienced in designing electronics and embedded software, including power electronics, electric vehicle traction and image sensors, but never in robotics.
Of course, we also saw ROS at the same time I was developing our game-changing (mostly price-cutting) integrated electronic designs. "Everyone is using it, so it has to be good." But things aren't just "good" or "bad." A hammer is an excellent tool for nails, but not for screws. The fact that others are using ROS suggests that it solved their problem (or so they thought). But do we think it answers our question?
Starting from scratch is sometimes the right solution
I have tried to write a ROS driver for my hardware. If the learning curve had been easier back then, things might have been different. But nothing actually came out, which made us question the need for this system.
After analyzing the situation, we wrote down what ROS is and what our needs are, and have very little in common.
ROS integrates existing, often difficult-to-use, incompatible hardware such as sensors, actuators, etc., by converting its data stream into a message bus, using data types that are compatible between hardware drivers and computational units. It is also a set of transformation interfaces for running multiple external (ie, not developed in ROS) open source computing algorithms.
When researchers buy new $1,000 or $5,000 robotic hardware, ROS also provides tools to help test what's already available. Therefore, ROS is a translator between robot parts and between robot designers, ROS is a "common language". All of this sounds great when you state it like above!
Our business is completely different. We are designing a powerful robotics platform as a complete integrated solution for the following reasons:
1) Developing all the parts in-house in a comprehensive way is the only way to reduce the price of the robot at least tenfold. If we were to build our robot with "robot components", as others seem to be doing, our total bill of materials would be at least $5,000 (as everyone else), compared to the market price that would require at least $15,000 , which is actually where the game starts.
2.）将复杂的、单独的模块（不是相互兼容的）连接在一起，是一种使用效率低下的开发方法，即使在使用ROS等中间件时也是如此，即使是传说中已经有“别人”做好了驱动程序和数据转换。
3.）我们不会提供“可交换零件，对每个新的机器人零件测试”的可能性，这不是我们的产品，也不是我们的商业模式。ROS很擅长为此提供一个平台，如果这是我们的业务，我们会使用它。相反，我们正在构建我们自己的组件，将它们尽可能简单地整合在一起，并尽可能高效地将它们集成在一起，并尝试找到性能最佳的组件，以便我们的客户无需进行低级设计工作。然后，我们为社区提供一个完整的平台，我们希望能够在这个平台上设计真正的应用程序，从而为您提供一个跳跃式的开始，而不是一直重复变量块之间的必须的粘合。当然，因为它是开源的，任何人如果愿意，仍然可以修改这个平台，
ROS实际上可以解决我们10％左右的问题。剩下的90％至少会是两倍繁琐的。
“ROS方式”效率低下
我可以穿上你的马甲吗？
我开始把我们的机器人与外界隔离开来，事后看来，这个决定太棒了。
让我举一个例子。当负责将LIDAR（旋转激光扫描仪）数据映射到地图上时，我直接创建了代码，使用几乎零延迟的轮子编码器和陀螺仪数据来处理每个LIDAR测距数据点。它对机器人当前的坐标进行估计，有效地消除了机器人在采集过程中移动时，如果将LIDAR一次扫描作为单个固定的“帧”进行处理将出现的拉伸假象。
对我来说，这是一个不费脑筋的事情，但是后来，看看其他人如何在ROS环境中实现这一点，我很惊讶地发现这个问题常常完全被忽略了。这是可以理解的，因为虽然这个问题是我正在做低层集成时直接解决的（没有额外的代码，只是使用最新的信息，因为在你同一个CPU里已经有了所有你需要的数据）！但当您的系统非实时，又从多个不兼容的硬件设备接收非实时数据，再加上以“模块化”名义在软件之间所造成的人为障碍。正如我后来发现的那样，解决这个激光雷达问题实际上都够研究人员撰写完整（和复杂）的论文了！
对于我们的价格方面来说，昂贵的计算机也是不可能的。我们需要在Raspberry Pi 3上运行所有的功能。我们希望我们的产品功能丰富，敏捷，快速，节能。即使仅仅从环境角度来看，我们也承担不起将数十瓦的功率转化为热量，因为我们将要在这个星球上运行数百万台机器人。
因此，当其他厂商将100至1000美元的传感器和执行器模块组装在一起时，一些还要通过高延迟的USB，并且在昂贵的计算机内部复杂的消息传递体系结构中处理数据，这总是很慢，我们的解决方案是直接使用100 $的组件模块，全部连接到单个微控制器，运行简单的低级别实时代码，无操作系统，并提供机器人的主要“中枢神经”系统，使用200mW的功率来做到这一点。
低效率不仅体现在成本或功耗方面。在看过使用ROS的项目后，我们发现需要程序员一遍又一遍地解决同样的问题：如何在ROS系统中将各个部分“粘合”在一起，如何提供适于销售的用户接口，而不是演示/研究应用程序。
我们已经从零开始开发了所有东西，并且已经达到了相同的实际功能水平，并且通过一个三人小组用六个月时间实现，相比使用ROS需要十人小组在两年来实现（基于我们在分析市场时所看到的）。前方仍有很多艰苦的工作，尤其是在软件方面，但它是伟大的，我们的演示的设计具有实际的可制造性，所有都有CAD / CAM，BOM成本即使在10个单位的批次仍能满足我们的目标市场价格。
我们从来没有打算使用仅是演示用途的硬件（昂贵的、无法量产的或是干脆说没卵用的）来做演示。
ROS既不是问题，但也不是答案
我喜欢通过发现问题，从而找到问题的根源，然后修复它或完全重新来做。
移动机器人要价格合理，那么就很容易发现问题：昂贵、难以使用、通常不可靠的组件；缺乏编程技巧、资源或团队协调来构建完整的系统，缺少真实场景可用的“客户案例”。
我不知道ROS项目是否正在按照这些思路进行思考，但至少他们看起来正在解决同样的问题-正确的问题。然而，他们并没有能解决的根本原因，我想正是很多“ROS思想家”似乎还都喜欢这种方式。
今天机器人的基础往往是一个太过于复杂的系统。ROS位于复杂且昂贵的系统的顶端，也增加了更多的复杂性，但以某种方式成功地解决了这个难题。我看到一些伟大的演示，这令我印象深刻。
在我们看来，复杂性问题的答案必须是去除复杂的部分而不是管理它们。但是，如果我们删除作为移动机器人基础的部件，我们什么都没有了。所以我们别无选择，只能从头开始重做一切。
尽管从头开始听起来像是一项艰巨的任务，但请记住，这正是ROS的初心：让我们设计和实现这个庞大的软件，以便每个人都可以在以后重用。
在我们的例子中，通过固执的简化，做“一次大事”是可能的。我们以最基本的形式简化每个问题。如果事情看起来很复杂，我们必须深入挖掘，直到我们处于可能的最低层来解决复杂性的原因，而不是增加复杂性。我们想要得到正确的基础。
基础是机械和电子。（包括低层固件）
ROS是中间件。这也是我们为什么不与ROS竞争的原因。这就是为什么我们不重做他们的工作，为什么我说我们所做的90％没有被ROS回答。我们认为我们不需要中间件，我们的“stack”只是时间关键的低层（嵌入式）和高层次的计算。
我们将与ROS兼容（无论如何 - 请告诉我们！）
导航到未来
最后，我们发现，ROS是一个拥有庞大社区的完全胜任的系统，显然已经在许多机构和公司从中找到了自己的位置。我们鼓励大家做出自己的、明智的决定。我们都有自己的动机，永远不要盲目相信任何意见，根据您的技术分析做出技术决策，使其适用于你的业务模式。
所以，我们从来都不想阻挠任何人，对于那些能够流畅使用ROS，或者从“ROS方式”中获得灵感的人，我们甚至都想帮助你加入到这个运动中。
为此，我们决定（从第一天起）为我们的硬件提供ROS驱动程序。另一方面，我们从不善于满足别人的软件需求（而不是我们自己的需要）。我们自己对ROS体系结构的经验太少，所以如果ROS开源社区的某个人能够获得灵感来帮助我们，那么这可能是一个双赢的局面。我们已经得到了一些联系，显然有人希望这样做，这显示了ROS社区积极的一面。
我们将把所有的软件都作为开源发布，没有任何限制，所以我100％确定我们的产品也会在ROS社区产生巨大影响，即使我们现在没有使用ROS。