librealsense 单元测试完全指南从硬件实测到模拟设备回放【免费下载链接】librealsenseRealSense SDK项目地址: https://gitcode.com/GitHub_Trending/li/librealsense本指南以 unit-tests/readme.md 为核心系统讲解 librealsenseRealSense SDK单元测试的构建、运行与调试全流程如何在 CMake 中开启测试、如何通过live-test在真实设备上执行测试、如何在无硬件环境下借助后端录制回放机制验证软件逻辑以及如何利用 Catch 测试框架和run-unit-tests.py精确控制测试的执行范围。读完本文你将掌握一套可复现、可筛选、可离线调试的 RealSense 测试方法论。一、为什么单元测试需要两条腿走路真实设备与模拟硬件librealsense 的单元测试与普通纯软件项目有一个本质区别大量测试用例依赖真实的 Intel® RealSense™ 硬件。例如 unit-tests-internal.cpp 中的Sync sanity用例会创建rs2::context、查询设备列表并驱动传感器进行帧同步验证Extrinsic transformation between two streams is a rigid transformunit-tests-internal.cpp则直接读取设备流配置的外参矩阵做刚体变换断言。这种依赖带来的直接问题是测试失败时很难区分是设备故障、环境配置问题还是 SDK 代码缺陷。为此librealsense 在 backend 层底层 USB/UVC 传输层提供了录制与回放能力——把一次真实设备上的测试执行过程完整记录成文件再在无硬件时基于记录文件重放同样的数据流。这正是文档中./live-test into filename与./live-test from filename两个命令的由来。回放机制的底层实现在 src/media 目录中其中 playback_device.cpp 明确写道创建模拟已录制传感器的播放传感器Create playback sensor that simulate the recorded sensors即播放设备在 API 层面呈现出与真实传感器一致的接口让上层测试逻辑无需感知数据来源的差异。二、构建并运行单元测试2.1 开启 CMake 测试开关文档明确指出运行 CMake 时必须传入以下标志-DBUILD_UNIT_TESTStrue该开关在顶层 CMakeLists.txt 中被消费并在if(BUILD_UNIT_TESTS)分支内引入 unit-tests/CMakeLists.txt 的相关逻辑。此外还有两个前置条件需要注意必须开启BUILD_EASYLOGGINGPP单元测试构建依赖 easyloggingpp 日志库unit-tests/CMakeLists.txt 中会直接以FATAL_ERROR终止构建并提示Unit tests are not supported without BUILD_EASYLOGGINGPP; Check BUILD_EASYLOGGINGPP to run them.需要 Python3 解释器unit-tests.cmake 在构建期调用unit-test-config.py生成测试工程若找不到 Python3 会警告Unit tests will be limitedC 测试将无法自动生成构建目标。2.2 编译并执行 live-test按文档步骤在完成make之后make sudo make install随后执行live-test即可运行库单元测试live-test运行前请确认已有 Intel® RealSense™ 设备连接因为默认情况下大量用例属于[live]标记的实测用例详见下文测试标签体系。说明live-test是构建产物中的测试可执行入口其默认main()由 unit-test-default-main.cpp 提供内部基于 Catch2 的Catch::Session解析命令行支持--context、--debug、--rslog等自定义参数因此你也可以直接把它当作一个标准的 Catch 可执行程序使用。三、无硬件运行后端录制与回放3.1 录制一次测试流在连接真实设备的前提下将单元测试的执行过程录制到文件./live-test into filenameinto模式在 backend 层拦截底层 I/O把设备与主机之间交互的数据流原样写入文件。由于录制发生在底层传输层测试代码本身无需任何修改。3.2 基于录制文件回放换一台没有设备的机器或 CI 环境运行./live-test from filenamefrom模式以录制文件为数据源模拟设备单元测试将像操作真实硬件一样消费这些数据。这一模式的价值在于定位问题是硬件还是软件如果from回放全部通过而into实录失败则问题大概率出在设备或现场环境在多种模拟设备上验证代码同一个 SDK 构建可以针对 D415、D435 等不同型号的录制文件反复测试无需为每种型号准备物理设备。3.3 官方测试数据unit-test recordings如果你本地没有 RealSense 设备又想运行和调试单元测试项目发布了一套unit-test录制文件它们捕获了测试套件在多种硬件D415、D435 等上的预期执行过程可从项目的持续集成CI发布渠道获取。这里有两个重要提醒录制文件不含任何成像数据These recordings do not contain any imaging data因此它们只对单元测试有用——不能用来跑自己的算法如果你想基于采集数据运行算法应使用 librealsense 的 playback/record 能力相关实现见 src/media录制回放设备、ROS bag 工厂等官方文档 record-and-playback.md 与 record-and-playback-legacy-ros1.md 提供了详细说明。录制文件在构建期也会被自动下载unit-tests/live/CMakeLists.txt中通过dl_file从录制服务器拉取recording_deadlock.bag、all_combinations_depth_color.bag、[aligned_2c]_all_combinations_depth_color.bag、[aligned_2d]_all_combinations_depth_color.bag、[pointcloud]_all_combinations_depth_color.bag、single_depth_color_640x480.bag等回放素材分别供rec-play、post-processing、3D/projection等测试子目录使用见 live/CMakeLists.txt。3.4 在 CI 中复现官方测试流程除了本地运行你还可以轻松地在自己 fork 的项目上复刻官方持续集成过程——只需在 GitHub Actions 上对 fork 的librealsense启用构建即可。run-unit-tests.py会自动检测GITHUB_ACTIONS环境变量并把gha注入测试 contextrun-unit-tests.py实现与官方 CI 一致的运行上下文。四、精确控制测试执行4.1 Catch 测试框架与基础参数项目使用 Catch。默认情况下运行器只输出失败信息如需查看通过的测试列表在命令行追加live-test -d yes-d yes是 Catch 的--durations yes简写用于输出每个测试用例的执行耗时明细。Catch 还提供-r指定 reporter、-s成功用例也输出、-t列出所有测试等标准选项可直接组合使用。4.2 Python 测试运行器 run-unit-tests.py除了live-test直接跑 Catch 用例仓库还提供了更高层的 Python 运行器 run-unit-tests.py。它会自动发现构建目录中的 C 测试可执行文件test-*与unit-tests/下的 Python 测试脚本test-*.py并统一调度执行、汇总日志。常用选项如下选项作用-r, --regex re只运行名称匹配该正则表达式的测试--skip-regex re跳过名称匹配该正则表达式的测试-t, --tag tag只运行带有指定标签的测试可多次指定多个标签取交集--live/--not-live只运行有test:device指令的实测用例 / 只运行无该指令的非实测用例--device specs只在指定设备上运行如--device D455 D435隐含--live--exclude-device specs排除指定设备--repeat n每个测试重复 n 次--retry n每个测试失败后重试 n 次--rslog在测试中开启 LibRS 日志LOG_DEBUG等输出到控制台--list-tests/--list-tags只列出所有测试 / 所有标签不实际运行--no-reset测试前不重置设备--hub-reset若存在 USB Hub重置 Hub 本身--skip-disconnected无 Hub 时若所需设备未连接则跳过 live 测试--test-dir dir指定测试目录默认librealsense/unit-tests日志存放在同目录-s, --stdout测试输出直接打到控制台而不是写入日志文件-v, --verbose/-q, --quiet详细 / 安静模式--config cfg忽略测试自身配置使用给定配置--context ctx指定测试运行上下文如nightly--custom-fw-d400 fw/--custom-fw-d555 fw为 fw-update 测试指定自定义固件若与当前固件不同则刷入典型用法示例# 运行所有名称含 name 且带 log 标签的测试指定构建目录 python run-unit-tests.py -r name -t log ~/my-build-directory # 输出直接到控制台 python run-unit-tests.py -s # 只列出测试及其标签 python run-unit-tests.py --list-tests --list-tags运行器具备完善的设备管理与失败重试机制测试前自动发现设备Discovering devices ...、支持 USB Hub 端口循环利用devices.enable_only(serial_numbers, recycleTrue)失败时重试并自动重置设备最后汇总输出N unit-test(s) completed successfully见 run-unit-tests.py。4.3 标签与设备指令自动标签测试会根据所在目录自动获得位置标签例如unit-tests/log/test-all.py会被标记为[log, py]C 可执行测试则标记exePython 测试标记pylive 判定测试文件中带test:device指令如test:device D435即视为 live 测试只有连接了匹配设备才会运行--live/--not-live即基于此过滤平台/连接类型过滤测试可声明Windows/Linux平台标志和连接类型如!usb3排除 USB3运行器会按当前 OS 与设备连接类型自动跳过不匹配的用例见 run-unit-tests.py。五、测试框架的源码级架构理解测试代码的组织方式能帮助你快速新增或调试用例。5.1 自动化的构建生成unit-test-config.pyunit-tests.cmake会在构建期调用 unit-test-config.py扫描unit-tests/下所有test-*.cpp文件为每一个测试源文件生成独立的 CMake 子工程Each target is compiled in its own project, so that each file ends up in a different process。这意味着单个测试崩溃不影响其他测试进程测试之间只能通过硬件产生耦合无法通过共享进程状态互相污染。生成逻辑会递归解析#include指令把依赖的源文件加入工程find_includes并支持在测试源文件中通过注释指令定制构建行为例如//#cmake:add-file filename // 追加额外的源文件 //#cmake:custom-main // 使用自定义 main()不链接默认 main //#cmake:dependencies libs // 指定链接依赖 //#cmake:static! / //#cmake:shared!其中custom-main指令对应 unit-test-default-main.cpp 中的说明默认情况下每个测试链接默认main()支持--context、--debug、--rslog参数若测试自带main()则需定义CATCH_CONFIG_RUNNER并在源文件头部加//#cmake:custom-main。5.2 测试基础设施test.h / test.cpp提供test::context、test::debug全局变量以及test::log分级日志d/i/w/e/f输出格式如-D- message供测试用例统一打点unit-tests-internal.cppCatchTEST_CASE的集中示例展示了 libs 内部命名空间using namespace librealsense;下的测试写法覆盖流同步Sync sanity、外参标定一致性Extrinsic transformations are transitive、高级模式开关Toggle Advanced Mode、RS2_OPTION_VISUAL_PRESET预设读写等场景并大量使用disable_sensitive_options_for()关闭自动曝光等对帧内容敏感的选项以保证测试确定性algo/algo-common.h 与 live/live-common.h分别提供算法类无需硬件与实测类需要设备的公共辅助代码requirements.txtPython 测试的依赖清单包含pytest8.3.5及pytest-timeout、pytest-retry、pytest-repeat、pytest-check等插件以及numpy、opencv-python、zstandard用于校验 zstd 压缩的.db3帧等。5.3 测试目录的职责划分unit-tests/下的子目录按测试对象组织algo/、rsutils/、types/、post-processing/纯算法/工具函数测试无需硬件即可运行live/依赖真实设备的集成测试按功能细分frames/帧率与丢帧、hdr/HDR、metadata/元数据、multi_devices/多设备、rec-play/录制回放、options/传感器选项、fw/固件等log/easyloggingpp 日志行为测试dds/DDS 通信层测试含多个 mock 服务器脚本syncer/、sw-dev/软件设备与帧同步器测试wrappers/rest-api/、3D/包装层与投影算法测试。六、故障排查建议全部测试失败优先检查设备连接与固件状态用./live-test from filename在模拟数据上复跑若回放通过则基本可判定为硬件/环境问题部分测试失败使用-r regex或-t tag缩小范围配合-d yes观察耗时分布定位是特定型号设备还是特定流配置的问题需要诊断日志给live-test传--rslog开启 LibRS 内部日志等价于rs2::log_to_console(RS2_LOG_SEVERITY_DEBUG)或使用run-unit-tests.py -v在失败时自动 dump 日志无设备环境安装unit-tests/requirements.txt中的 Python 依赖直接运行python run-unit-tests.py --not-live执行无需硬件的算法测试。结语librealsense 的单元测试体系以真实硬件 录制回放双模式为核心配合 Catch 框架、自动化的逐文件构建生成unit-test-config.py和功能完备的 Python 运行器run-unit-tests.py既保证了测试对真实设备行为的覆盖又让开发者能在无硬件环境下快速复现、定位和修复问题。无论你是 SDK 贡献者、基于 fork 做二次开发还是希望在 CI 中建立 RealSense 回归防线本文介绍的构建开关、运行命令与筛选参数都值得直接落地使用。【免费下载链接】librealsenseRealSense SDK项目地址: https://gitcode.com/GitHub_Trending/li/librealsense创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 librealsense 单元测试完全指南：从硬件实测到模拟设备回放
librealsense 单元测试完全指南从硬件实测到模拟设备回放【免费下载链接】librealsenseRealSense SDK项目地址: https://gitcode.com/GitHub_Trending/li/librealsense本指南以 unit-tests/readme.md 为核心系统讲解 librealsenseRealSense SDK单元测试的构建、运行与调试全流程如何在 CMake 中开启测试、如何通过live-test在真实设备上执行测试、如何在无硬件环境下借助后端录制回放机制验证软件逻辑以及如何利用 Catch 测试框架和run-unit-tests.py精确控制测试的执行范围。读完本文你将掌握一套可复现、可筛选、可离线调试的 RealSense 测试方法论。一、为什么单元测试需要两条腿走路真实设备与模拟硬件librealsense 的单元测试与普通纯软件项目有一个本质区别大量测试用例依赖真实的 Intel® RealSense™ 硬件。例如 unit-tests-internal.cpp 中的Sync sanity用例会创建rs2::context、查询设备列表并驱动传感器进行帧同步验证Extrinsic transformation between two streams is a rigid transformunit-tests-internal.cpp则直接读取设备流配置的外参矩阵做刚体变换断言。这种依赖带来的直接问题是测试失败时很难区分是设备故障、环境配置问题还是 SDK 代码缺陷。为此librealsense 在 backend 层底层 USB/UVC 传输层提供了录制与回放能力——把一次真实设备上的测试执行过程完整记录成文件再在无硬件时基于记录文件重放同样的数据流。这正是文档中./live-test into filename与./live-test from filename两个命令的由来。回放机制的底层实现在 src/media 目录中其中 playback_device.cpp 明确写道创建模拟已录制传感器的播放传感器Create playback sensor that simulate the recorded sensors即播放设备在 API 层面呈现出与真实传感器一致的接口让上层测试逻辑无需感知数据来源的差异。二、构建并运行单元测试2.1 开启 CMake 测试开关文档明确指出运行 CMake 时必须传入以下标志-DBUILD_UNIT_TESTStrue该开关在顶层 CMakeLists.txt 中被消费并在if(BUILD_UNIT_TESTS)分支内引入 unit-tests/CMakeLists.txt 的相关逻辑。此外还有两个前置条件需要注意必须开启BUILD_EASYLOGGINGPP单元测试构建依赖 easyloggingpp 日志库unit-tests/CMakeLists.txt 中会直接以FATAL_ERROR终止构建并提示Unit tests are not supported without BUILD_EASYLOGGINGPP; Check BUILD_EASYLOGGINGPP to run them.需要 Python3 解释器unit-tests.cmake 在构建期调用unit-test-config.py生成测试工程若找不到 Python3 会警告Unit tests will be limitedC 测试将无法自动生成构建目标。2.2 编译并执行 live-test按文档步骤在完成make之后make sudo make install随后执行live-test即可运行库单元测试live-test运行前请确认已有 Intel® RealSense™ 设备连接因为默认情况下大量用例属于[live]标记的实测用例详见下文测试标签体系。说明live-test是构建产物中的测试可执行入口其默认main()由 unit-test-default-main.cpp 提供内部基于 Catch2 的Catch::Session解析命令行支持--context、--debug、--rslog等自定义参数因此你也可以直接把它当作一个标准的 Catch 可执行程序使用。三、无硬件运行后端录制与回放3.1 录制一次测试流在连接真实设备的前提下将单元测试的执行过程录制到文件./live-test into filenameinto模式在 backend 层拦截底层 I/O把设备与主机之间交互的数据流原样写入文件。由于录制发生在底层传输层测试代码本身无需任何修改。3.2 基于录制文件回放换一台没有设备的机器或 CI 环境运行./live-test from filenamefrom模式以录制文件为数据源模拟设备单元测试将像操作真实硬件一样消费这些数据。这一模式的价值在于定位问题是硬件还是软件如果from回放全部通过而into实录失败则问题大概率出在设备或现场环境在多种模拟设备上验证代码同一个 SDK 构建可以针对 D415、D435 等不同型号的录制文件反复测试无需为每种型号准备物理设备。3.3 官方测试数据unit-test recordings如果你本地没有 RealSense 设备又想运行和调试单元测试项目发布了一套unit-test录制文件它们捕获了测试套件在多种硬件D415、D435 等上的预期执行过程可从项目的持续集成CI发布渠道获取。这里有两个重要提醒录制文件不含任何成像数据These recordings do not contain any imaging data因此它们只对单元测试有用——不能用来跑自己的算法如果你想基于采集数据运行算法应使用 librealsense 的 playback/record 能力相关实现见 src/media录制回放设备、ROS bag 工厂等官方文档 record-and-playback.md 与 record-and-playback-legacy-ros1.md 提供了详细说明。录制文件在构建期也会被自动下载unit-tests/live/CMakeLists.txt中通过dl_file从录制服务器拉取recording_deadlock.bag、all_combinations_depth_color.bag、[aligned_2c]_all_combinations_depth_color.bag、[aligned_2d]_all_combinations_depth_color.bag、[pointcloud]_all_combinations_depth_color.bag、single_depth_color_640x480.bag等回放素材分别供rec-play、post-processing、3D/projection等测试子目录使用见 live/CMakeLists.txt。3.4 在 CI 中复现官方测试流程除了本地运行你还可以轻松地在自己 fork 的项目上复刻官方持续集成过程——只需在 GitHub Actions 上对 fork 的librealsense启用构建即可。run-unit-tests.py会自动检测GITHUB_ACTIONS环境变量并把gha注入测试 contextrun-unit-tests.py实现与官方 CI 一致的运行上下文。四、精确控制测试执行4.1 Catch 测试框架与基础参数项目使用 Catch。默认情况下运行器只输出失败信息如需查看通过的测试列表在命令行追加live-test -d yes-d yes是 Catch 的--durations yes简写用于输出每个测试用例的执行耗时明细。Catch 还提供-r指定 reporter、-s成功用例也输出、-t列出所有测试等标准选项可直接组合使用。4.2 Python 测试运行器 run-unit-tests.py除了live-test直接跑 Catch 用例仓库还提供了更高层的 Python 运行器 run-unit-tests.py。它会自动发现构建目录中的 C 测试可执行文件test-*与unit-tests/下的 Python 测试脚本test-*.py并统一调度执行、汇总日志。常用选项如下选项作用-r, --regex re只运行名称匹配该正则表达式的测试--skip-regex re跳过名称匹配该正则表达式的测试-t, --tag tag只运行带有指定标签的测试可多次指定多个标签取交集--live/--not-live只运行有test:device指令的实测用例 / 只运行无该指令的非实测用例--device specs只在指定设备上运行如--device D455 D435隐含--live--exclude-device specs排除指定设备--repeat n每个测试重复 n 次--retry n每个测试失败后重试 n 次--rslog在测试中开启 LibRS 日志LOG_DEBUG等输出到控制台--list-tests/--list-tags只列出所有测试 / 所有标签不实际运行--no-reset测试前不重置设备--hub-reset若存在 USB Hub重置 Hub 本身--skip-disconnected无 Hub 时若所需设备未连接则跳过 live 测试--test-dir dir指定测试目录默认librealsense/unit-tests日志存放在同目录-s, --stdout测试输出直接打到控制台而不是写入日志文件-v, --verbose/-q, --quiet详细 / 安静模式--config cfg忽略测试自身配置使用给定配置--context ctx指定测试运行上下文如nightly--custom-fw-d400 fw/--custom-fw-d555 fw为 fw-update 测试指定自定义固件若与当前固件不同则刷入典型用法示例# 运行所有名称含 name 且带 log 标签的测试指定构建目录 python run-unit-tests.py -r name -t log ~/my-build-directory # 输出直接到控制台 python run-unit-tests.py -s # 只列出测试及其标签 python run-unit-tests.py --list-tests --list-tags运行器具备完善的设备管理与失败重试机制测试前自动发现设备Discovering devices ...、支持 USB Hub 端口循环利用devices.enable_only(serial_numbers, recycleTrue)失败时重试并自动重置设备最后汇总输出N unit-test(s) completed successfully见 run-unit-tests.py。4.3 标签与设备指令自动标签测试会根据所在目录自动获得位置标签例如unit-tests/log/test-all.py会被标记为[log, py]C 可执行测试则标记exePython 测试标记pylive 判定测试文件中带test:device指令如test:device D435即视为 live 测试只有连接了匹配设备才会运行--live/--not-live即基于此过滤平台/连接类型过滤测试可声明Windows/Linux平台标志和连接类型如!usb3排除 USB3运行器会按当前 OS 与设备连接类型自动跳过不匹配的用例见 run-unit-tests.py。五、测试框架的源码级架构理解测试代码的组织方式能帮助你快速新增或调试用例。5.1 自动化的构建生成unit-test-config.pyunit-tests.cmake会在构建期调用 unit-test-config.py扫描unit-tests/下所有test-*.cpp文件为每一个测试源文件生成独立的 CMake 子工程Each target is compiled in its own project, so that each file ends up in a different process。这意味着单个测试崩溃不影响其他测试进程测试之间只能通过硬件产生耦合无法通过共享进程状态互相污染。生成逻辑会递归解析#include指令把依赖的源文件加入工程find_includes并支持在测试源文件中通过注释指令定制构建行为例如//#cmake:add-file filename // 追加额外的源文件 //#cmake:custom-main // 使用自定义 main()不链接默认 main //#cmake:dependencies libs // 指定链接依赖 //#cmake:static! / //#cmake:shared!其中custom-main指令对应 unit-test-default-main.cpp 中的说明默认情况下每个测试链接默认main()支持--context、--debug、--rslog参数若测试自带main()则需定义CATCH_CONFIG_RUNNER并在源文件头部加//#cmake:custom-main。5.2 测试基础设施test.h / test.cpp提供test::context、test::debug全局变量以及test::log分级日志d/i/w/e/f输出格式如-D- message供测试用例统一打点unit-tests-internal.cppCatchTEST_CASE的集中示例展示了 libs 内部命名空间using namespace librealsense;下的测试写法覆盖流同步Sync sanity、外参标定一致性Extrinsic transformations are transitive、高级模式开关Toggle Advanced Mode、RS2_OPTION_VISUAL_PRESET预设读写等场景并大量使用disable_sensitive_options_for()关闭自动曝光等对帧内容敏感的选项以保证测试确定性algo/algo-common.h 与 live/live-common.h分别提供算法类无需硬件与实测类需要设备的公共辅助代码requirements.txtPython 测试的依赖清单包含pytest8.3.5及pytest-timeout、pytest-retry、pytest-repeat、pytest-check等插件以及numpy、opencv-python、zstandard用于校验 zstd 压缩的.db3帧等。5.3 测试目录的职责划分unit-tests/下的子目录按测试对象组织algo/、rsutils/、types/、post-processing/纯算法/工具函数测试无需硬件即可运行live/依赖真实设备的集成测试按功能细分frames/帧率与丢帧、hdr/HDR、metadata/元数据、multi_devices/多设备、rec-play/录制回放、options/传感器选项、fw/固件等log/easyloggingpp 日志行为测试dds/DDS 通信层测试含多个 mock 服务器脚本syncer/、sw-dev/软件设备与帧同步器测试wrappers/rest-api/、3D/包装层与投影算法测试。六、故障排查建议全部测试失败优先检查设备连接与固件状态用./live-test from filename在模拟数据上复跑若回放通过则基本可判定为硬件/环境问题部分测试失败使用-r regex或-t tag缩小范围配合-d yes观察耗时分布定位是特定型号设备还是特定流配置的问题需要诊断日志给live-test传--rslog开启 LibRS 内部日志等价于rs2::log_to_console(RS2_LOG_SEVERITY_DEBUG)或使用run-unit-tests.py -v在失败时自动 dump 日志无设备环境安装unit-tests/requirements.txt中的 Python 依赖直接运行python run-unit-tests.py --not-live执行无需硬件的算法测试。结语librealsense 的单元测试体系以真实硬件 录制回放双模式为核心配合 Catch 框架、自动化的逐文件构建生成unit-test-config.py和功能完备的 Python 运行器run-unit-tests.py既保证了测试对真实设备行为的覆盖又让开发者能在无硬件环境下快速复现、定位和修复问题。无论你是 SDK 贡献者、基于 fork 做二次开发还是希望在 CI 中建立 RealSense 回归防线本文介绍的构建开关、运行命令与筛选参数都值得直接落地使用。【免费下载链接】librealsenseRealSense SDK项目地址: https://gitcode.com/GitHub_Trending/li/librealsense创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考