目录
一、研究策略说明
在上一章中，描写最先进的机器人软件框架，每个都有其优点和缺点。在本章中，我们举例说明我们的研究目标和战略，这将导致提出的框架在接下来的章节中描述。
二、研究目标
在硬件和硬件上提供一个好的框架非常重要软件领域，因此可以在不花钱的情况下开发机器人资源太多，主要是时间和金钱。以前的作品要么很擅长软件或硬件领域，但似乎成为他们之间缺失的一环。
有时，预打包的算法仅适用于那些对于实际应用来说过于复杂。而不是浪费时间为更简单的系统重新实现这些算法，这很常见为机器人配备更强大的计算机。这将是一个价格和性能矫枉过正，没有它就不能变成未来的产品在设计过程的某个阶段进行重新设计。又是这么强大计算机可能不适合特定的机器人域，因为所需的尺寸和重量；想想一个四旋翼，它不能装备台式电脑。由于这些原因，我们将专注于嵌入式系统在我们的研究中。
2.1 框架设计
我们不会提出一个全新的软件框架，而是要针对嵌入式系统开发增强现有的框架。如前一章所述，一些像 LCM 和 R2P 这样的作品已经在嵌入式平台上可用，但两者都缺少用户级设备库的可用性。相比之下，ROS 有很多可以使用的包，但 ROS 本身并不适合嵌入式系统。通过扩展现有框架，仍然可以利用它们的优点，同时尝试解决其缺点，或至少部分解决。框架被设计成模块化的，我们研究的目的是让简单、廉价的外围模块以原生方式与中央框架模块（通常是工作站）进行通信。占用空间小 然而，嵌入式系统的开发总是应对一些资源限制。一个嵌入式系统，关于一个台式计算机或工作站，通常对内存有严格的限制大小、CPU 速度和时序。当今天赐良机的微控制器配备大约 1 MB 的代码存储器（ROM、EEPROM、闪存）256 kB RAM 和 200 DMIPS。
虽然无法完全托管完整的框架，但微控制器仍然可以管理框架本身的原生通信协议。一块嵌入式硬件仍将与框架通信开箱即用，可以运行预打包的算法，并且无需需要代理或桥接器来处理不同的协议。相比之下，ROS 有很多可供使用的包，但 ROS 本身并不适合嵌入式系统。通过扩展现有框架，仍然可以利用它们的优点，同时尝试解决其缺点，或至少部分解决。框架被设计成模块化的，我们研究的目的是让简单、廉价的外围模块以原生方式与中央框架模块（通常是工作站）进行通信。
2.2 可移植性
提议的框架也应该是可移植的。这是一个棘手的嵌入式系统领域的特点，因为硬件抽象层
即使在同一系列的设备之间也几乎不兼容。此外，嵌入式系统编译器通常落后于通用计算机的编译器；这最新的编程语言（或其更新）不可用，或者编译器实现不完全符合标准。
2.3 便利性
最后但并非最不重要的一点是，代码应该易于使用。一个简单的 使用简单的代码、良好的文档和实用工具进行设计可以使 开发过程更高效，更不容易出错。由于目标 我们的工作是快速机器人原型设计，它必须被理解和修改 尽可能短的时间，以便用户可以专注于他们的目标，而不是 关于软件框架库本身。
综上所述，增强型系统应具备以下特点：
• 支持现有框架；
• 小代码/内存占用；
• 在不同的硬件/软件架构之间移植；
• 简洁干净的设计。
三、设计策略
我们的工作是现有框架的扩展。其中描述的在第 2 章介绍的最新技术中，我们发现最适用于快速原型设计目的的是 ROS。它的发展是最活跃，并且数百个完全模块化的包的可用性缩短发展时代。相反，它缺乏嵌入式系统的观点不鼓励将其用于简单系统，尽管有一些解决方法（例如，rosserial）。
我们提出的框架，称为 µROSnode，旨在运行在嵌入式系统。事实上，习惯了 ROS 的用户仍然可以使用它的打包在中央计算机上，并部署在外围模块上可以与 ROS 进行原生通信。
微控制器上原生 ROS 支持的一个结果是，它将是可以将基于 µROSnode 的设备直接连接到基于 ROS 的网络。
以一个简单的机器人为例，如图 3.1a 所示，由 iRobot 制成创建通过 RS232、Sick LMS100 [27] 以太网控制的 [13] 移动底座激光扫描仪，以及尚未设计的定制 IMU 板。这些设备是连接到运行使用它们的 ROS 应用程序的主机。作为它们不直接与 ROS 通信，主机必须运行自定义 ROS与它们的低级驱动程序连接到 ROS 本身的节点。
取而代之的是图 3.1b 中的示例。激光扫描仪运行经过修改的利用可用的以太网端口，基于 µROSnode 的固件；这从头开始设计的定制 IMU 板围绕 µROSnode 进行编程；
一个廉价的适配器板将 RS232 移动机器人平台连接到通过廉价的适配器板进行以太网。有了这种设计，用户只有将它们连接到 ROS（例如，通过以太网电缆连接到主机）并开始开发应用程序，而不用担心底层协议或设备驱动程序。这种设计简化了新想法的原型制作，并且为用户提供同质 API。
3.1 通信策略
ROS 的通信栈（见第 4 章）不是为资源受限的平台设计的（不像 LCM 和 R2P），而是为了便于不同编程语言库的集成。无论如何，它仍然可以保持它的实现足够小以部署在微控制器上，正如第 6 章所证明的那样。ROS 对于内存受限系统的一个主要缺陷是它通过点对点 TCP 通道进行通信，大多数次。这种选择会影响带宽、RAM 分配和线程，因为每个通道都需要自己的管理，而使用广播方法（UDP 能够）它们是按主题统一的，而不是按通道统一的。 ROS 协议的 UDP 版本在撰写本文时仍处于试验阶段，因此我们必须处理为每个 TCP 连接分配一个通道的问题。尽管存在设计缺陷，但我们将证明 TCP 方法对于基于微控制器的简单系统来说不是主要问题。例如，它们几乎无法使 100 Mbps 以太网链路饱和，并且用户知道微控制器可管理的同时连接数量相当少。
1）具有传统集中式 ROS 适配器节点的设备
这里解释一下器件：
- SICK是激光雷达：
- IMU惯性检测单元：
2）使用 µROSnode 的 ROS 就绪设备
3.2 编程语言策略
我们的目标之一是软件可移植性。在嵌入式系统领域，可移植性基本上只由一种编程语言 ANSI C 来保证。这种语言可广泛用于当今的嵌入式系统。由于其成熟度，几乎所有嵌入式级 C 编译器都可以管理用纯 ANSI C 编写的代码。这确保了由 ANSI C 兼容编译器生成的目标代码可以正常工作，而其他语言并不总是如此。此外，用 ANSI C 编写的软件仍然与大多数 C++ 和 Objective C 编译器兼容，因此仍有可能将其与这些更高级的语言以本地方式集成，或者通过编写惯用的包装器。顺便说一句，完整 C++ 实现的某些特性（例如 RTTI、异常）只会因为它们被启用而使目标代码的大小爆炸，从而超过 MCU 代码内存大小。没有它们的 C ++ 只是带有一些语法糖的 C，这是一种冗余，还有前面所述的不合规风险。
3.3 系统抽象
实现嵌入式系统的软件可移植性也通过适当的硬件抽象层。我们的设计包括绑定到硬件的低级功能，以便用户可以编写或者选择与目标架构最匹配的低级驱动程序。
我们的框架需要用于通信、多线程、和内存管理。通信库与 TCP/IP 堆栈通信以一种常见的方式。
需要一个多线程环境，因为它极大地简化了开发复杂的固件，多线程环境引入的开销在现代 MCU 上是微不足道的。
内存管理驱动程序应该处理动态分配（例如，内存堆）。所有这些功能通常由适当的操作提供系统，并且绑定的编写相当简单。
为在通用计算机上部署而选择的 API 是 POSIX，这在大多数操作系统中都可用。对于微控制器，我们选择了 ChibiOS / RT，它支持一些最当今可用的高级微控制器，以及 LWIP 作为其 TCP/IP 堆栈。
3.4 编码风格和工具
拟议框架的设计，广泛在第 5 章中描述的，由一些抽象实体组成，它们被管理
通过简单干净的软件界面。模块化方法也是反映在包的文件系统结构上。
代码大部分遵循 ChibiOS/RT 的风格规则，来源于典型的 K&R（Kernighan 和 Ritchie）风格。还有其他编码规则以可移植性为目标（例如 MISRA 规则），但我们认为 K&R 派生的样式仍然是最干净和易懂的。该代码还具有Doxygen 的广泛自我文档，一个广泛的自我文档工具。
为用户提供代码生成器，可以生成模板通过指定所需的主题、服务、以及它们各自的消息类型。
静态分析器可以通过估计一组函数（线程的入口点）的总堆栈使用情况来帮助针对内存受限平台的开发。总之，我们研究的增强框架具有以下主要特点：
• 与 ROS 通信栈的原生兼容性；
• ANSI C 编写的代码；
• 为 POSIX 和 ChibiOS / RT + LWIP 预配置；
• 简单的模块化设计；
• 对 Doxygen 进行了广泛的自我记录；
• 用于用户应用程序消息管理的代码生成器；
• 静态堆栈使用分析器。