mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-03 23:40:14 +08:00
Merge pull request #5856 from SunWave/master
20170718 Things to consider when building a robot with open source.md[translated]
This commit is contained in:
Xingyu.Wang
GitHub
commit
fefd6c1c94
@ -1,57 +0,0 @@
|
||||
Translating by Sunwave
|
||||
|
||||
Things to consider when building a robot with open source
|
||||
==============================================
|
||||
|
||||
|
||||
### Share or save
|
||||
|
||||
|
||||
|
||||
So you’re considering (or are in the process of) bringing a robot, using open source software, to market. It’s based on Linux. Maybe you’re using the [Robot Operating System][2] (ROS), or the [Mission Oriented Operating Suite][3] (MOOS), or yet another open-source middleware that’s helping you streamline development. As development nears something useful, you start receiving some pressure about desired returns on this thing. You might be asked ‘When can we start selling it?’ This is where you reach a crossroads.
|
||||
|
||||
You can do one of two things:
|
||||
|
||||
1. Start shipping essentially what you have now
|
||||
|
||||
2. Step back, and treat going to production as an entirely new problem to solve, with new questions to answer
|
||||
|
||||
You don’t need to look very far to see examples of people who settled on (1). In fact, the IoT market is flooded with them. With the rush to get devices to market, it’s not at all rare to find devices left with hard-coded credentials, development keys, various security vulnerabilities, and no update path.
|
||||
|
||||
Think of Mirai, the botnet that mounted a DDoS attack with traffic surpassing 1Tbps, bringing down some of the biggest websites on the Internet. It’s made up primarily of IoT devices. Does it use super cool black magic developed in a windowless lab (or basement) to overwhelm the devices’ defenses and become their master? Nope, default (and often hard-coded) credentials. Did the manufacturers of these devices react quickly and release updates to all these devices in order to secure them? No, many of them don’t have an update method at all. [They recalled them instead][4].
|
||||
|
||||
Rather than rushing to market, take a step back. You can save yourself and your company a lot of pain simply by thinking through a few points.
|
||||
|
||||
For example, **how is your software updated**? You _must_ be able to answer this question. Your software is not perfect. In a few weeks you’ll find out that, when your autonomous HMMWV is used in California, it thinks that little sagebrush is an oak. Or you accidentally included your SSH keys.
|
||||
|
||||
**How is the base OS updated**? Perhaps this is still part of your product, and answering the above question answers this one as well. But perhaps your OS comes from another vendor. How do you get updates from them to your customers? This is where security vulnerabilities can really bite you: a kernel that is never updated, or a severely out-of-date openssl.
|
||||
|
||||
Once you have updates figured out, **how is your robot recovered if an update goes sideways**? My go-to example for this is a common solution to the previous problem: automatic security updates. That’s a great practice for servers and desktops and things that are obviously computers, because most people realize that there’s an acceptable way to turn those off, and it’s _not_ to hold the power button for 5 seconds. Robotic systems (and IoT systems in general) have a bit of an issue in that sometimes they’re not viewed as computers at all. If your robot is behaving oddly, chances are it will be forcefully powered off. If it was behaving oddly because it was installing a kernel update real quick, well, now you have a robotic paperweight with a partially installed kernel. You need to be able to deal with this type of situation.
|
||||
|
||||
Finally, **what is your factory process**? How do you install Linux, ROS (or whatever middleware you’re using), and your own stuff on a device you’re about to ship? Small shops might do it by hand, but that doesn’t scale and is error-prone. Others might make a custom seeded distro ISO, but that’s no small task and it’s not easy to maintain as you update your software. Still others use Chef or some other automation tool with a serious learning curve, and before long you realize that you dumped a significant amount of engineering effort into something that should have been easy.
|
||||
|
||||
All of these questions are important. If you find yourself not having clear answers to any of them, you should join our webinar, where we discuss how to build a commercial robot with open source. We’ll help you think through these questions, and be available to answer any more you have!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Kyle is a member of the Snapcraft team, and is also Canonical's resident roboticist. He focuses on snaps and the snap developer experience, as well as robotics enablement for snaps and Ubuntu Core.
|
||||
|
||||
|
||||
|
||||
-----------
|
||||
|
||||
via: https://insights.ubuntu.com/2017/07/18/things-to-consider-when-building-a-robot-with-open-source/
|
||||
|
||||
作者：[Kyle Fazzari ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://insights.ubuntu.com/author/kyrofa/
|
||||
[1]:https://insights.ubuntu.com/author/kyrofa/
|
||||
[2]:http://www.ros.org/
|
||||
[3]:http://www.robots.ox.ac.uk/~mobile/MOOS/wiki/pmwiki.php/Main/HomePage
|
||||
[4]:https://krebsonsecurity.com/2016/10/iot-device-maker-vows-product-recall-legal-action-against-western-accusers/
|
||||
@ -0,0 +1,40 @@
|
||||
# 使用开放源代码构建机器人时需要考虑的事项 #
|
||||
|
||||
|
||||
|
||||
|
||||
或许你正在考虑（或正在进行）将机器人使用开源软件推向市场。这个机器人是基于linux构建的。也许你正在使用机器人操作系统（ROS）或任务导向的操作套件（MODS），或者是另外一个可以帮助你简化开发过程的开源中间件。当开发接近实用化，期望得到回报会开始给你带来一些压力。你可能会被问到“我们的产品什么时候可以开始销售？”，这时你将面临重要的抉择。
|
||||
|
||||
你可以做下面两件事之一：
|
||||
|
||||
1.对现有的产品开始出货
|
||||
|
||||
2.回过头去，把现在的产品当做一个全新的问题来解决，并提出新的问题
|
||||
|
||||
不需要看很远，就可以找到采用（1）的例子。事实上，在物联网设备市场上，到处都是这样的设备。由于急于将设备推向市场，在这些设备中找到硬编码证书、开发密钥、各种安全漏洞和没有更新方式的产品并不少见。
|
||||
|
||||
想想Mirai僵尸程序，通过僵尸网络发起一个网络流量超过1Tbps的分布式拒绝服务攻击（DDos），导致一些互联网上最大的网站停止服务。这个僵尸网络主要由物联网设备组成。这种为了攻破设备的防御机制进而控制设备所开发的僵尸程序，是采用了超级酷的黑魔法在一个无窗实验室（或地下基地）开发的吗？不是，默认的（通常是硬编码）证书。这些设备的制造商是否快速反应并发布所有这些设备的更新，以确保设备的安全？不，很多制造商根本没有更新方法。他们会开始反思。
|
||||
|
||||
不是急于将产品推向市场，而是退后一步。多思考几点，就可以使你自己和你所在公司避免痛苦。
|
||||
|
||||
例如，你的软件如何更新？这必须能回答这个问题。你的软件不是完美的。几个星期之内，当你在加利福尼亚使用自主的高机动性多用途轮式车辆（HMMWV）时，它把小灌木识别为一棵橡树。或者你不小心在软件中包含了你的SSH密钥。
|
||||
|
||||
基础操作系统如何更新？也许这仍然是你的产品的一部分，也是你回答上一个问题的答案。但也许你使用的操作系统来自于另外一个供应商。你如何从供应商那里得到更新并提供给客户？这就是安全漏洞真正让你头痛的地方：从来不更新的内核，或者严重过时的开放ssl。
|
||||
|
||||
当你解决了更新问题，在更新过程出现问题时，机器人怎么恢复？我的示例是对前面问题的一个常见解决方案：自动安全更新。对于服务器和台式机以及显然是计算机的东西来说，这是一个很好的做法，因为大多数人意识到有一个可以接受的方法来关闭它，而不是按住电源按钮5秒钟。机器人系统（以及大多数物联网系统）有一个问题，有时它们根本不被认为是计算机。如果您的机器人表现奇怪，有可能会被强制关闭。如果你的机器人行为奇怪，因为它正在快速安装一个内核更新，那么，现在你有一个部分安装内核的机器人。你需要有能力处理这种情况。
|
||||
|
||||
最后，你的工厂流程是什么？你如何安装Linux，ROS（或者你使用的中间件），以及你要安装在设备上的你自己的东西？小的工厂可能会手工操作，但这种方法没有伸缩性，容易出错。其他厂商可能会制作一个定制化的初始发行版ISO，但这是不小的任务，在更新软件时也不容易维护。还有一些厂商会使用专家或者有陡峭学习曲线的自动化工具，不久就会意识到，你把大量的工程精力投入到本来应该很简单的工作中。
|
||||
所有这些问题都很重要。针对这些问题，如果你发现自己没有任何明确的答案，你应该加入我们的网络研讨会，在研讨会上我们讨论如何使用开放源代码构建一个商业化机器人。我们会帮助你思考这些问题，并可以回答你更多问题。
|
||||
|
||||
----------
|
||||
|
||||
作者简介：
|
||||
Kyle是Snapcraft团队的一员，也是Canonical公司的常驻机器人专家，他专注于snaps和snap开发实践，以及snaps和Ubuntu Core的机器人技术实现。
|
||||
|
||||
----------
|
||||
|
||||
via: [https://insights.ubuntu.com/2017/07/18/things-to-consider-when-building-a-robot-with-open-source/](https://insights.ubuntu.com/2017/07/18/things-to-consider-when-building-a-robot-with-open-source/)
|
||||
|
||||
作者：Kyle Fazzari 译者：SunWave 校对：校对者ID
|
||||
|
||||
本文由 LCTT 原创编译，Linux中国 荣誉推出
|
||||
Loading…
Reference in New Issue
Block a user