一、仓库主要内容
二、.github文件解读
.github目录通常在一个 GitHub 项目中使用，用于存放 GitHub 提供的一些特性和工具的配置文件，在十个仓库中，.github文件里的内容是一样的，以下是文件中具体内容
名词解释：
GitHub项目
又称为Git项目，Git是一个版本管理控制系统（version control systems，缩写VCS），它可以在任何时间点，将文档的状态作为更新记录保存起来，也可以在任何时间点，将更新记录恢复回来。
1、ISSUE_TEMPLATE文件夹
这个目录用于创建 issue 模板。这些模板会在用户新建一个 issue 时显示，可以帮助用户提供详细的报告或请求。
该文件夹中的.md文件似乎只是提供了一个模板，并没有一个实际问题的描述。
名词解释：
issue模板
issue模板的目的是让项目管理者和贡献者更好地协作，准确地描述问题和贡献，让所有贡献者更加专注于项目本身，而不是浪费时间在描述和组织问题上。
关于如何创建issue模版：github如何设置issue和pr模板 - 知乎 (zhihu.com)
2，workflows文件夹
这个目录用于存放 GitHub Actions 的工作流配置文件。GitHub Actions 是 GitHub提供的一种持续集成/持续部署 (CI/CD) 服务。用户可以定义工作流 (workflows)来自动化他们的软件开发工作，比如自动测试、自动构建和自动部署。
在workflows.yml文件中，整个过程的目的是在 Docker 容器中构建和测试指定的 ROS2 软件包，并且在 GitHub Actions 中实现了这个过程的自动化。
名词解释：
GitHub Actions：
是一个持续集成和持续交付 (CI/CD) 平台，可以自动化构建、测试和部署管道，直接从 GitHub 部署代码。
持续集成和持续交付 (CI/CD)：
工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为 运维开发(DevOps)践行者。其中，“持续”并不意味着“一直在运行”，而是“随时可运行”。
工作流：
工作流（Workflow），是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。工作流建模，即将工作流程中的工作如何前后组织在一起的逻辑和规则，在计算机中以恰当的模型表達并对其实施计算。
Docker ：
docker是一个用Go语言实现的开源项目，可以让我们方便的创建和使用容器，docker将程序以及程序所有的依赖都打包到docker container，使程序可以在任何环境都会有一致的表现。
什么是Docker？看这一篇干货文章就够了！ - 知乎 (zhihu.com)
三、cyberdog_bringup文件解读
以下是文件的具体内容：
1、doc文件夹
.md文件一般是开发者对于这个项目文件进行的一个解读，在看代码时，我们也应该优先查看.md文件，在cyberdog_ws仓库中，仅有这一个文件夹的.md文件有较为详细的内容。
(1)概述
bringup 主要功能如下：
- 可根据目标配置文件（*.yaml）内的参数启动机器人内所有已配置的节点；
- 动态启动/停止某些节点（目前仅 navigation2 有需求）；
- 配置文件尽可能全的适配 ROS2 launch 内接口；
功能一解读：
目标配置文件 (*.yaml)： 这是一个 YAML 格式的配置文件，其中包含了启动机器人所需的参数和配置信息。这可能包括传感器配置、硬件设备参数、通信配置等。
节点（Nodes）： 在 ROS2 中，节点是执行实际工作的单一进程。这些节点可以提供传感器数据、执行控制算法等。通过配置文件，可以定义并启动这些节点，以满足机器人系统的需求。
功能二解读：
navigation2： 这是 ROS2 中用于导航（navigation）的软件包。导航涉及到机器人在环境中移动的问题，通常需要使用传感器数据和地图信息来规划和执行路径。
动态启动/停止节点： 这表示可以在机器人运行时动态地启动或停止某些节点，而不需要重新启动整个机器人系统。这对于灵活性和系统调试非常有用，特别是在开发导航系统时。
功能三解读：
ROS2 Launch： Launch 文件是 ROS2 中用于启动和配置节点的一种方式。它使用 XML 或者 Python 编写，提供了一种灵活的方法来定义和配置节点的启动方式。
配置文件适配 ROS2 Launch 内接口： 这表示配置文件的设计旨在与 ROS2 Launch 接口兼容。这样一来，就可以使用 ROS2 Launch 工具来管理和启动机器人系统中的节点，使系统配置更加方便和灵活。
拓展：
cyberdog_bringup 文件夹的主要功能是在 ROS2 中启动和配置机器人系统中的节点，而不是直接与嵌入式开发中的板子点亮（bringup）过程直接相关。在嵌入式系统中，"点亮板子" 通常指的是确保嵌入式板子能够正常运行，包括启动引导加载程序（Bootloader）、初始化硬件等。
cyberdog_bringup 文件夹的作用是在ROS2框架下配置和启动机器人系统的相关节点。这通常是在嵌入式系统启动的后期阶段，当ROS2运行时已经在嵌入式系统上建立起来时。这一过程并不直接涉及引导加载程序或硬件初始化，而是专注于ROS2框架中的软件层面的配置和启动。
(2)功能设计
bringup 启动约束分两类，即配置文件（*.yaml）和 命令行启动参数（argv[]），其中：
- 配置文件（*.yaml）有唯一主文件，主文件内可加载其他副文件内符合 ros 约束的参数；
- 命令行启动参数（argv[]）适配 ROS2 launch 参数接口。
就启动文件呈现形式考虑到以下问题：
- 启动约束在运行时动态加载到内存时用户不可见，不好排查分析；
- 唯一启动文件不可以同时启动多次，不好排查分析。
故启动约束将静态穷举，尽可能避免运行时动态加载，由此：
- 启动文件将在 cyberdog_bringup 编译时根据配置文件（*.yaml）动态生成；
- 且尽可能穷举参数，但也会流出动态参数入口。
- 启动文件有唯一主文件，负责启动参数约束下所有节点；
- 启动文件有不同级别的副文件，负责启动参数约束下相应节点。
(3)模块设计
- cyberdog_bringup根据配置文件（bringup.yaml, launch.yaml, node.yaml）动态生成所需的各级别的launch.py 文件。
- 自动生成的launch.py文件会根据配置参数加载手动创建的 yaml 文件或 launch 文件，做到灵活配置。
- 最终根据配置可实现启动机器人所有节点的唯一 launch.py，用于系统级别的service 调用，从而实现机器人软件功能的自动启动功能。
实现方案简单分为以下5步：
- 将复杂冗长的语法进行分类抽象，提取出必须由人工编码的环节并高度抽象为自定义的元语言；
- 用某种编码风格（比如toml，yaml，json等）对自定义元语言进行编码；
- 为上述确定的编码风格及元语言编写编译工具，也就是机器人实现自动编码功能的程序；
- 在每次编译时，自动对元语言进行编译，产生可执行脚本，并安装；
- 通过系统指令设置开机启动。
元语言：编写元程序的语言，元程序处理程序的程序
2、automatic文件夹
automatic文件夹中包含三个配置文件（*.yaml），有唯一主文件launch.yaml（#）。
以launch.yaml文件为例：
#定义了一个字典type和date
#date中还嵌套了一个列表arguments和字典param
#前面都是数据类型的定义，
type:
#这是YAML文件的顶层元素，定义了一个类型为 xxx 的数据，其中 &Xxx 是一个锚点（anchor），用于在其他位置引用。
xxx: &Xxx true
data:
#包含了不同的启动配置信息，每个配置都有一个唯一的标识符，如 bringup_test、base、sim_base 等。
bringup_test:
file_name: bringup_test.launch.py
arguments:
- {argument_int: 0, description: "int 键值对"}
- {argument_float: 0.1, description: "float 键值对"}
- {argument_bool: True, description: "bool 键值对"}
- {argument_string: string, description: "string 键值对"}
param:
cmd: null
name: null
cwd: null
env: null
additional_env: null
shell: null
sigterm_timeout: null
sigkill_timeout: null
emulate_tty: null
prefix: null
output: screen
output_format: null
log_cmd: null
on_exit: null
respawn: true
respawn_delay: 1
events:
handled:
shutdown_process: null
signal_process: null
process_stdin: null
shutdown: null
emitted:
process_started: null
process_exited: null
process_stdout: null
process_stderr: null
nodes: [bringup_test]
#这部分是一个YAML文件中的注释，用于提供关于下方 base 部分的说明。注释中的 #---------------------->;
#类似于一个分隔符，它的作用是在配置文件中提供一些可读性的分割线或标记。
#在这个特定的注释下面，有一个名为 base 的配置块，它包含了一些关于机器人系统启动的信息。具体来说：
#1.file_name: base.launch.py 表示使用名为 base.launch.py 的启动文件。
#这可能是一个ROS2中的启动文件，其中包含了启动系统所需的节点和参数配置。
#2.nodes: [connector, cyberdog_audio, device_manager, sensor_manager, motion_manager, ...]
#表示在启动时要运行的节点列表。这里列出了一系列节点的名称，包括 connector、cyberdog_audio、device_manager 等等。
#这些节点可能代表了机器人系统中的不同组件或功能模块。
#总的来说，这部分配置的含义是指定了一个名为 base 的启动配置，其中包含了要启动的节点列表和启动文件的信息。
#这些节点可能涉及机器人的音频处理、设备管理、传感器管理、运动控制等各个方面的功能。
#------------------------------------------------------------->
base:
file_name: base.launch.py
nodes: [connector, cyberdog_audio, device_manager, sensor_manager, motion_manager, realsense2_camera, cyberdog_manager, odom_out_publisher, motor_bridge, cyberdog_grpc, bes_transmit, cyberdog_vp_engine, cyberdog_face, cyberdog_action, cyberdog_interactive, cyberdog_train, cyberdog_ai_sports]
#------------------------------------------------------------->
sim_base:
file_name: sim_base.launch.py
nodes: [connector, sim_device_manager, sim_sensor_manager, motion_manager, cyberdog_grpc, cyberdog_audio]
#------------------------------------------------------------->
navigation_bringup:
package_name: navigation_bringup
file_name: navigation.launch.py
#------------------------------------------------------------->
factory_base:
file_name: factory_base.launch.py
nodes: [factory_sensor_manager]
#------------------------------------------------------------->
cyberdog_sudo:
file_name: cyberdog_sudo.launch.py
nodes: [cyberdog_permission, cyberdog_wifi, cyberdog_ota, cyberdog_bluetooth, unlock_request]
3、bringup文件夹
manual.py文件中含有四个函数，分别实现了预处理：仅处理命令行参数、获取 shell 指令结果、获取计算机 MAC 地址和获取 namespace的功能。
4、config文件夹
test.yaml配置文件虽然叫test，但他是用于配置的设置，而不是用于测试。它定义了一系列的ROS参数，包括整数、布尔值、浮点数和字符串，以及这些值的向量形式。这些参数配置可能用于指定机器人系统的初始状态、行为规则或其他方面的配置。
四、third_party文件解读
third_party文件中是一些第三方的库。
以下是文件的具体内容：
cpp-httplib 是个开源的库，是一个c++封装的http库，使用这个库可以在linux、windows平台下完成http客户端、http服务端的搭建，这是一个多线程“阻塞”HTTP 库。
filesystem库是C++17标准的一部分，它的出现填补了C++长久以来在文件和目录操作方面的空白，C++ Filesystem库提供了一系列用于文件和目录操作的API，包括但不限于创建、删除、复制文件和目录，以及查询文件属性等。而在编程世界中，文件和目录操作是不可或缺的一部分。无论是在开发一个复杂的数据分析工具，还是一个简单的文本编辑器，都需要与文件系统进行交互。
mqttc库提供了实现MQTT协议的功能，方便C++开发者在其应用程序中使用MQTT进行通信。MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（publish/subscribe）模式的“轻量级”通讯协议，是主机之间的通信协议，该协议构建于TCP/IP协议上。
nvinference中是对NVIDIA TensorRT 库的实现，NVIDIA TensorRT是一个用于加速深度学习模型推理的库，它通过一系列优化技术和硬件加速功能，提供高性能的推理解决方案，可用于各种深度学习应用，包括计算机视觉、自然语言处理、语音识别等。这使得深度学习模型能够在实时应用中更快速地做出预测和推断。但这里貌似只用于处理日志输出。
rapidjson 是一个 C++ 的 JSON 解析器及生成器。
toml引用了toml11库，toml11一个用于解析和处理 TOML（Tom's Obvious Minimal Language）格式文件的 C++ 库。TOML 是一种配置文件格式，旨在具有简单性和易读性。
xpack是一个文件资源打包工具及类库，可以对文件进行打包、解压。
zxing是一个生成二维码的框架。
五、tools文件解读
以下是文件的具体内容：
tools里一般是项目需要使用到的工具方法代码，存放一些工具方法代码，一般存放项目自定义的工具方法代码，非第三方工具方法代码。
ci_check.sh
#!/bin/bash
#这是一个 shebang 行，用于告诉系统使用哪个解释器来执行脚本。在这里，它指定了 Bash 解释器。
colcon test --merge-install --event-handlers console_cohesion+ --return-code-on-test-failure --packages-select $S1
#这个脚本是使用 colcon 构建和测试 ROS 2 工程中特定的软件包。具体的软件包名称由 $S1 确定。
#colcon 是一个用于构建和测试 ROS 2 (Robot Operating System 2) 工程的工具。connector.sh/connector.zsh
.sh 和 .zsh 文件都是 shell 脚本文件的扩展名，用于存储命令和命令序列。Shell（基于C语言）是一个命令行解释器，它为用户提供了一个向Linux内核发送请求以便运行程序的界面系统级程序，用户可以用Shell来启动、挂起、停止甚至是编写一些程序。例如执行 mkdir 就是创建一个文件夹, 执行 touch 就是创建一个文件. 执行 ps 就是查看进程信息。
在这里.sh和.zsh中的内容基本上是一样的（除了.sh第一行有#!/bin/bash语句指定由Bash解释器执行脚本），是为了适应不同的 shell 环境。这样，用户可以根据其偏好或系统配置选择使用 Bash 还是 Zsh 来运行这个脚本。
#!/bin/bash
#这段脚本主要是处理命令行参数，根据参数执行不同的操作，最后执行一个 ROS2 服务调用来连接到指定的 WiFi 网络
ARGS=`getopt -a -o hs:n:p:i: -l help,connect_srv:,wifi_name:,wifi_password:,provider_ip:, -- "$@"`
#@"‘‘：∗∗这一行使用‘getopt‘工具来解析命令行参数。‘−a‘表示使用传统的getopt方法，
# ‘−o‘和‘−l‘分别指定短选项和长选项。‘−−‘表示选项结束，‘"
#这是一个用于打印帮助信息的函数。它包含了脚本的使用说明，各种选项的说明，以及一些示例用法
help_info() {}
#这是一个用于检查必选参数是否存在的函数。
judge_parameter_must() {}
#这是一个用于检查可选参数是否存在的函数。
judge_parameter_optional() {
}
[ $# -eq 0 ] && help_info
#set -- "${ARGS}"
eval set -- "${ARGS}"
while true
do
case "$1" in
-h|--help)
help_info
;;
-s|--connect_srv)
connect_srv="$2"
shift
;;
-n|--wifi_name)
wifi_name="$2"
shift
;;
-p|--wifi_password)
wifi_password="$2"
shift
;;
-i|--provider_ip)
provider_ip="$2"
shift
;;
--)
shift
break
;;
esac
shift
done
judge_parameter_must provider_ip
judge_parameter_optional connect_srv
judge_parameter_optional wifi_name wifi_password
if [[ -z "$connect_srv" ]];then
namespace=`ros2 node list | grep "mi_" | awk 'NR==1' | cut -f 2 -d "/"`
if [[ -n "$namespace" ]];then
connect_srv="/$namespace/connect"
else
connect_srv="/connect"
fi
fi
echo "ros2 service call $connect_srv protocol/srv/Connector \"wifi_name: '$wifi_name'"
echo "wifi_password: '$wifi_password'"
echo "provider_ip: '$provider_ip'"
echo "\""
ros2 service call $connect_srv protocol/srv/Connector "wifi_name: '$wifi_name'
wifi_password: '$wifi_password'
provider_ip: '$provider_ip'
"
cyberdog_wifi.service
Linux中.service文件是某项服务对应的配置文件，可用于systemd管理和控制的服务的设置。
.service 文件通常包含3个模块，即[Unit]控制单元，表示启动顺序和依赖关系；[Service]服务，表示服务的定义；[Install]安装，表示如何安装配置文件。
linux 之.service文件简介_Tian_cy_的博客-CSDN博客
这个单元文件的目的是定义一个名为 "cyberdog wifi service" 的服务，它会在系统启动时被启动，并在空闲时运行。服务运行的命令是 ros2 run wifi wifi，并且如果服务失败，则会尝试自动重启。
Dockerfile
Dockerfile，用于构建基于 arm64v8/ubuntu:bionic 镜像的环境，构建基于 arm64v8/ubuntu:bionic 镜像的环境是指在 Docker 中创建一个新的容器镜像，，并且在此基础上执行一系列操作以配置和安装特定的软件包、工具和设置。
reboot_cyberdog.sh
提供了在运行时重新启动两个与 Cyberdog 机器人相关的 systemd 服务，以应用配置更改或者确保服务处于正确的状态。
其他分享：了解一些常见的软件项目文件夹命名 - 知乎 (zhihu.com)
开源文档参考：https://miroboticslab.github.io/blogs/#/
开源源码参考：https://github.com/MiRoboticsLab/cyberdog_ws
扫一扫
1002
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
