嵌入式控制系统设计/RoboCup
|
的维基教科书
嵌入式控制系统设计
|
为了说明嵌入式控制系统的上述术语、特性和设计标准，本文以一组RoboCup机器人为例。这个例子涵盖了设计嵌入式控制系统时会遇到的所有方面。
RoboCup 是来自世界各地的 200 支机器人足球队之间的比赛，参加六个不同的联盟。每个机器人足球队由六个自主机器人组成（因此不允许人工干预）。机器人系统需要对规划、传感、控制和建模进行紧密集成。机器人还必须考虑自身、任务和环境之间的相互作用。有关 RoboCup 比赛的更多信息，请访问此链接：RoboCup
参加 RoboCup 比赛的每个团队都必须设计一支足球机器人队伍。每个足球机器人都是一个嵌入式控制系统，因此每个团队都可以看作是一个系统群。本章的目的是概述每个团队必须掌握的设计工作。
这个例子不同于其他例子，例如航空等，因为它
• 需求在项目开始时没有明确定义，而是随着下一章（移动目标）所示的不断调整。这意味着设计阶段没有明确定义，并且会随着目标的变化而变化。
• 存在一个不断变化和改进的主要敌对环境。在航空领域，环境，如空中交通管制或其他飞机（非战斗），是盟友，与飞机的行动配合。
• 存在不同的设计目标：“在给定的时间内和拥有的人力资源范围内尽力而为”。这意味着可以假设资源是固定的。
总的来说，这个例子可以看作是在每个设计级别上的系统群的原型。
总的来说，机器人技术可以分为两个领域：（按复杂程度递增排列）系统级设计（1 个机器人）或“系统群”级设计（机器人团队）。选择上述设计程序中的一个，取决于（团队）工程师的优先事项。但是，这两个领域都需要设计，因此，例如，从“系统群”级别开始，向下工作并优化单个机器人（通过从获得的结果中学习）是必要的。
RoboCup 团队 Wiki 有 1 年时间设计一个自主足球机器人团队。该团队组织了一个所有成员参与的头脑风暴会议，并列出了一份清单，其中列出了每个场地足球机器人必须具备的技能和/或规格，以实现其目的并遵循规章制度。这些技能和规格对设计人员来说是挑战，并用普通语言而不是用（技术）规格编写。
现在使用在嵌入式控制系统设计主章中解释的“四个 C”来执行对机器人技术的全面分析。以下主题重新表述了这四个概念，并将它们应用于本主题。
1.计算
计算可以描述为对每个可能输入的反应速度。“系统群”级别的计算取决于系统级别的计算，因此区分是多余的。在这两个级别上，硬件都是分散的。软件在系统级别是集中的，但在“系统群”级别是分散的。这种方法导致更快的系统，而且失败的可能性更小。
2.配置
这是机器人的编程。每个机器人中都实现了独立代码以及合作代码。
3.协调
可以在功能协调和系统协调之间进行区分。功能协调定义了战术智能，例如进攻所需的行动。另一方面，系统协调涵盖了不同子系统之间的连接。
4.通信
通信创建了使协调的各个方面成为可能的必要链接。机器人不同子系统之间的链接对于系统协调是必要的。
有关鲁棒性的更多一般信息，请参阅 设计标准。
鲁棒性是一个非常广泛的概念，它在 RoboCup 示例的许多领域都有很多应用。它可以描述为软件级别（处理通信错误等）或硬件级别（等同于碰撞等）的容错级别。
在鲁棒性和效率和性能之间取得良好的平衡非常重要。
• 系统必须足够鲁棒，能够处理移动目标。例如，始终预见通过使用外部链接通过电线上传新的驱动程序或软件来将新规则实施到配置中的方法。在多个管理程序或比赛策略之间切换的能力是一件明智的做法。
• 考虑硬件，客户端-服务器通信会导致单点故障，与点对点通信相比，这会严重降低鲁棒性。
• 在点对点通信的情况下，可以考虑在软件级别实现“服务器”。一个随机选择的机器人收集整个团队战术决策所需的所有输入并进行传输。在这种情况下，鲁棒性不会直接损失，效率更高。但是，在敌对环境中获取所有机器人的场地信息并不容易。因此，在每个级别上都使用点对点通信，这意味着每个机器人都会根据自己获得的信息确定战术决策（与其他机器人同时进行），并将信息进行传输，这可能是最初的更好解决方案。
• 最小的通信将导致最大的鲁棒性。但是，效率显著下降是不可忽视的。在 RoboCup 世界中（与航空等相比），由于复杂程度的提高、成本的增加等，冗余通常不会实现。在这种“约束”下，您会失去对网络故障的鲁棒性。但是，仍然可以通过将通信降至必要的最小值并创建另一种鲁棒性来利用可用资源。毕竟，机器人越能自主运行，并且仅进行必要的通信，鲁棒性就越高。
• 通常，优先级在于性能，而不是机器人的物理状态。物理损坏（例如碰撞）几乎是不可避免的，许多针对它们的加强措施会导致性能的完全下降。这个缺点表明，物理鲁棒性必须达到一定的水平，因为别忘了，这是一场你的团队必须表现出色的比赛！
这些考虑不能限定在单个 C 内，而更可能是横断面的设计标准。很明显，如果没有某种形式的鲁棒性，就很难实现性能和效率。
自主性与鲁棒性一样，是一个超越其他所有方面的设计方面。由于通信仍然对故障非常敏感，因此每个机器人能够自主运行至关重要。每个机器人的一定程度的自主性将自动导致对团队故障的鲁棒性。
设计挑战：踢足球、战术、通信、能源管理
设计约束：自主性、安全性、尺寸、重量
设计挑战与设计约束（由组织提供）相结合，形成了设计需求。尽管这些约束大多是非量化的，但这些设计需求中的许多都得到了很好的定义。即客户的这些需求：根据 RoboCup 规则踢足球。就像在每个设计环境中一样，规则是尽可能保持简单，并主要关注两个最重要的设计标准。
有关这些机器人的设计更多技术信息，请参阅 附录。
要做的事情
• 预计任何类型的通信错误的替代方案。当必须做出战术决策时，不要让机器人等待直到它拥有所有可能的信息，而是要预见一定的自主性，以便机器人即使没有所有信息也能快速做出决策。
• 意识到在选择鲁棒性而不是效率和性能或反之亦然时所做的权衡。不可能同时获得这两个标准的最大值，因此在开始之前明智地选择哪个标准具有最高优先级。
• 考虑到有限的设计时间，建议将重点放在团队上，而不是将所有精力投入到一个机器人上。因此，使用“高级设计”中描述的方法，并使用标准组件，而无需对其进行调整和重新编程，除非绝对必要。这样，可以将更多宝贵的时间和精力花在团队合作方面。通过在现场的经验，可以在系统级别进行调整。
• 预见通过使用外部链接通过线缆上传新的驱动程序或软件来将新规则实现到配置中的方法。能够在多个管理程序或比赛策略之间切换是一件明智的事情。
不要
• 通过客户端-服务器配置进行通信，这会创建一个单点故障（如前所述）。
• 尝试实现机器人可以检测到另一个机器人是否发生严重故障的功能。这很难通过通信来实现：必须发送什么信号？如果其通信系统发生故障怎么办？只有通过对其他机器人的运动进行持续的解释或反向处理，才能实现某种故障检测。