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