RoboMaster

标题: 【RM2020-仿真系统开源-项目简介开源】华南理工大学华南虎 [打印本页]

作者: Mentos_Seetoo 时间: 2020-9-19 17:50
标题: 【RM2020-仿真系统开源-项目简介开源】华南理工大学华南虎
1. 本次开源项目出自华南理工大学华南虎战队，作品仅用于技术交流，未经作者允许，不得作任何商业用途。
2. 转载须注明作品出处，对非法转载者，作者保留采用法律手段追究的权利。

   本文首先提出了一种“仿真-迭代的开发模式”，并介绍了搭建仿真系统的一种思路，然后通过多个演示实例来对这种开发模式和仿真系统进行验证与总结，希望可以为各参赛队提供一种新的思路，以提高竞赛机器人的开发效率，挖掘、应用更高水平的技术。

一、概述
为什么要开发仿真系统？
   机器人系统仿真是指通过计算机对实际的机器人系统进行模拟的技术，国外很早就意识到仿真在机器人研究种的重要性，从上世纪70年代就开始研究，目前大部分的开源、商业的机器人仿真软件都来自国外。
   通过使用仿真软件，我们可以确定机器人的本体及工作环境的动态变化过程。一方面在制造出实物前就进行机械结构的模拟，可以避免不必要的返工，例如在各战队中比较常见的使用Adams对结构进行仿真验证和优化设计。另一方面，在机器人竞赛的备赛过程中，机械组的前期设计和搭建实物的过程比较长，控制组的代码完成得比较快，如果等实物出来再进行代码调试和算法验证的话，整个迭代周期就会变长，而且也有可能发生控制组失误导致机器人受损返修的情况。
   因此从2019赛季起，我们尝试开发合适的仿真系统，把仿真环节加入到整个机器人的开发流程。与以往单纯的迭代开发不同，我们在项目开发后和整机测试前都对机器人的部分或者整体进行仿真，如机械结构部分使用Adams、Matlab仿真机器人的云台力矩和控制，控制组使用CoppeliaSim和Matlab仿真步兵整体的运动控制和联合视觉部分代码去打神符、自瞄等动作逻辑。更重要的是，结合我们已有的电控的软件结构，可以轻松地把这些逻辑与底层驱动解耦开，对业务代码单独进行验证，节省了时间和硬件成本，关于这部分在后面内容中会有解释。

[attach]27584[/attach]

如何选择合适的仿真软件？
考虑到Robomaster比赛中常用的是移动机器人的仿真，而机械机构的仿真软件已经有很多参赛队成功应用，所以本文主要介绍用于仿真机器人整体的软件。目前可供选择的机器人仿真软件有很多，可分为如CoppeliaSim(V-REP 4.0+)、Gazebo、Webot等，他们各有自己的特点，详细对比可以参考这篇博客，大家可以根据自己队伍的情况选择适合自己的仿真软件。为了能让仿真环节发挥更大的作用，或者说仿真的软件系统和仿真效果上更接近实际机器人，我们希望仿真软件能有良好的接口支持外部用户程序的接入，以及能够在仿真环境内编辑物体的模型、脚本和各种属性，以便实现更多的自定义功能。基于以上需求，我们选择使用CoppeliaSim，主要用到了该软件下面的几个特性：

CoppeliaSim是免费、开源的，支持完整的仿真功能，并且可以使用多种编程语言，其中包含C++。我们可以用远程客户端应用编程接入仿真环境。
CoppeliaSim支持跨平台运行，方便电控和视觉进行联调。
CoppeliaSim可以直接从Solidworks导入我们建好的机器人模型，也可以环境内编辑三维模型，而且带有各种丰富的传感器模块，方便模拟装甲板打击、神符打击、弹药箱夹取等效果。

二、仿真系统的搭建
软件结构
在上文提到，机器人整体仿真部分的软件更关注的不是对各种贴图、纹理、和动力学进行高精度仿真，而是能初步验证机器人上的逻辑代码、控制算法对环境的响应。所以，为了使仿真环节的软件系统更接近于实际机器人，我们设计了下图的结构。在这种结构下，仿真环境中运行的和真实机器人上运行的是同一份代码。

[attach]27585[/attach]

其中仿真的通信接口主要使用官方提供的通信接口（Legacy remote API），我们的代码相对于CoppeliaSim作为客户端运行。

[attach]27587[/attach]

   对于视觉算法部分的同学来说，他们只需把RGB、深度图等图像的获取接口改成从仿真软件获取。所有的代码可直接运行在用于机器人的已配置好环境的NUC平台，通过网线或者WIFI与CoppeliaSim运行的主机组建局域网，使用CoppeliaSim提供的基于TCP的API与仿真环境进行通信，获取图像信息即可。
   对于电控的同学来说要做的工作可能会稍微多一点，但如果有Demo project的话移植起来也很快。首先，在MCU上运行的代码需要有良好的结构，可以把底层驱动和其他与硬件有关的模块解耦开。其次，我们需要一个带RTOS的环境支持其他部分代码的运行。CoppeliaSim软件运行的平台是在Windows上所以为了提供RTOS的环境，我们使用FreeRTOS的Windows Simulator（最近好像也推出了Linux Simulator）模拟运行MCU上的部分代码。
   例如，MCU上的软件可以采用类似“微服务+分层”的架构，把MCU软件要实现的功能划分为独立的模块，把每个功能分层实现，这样就可以把控制机器人逻辑的状态机，控制各驱动元件的算法，决策规划算法等部分与底层的硬件驱动解耦，每个功能可以单独测试而不需要依赖硬件，直接使用对应平台（WIN32）的API代替原来的驱动层和各种通信服务，文件系统服务。事实上对于robomaster比赛中的机器人来说，很多机器人的底层的驱动和工具中间件都是一样的，如果把这些模块的接口都统一了之后，那么我们机器人上的核心代码和CoppeliaSim通信的接口也就可以统一了，最终大部分的机器人（除了飞镖、基站、无人机）都可以用同一套封装好的接口去访CoppeliaSim获取环境数据，实现快速移植和配置。下图为MCU的软件结构，SRML（SCUT-RobotLab Middleware Library）为常用中间件库（不在本次开源范围内）。

[attach]27586[/attach]

使用简述
至此，讨论了这么多，似乎看上去很麻烦，但是其实操作起来简单易上手，可以参考博客。整个搭建过程简单分为下面几步（下面用到的资源在Github仓库的Demo中均可找到，Readme会持续更新更加详细的介绍，如遇到问题请发Issue）：
1. 导入、编辑模型
把我们要用的场地模型、道具模型、机器人模型逐一导入，设置物体的颜色、场景亮度、发光属性，摄像头的参数设置等（主要影响视觉识别效果）。如果优化得好实际上获得的图片可以和真实获得图片非常像。导入过程可使用sw中的URDF插件先导出模型，或者直接导出stl再到CoppeliaSim里面组合起来。导出模型的时候需要把机器人按照运动副分割开不同的零件。

[attach]27588[/attach]

2. 设置动力学属性
   动力学属性在使用urdf插件导入时已经自行设置好，但如果是使用stl导入的话就要自行设置。
3. 编写服务端（CoppeliaSim）脚本
   有需要的话可自行添加各种模块，如装甲板被击中后的检测，子弹发射模块，场地道具等脚本的编写。在主脚本使能远程通信。
4. 在客户端程序中配置Remote API
   Legacy Remote API是官方提供的一个跨平台适用的，可以与CoppeliaSim直接进行通信的一套API。为了方便使用，我们把常用的函数封装成一套简单的接口（coppeliasim-client），Windows下直接包含相关文件夹，配置包含路径即可使用。Linux下可链接文件夹中写好的CMakeLists.txt，作为静态库加入到自己的项目中。

[attach]27589[/attach]

三、演示示例
在进行涉及控制算法的仿真时，要注意仿真通信带来的延迟的影响，以及数据不同步的问题。所以在某些情景下我们采用的是CoppeliaSim提供的同步模式，即离线仿真。
1. 步兵电控、视觉联合仿真Demo
Github:https://github.com/scutrobotlab/coppeliasim_infantry.git

[attach]27615[/attach]

[attach]27618[/attach]

[attach]27617[/attach]

2. 结合Matlab工具箱Simulink完成系统辨识与其他算法的调试
知乎:https://zhuanlan.zhihu.com/p/254889446
3. 其他兵种演示
工程取弹（测试版）

[attach]27590[/attach]

无人机模拟（第一视角观察）

[attach]27591[/attach]

哨兵自瞄、躲避决策。

[attach]27592[/attach]

如果主机算力够猛也许可以整支战队进行联动

四、总结与改进
   总的来说，使用CoppeliaSim对机器人场景进行仿真模拟还是比较简单的，网上也有很多教程。相对来说CoppeliaSim在国内的中文教程和经验博客还是比较少，在Youtube上有比较多的教学视频，如果有需要后面也可以把我们总结出的教程和大家分享。受疫情影响在家云备赛的这段时间，我们的步兵组、工程组、哨兵组和无人机组都在仿真环境中完成了电控、视觉代码的测试和联调，在回校后除了硬件部分外，其他部分在实物上进行参数调整就可以有不错的效果。在形成一套固定的模式和软件工程后，新队员从零基础到上手仿真测试只需要一周时间。
   如果要真正地在整个开发流程中发挥仿真软件最大的威力，一方面需要我们熟悉仿真软件的运行机制和动力学的特性，使整个物理效果更接近实物；另一方面也需要我们去考虑优化机器人上软件的结构，对软件系统进行解耦和接口统一，尽可能地提高团队的开发效率，降低每个人的学习成本。到目前为止，我们仿真结果和实物结果完整的对比分析还没做完，这是今后需要进一步完善的地方。
   虽然不同的战队使用的仿真环境不一样，但我们希望可以通过搭建合适的仿真环境，来促进队员们用更低的硬件成本和时间成本来把更多理论应用到robomaster的机器人上