机器人ROS自动驾驶【免费下载链接】navigation2ROS 2 Navigation Framework and System项目地址https://gitcode.com/gh_mirrors/na/navigation2点击查看免费下载导读本文以 nav2_docking/README.md 为骨架系统讲解 ROS 2 Navigation 框架中的自动停靠Docking任务服务器。你将掌握 DockingServer 的五大组件架构与停靠/拔出完整流程、dock 实例与 dock 插件双层建模方式、DockRobot/UndockRobot 动作接口与语义化错误码以及SimpleChargingDock从配置到视觉闭环控制的全部参数用法并了解如何通过行为树把停靠能力接入实际应用任务。一、框架定位应用层的停靠任务服务器Open Navigation 的 Docking 框架位于 nav2_docking/是一套自动机器人停靠框架及辅助工具集。它的核心设计思想是通过可插拔的dock插件实现让框架能够泛化到多种不同的机器人——不同运动学模型、不同充电方式、不同传感器模态、乃至非充电的停靠需求。同时框架内置一个停靠点数据库DockDatabase支持在一个异构环境中管理大量不同位置、不同型号的停靠点。需要特别强调的是它的调用位置约定这个任务服务器设计为由应用层行为树application BT或自主应用在完成任务后、或电量低时调用而不是在navigate-to-pose动作内部调用——不过undock拔出动作可以例外地从导航动作内部调用。这一约定保证了停靠逻辑与导航逻辑的清晰分层。框架被拆分为 4 个包包名职责opennav_docking主停靠框架DockingServer、Controller、DockDatabase、Navigator、简单插件opennav_docking_core停靠插件抽象头文件每种 dock 类型需实现的接口opennav_docking_bt停靠/拔出行为树节点及示例 XMLnova_carter_docking基于 NVIDIA Nova Carter 机器人平台的参考实现外部仓库维护本项目由 NVIDIA 赞助、Open Navigation LLC 创建Docking 框架的 ROSCon 2024 演讲与演示视频可在 Open Navigation 公开渠道获取。二、五大核心组件DockingServer、Navigator、DockDatabase、Controller 与插件根据 nav2_docking/README.md 的 Architecture 章节停靠框架由 5 个主要组件构成DockingServer执行停靠/拔出动作的主动作服务器与核心逻辑。它是一个nav2::LifecycleNode节点名为docking_server在配置阶段创建dock_robot与undock_robot两个 action server见 docking_server.cpp。Navigator一个NavigateToPose动作客户端当机器人不在预停靠prestaging容差范围内时负责把机器人导航到停靠点的 staging pose。从源码看它通过独立回调组与SingleThreadedExecutor在停靠动作内部嵌套调用导航动作并会在失败时自动重试一次navigator.cpp。DockDatabase环境中停靠点实例及其对应接口插件的数据库支持任意数量的 dock 类型。Dock结构体把pose、frame、type、id与plugin指针绑定在一起types.hpp。Controller基于螺旋线spiral的 graceful 控制器用于停靠的视觉控制闭环。其底层复用nav2_graceful_controller::SmoothControlLaw并通过CostmapTopicCollisionChecker做轨迹碰撞检测controller.cpp。ChargingDock 与 NonChargingDock 插件描述 dock 并定义与之交互方式是否充电、检测方式等的插件插件头文件位于opennav_docking_core包中。ChargingDock与NonChargingDock插件是整个框架可定制性的核心通过它们你既能对接充电站也能对接非充电基础设施——例如静态位置传送带或动态位置托盘、可移动货架。对于动态停靠目标动作请求可以携带一个近似停靠位姿由视觉控制闭环在运动过程中持续精化。DockDatabase则用来描述这些停靠点在环境中的位置任何数据库内的停靠点都可以在停靠请求中被选用。三、停靠与拔出完整工作流程3.1 停靠流程8 步按原文档停靠过程如下接收动作请求获得 dock 的插件及其位姿若机器人不在 dock 的 staging pose 的预停靠容差内导航到 staging pose调用插件startDetectionProcess()方法激活任何外部检测机制利用插件完成初始检测getRefinedPose返回停靠位姿进入视觉控制闭环机器人向停靠位姿行进同时该位姿被视觉系统持续精化检测到接触或充电已开始如适用后退出视觉控制闭环等待充电开始如适用返回成功调用插件stopDetectionProcess()方法停用外部检测机制。若流程中任意一步失败在第 8 步之前会进行最多N次重试先退回 dock 的 staging pose再从第 3 步重新开始。重试仍失败则返回一个语义化失败码告知客户端失败类型。源码印证dockRobot()依次执行“解析 dock → 检查是否已停靠/充电 → 导航至 staging pose →doInitialPerception→rotateToDock可选→approachDock闭环 →waitForCharge→ 成功收尾/异常重试”异常分支严格对应DockingException子类与错误码docking_server.cpp。一个值得注意的细节approachDock会把目标位姿沿 dock 朝向向后投影 0.25 mbackward_projection目的是避免螺旋控制器在接近终点时因atan2抖动而过早减速确保机器人在接触 dock 前始终有驱动余量docking_server.cpp。3.2 拔出流程3 步拔出逻辑更简单若此前已停靠利用已知的 dock 信息确定 dock 类型否则使用拔出动作请求中指定的 dock 类型找到该 dock 的 staging pose倒退back out至该位姿检查是否成功退出到该位姿、且充电已停止。源码印证undockRobot()会先根据上次停靠记录或请求中的dock_type解析插件检查机器人确实在 dock 上随后在控制前反复调用disableCharging()避免带电流拔出损伤触点再用getCommandToPose以undock_linear_tolerance/undock_angular_tolerance判定是否到达 staging pose最后以hasStoppedCharging()判定拔出成功docking_server.cpp。四、动作与服务接口4.1 停靠动作DockRobot.action停靠动作既可以操作DockDatabase中的某个 dock也可以操作停靠请求中直接指定的 dock后者适合测试或当 dock 位置事先未知时。use_dock_id true时用dock_id字段指定数据库中的 dock否则必须填充dock_pose与dock_type字段。若希望 DockingServer 帮你把机器人布置到 staging posenavigate_to_staging_pose必须为true否则可自行把机器人送到该位姿只要机器人处于预停靠容差内导航会被跳过。max_staging_time用于设置导航的最大时间。动作结果包含num_retries实际重试次数、success是否成功停靠并开始充电、error_code语义化错误码详见 DockRobot.action。执行过程中可通过反馈获知当前停靠状态state、已用时间docking_time与当前重试次数。动作反馈状态机定义于 DockRobot.action状态值含义NONE0无状态NAV_TO_STAGING_POSE1正在导航至 staging poseINITIAL_PERCEPTION2正在执行初始感知CONTROLLING3正在视觉控制闭环中逼近WAIT_FOR_CHARGE4已接触等待充电开始RETRY5正在重试停靠动作错误码DockRobot::Result错误码值含义NONE0无错误GOAL_REJECTED1目标被拒绝SEND_GOAL_FAILURE2发送目标失败DOCK_NOT_IN_DB901dock 不在数据库中DOCK_NOT_VALID902dock 插件无效FAILED_TO_STAGE903导航到 staging pose 失败FAILED_TO_DETECT_DOCK904未检测到 dockFAILED_TO_CONTROL905控制失败FAILED_TO_CHARGE906充电未开始TIMEOUT907超时UNKNOWN999未知错误这些异常类型在 docking_exceptions.hpp 中均有对应类DockNotInDB、DockNotValid、FailedToStage、FailedToDetectDock、FailedToControl、FailedToCharge并在 docking_server.cpp 中一一映射到上述错误码。4.2 拔出动作UndockRobot.action拔出动作布局类似。请求包含dock_type——若 DockingServer 曾将机器人停靠到当前 dock该字段可选否则必须提供以便在配置了多个 dock 插件时取得 staging pose只有单一插件时会使用默认值。另有max_undocking_time作为脱离 dock 失败的超时上限。结果同样包含success与语义化error_codeUndockRobot.action且不提供反馈。4.3 重载数据库服务ReloadDatabase Service该服务用于在 dock 数据库加载后用一份新的 dock 文件重新加载。只需在请求中提供新停靠点集合的filepath即可。服务实现于 dock_database.cpp它通过try_lock互斥量保证停靠进行中不允许重载数据库解析成功后整体替换dock_instances_。服务名称为~/reload_database消息定义见 ReloadDockDatabase.srv。五、停靠点建模dock 实例Instances与 dock 插件Plugins规范停靠点需要区分两个要素Dock 实例instances地图中某个具体位置的 dock数据库中可能包含多个已知 dock可按名字指定停靠哪个。Dock 插件plugins每一类 dock 的模型抽象包含通用性地检测、连接特定 dock 型号的能力。这种分离让你能够以较少配置高效管理大量不同位置、甚至不同硬件修订版本的停靠点。5.1 插件定义参数文件内dock 插件在参数文件中定义如果你熟悉 Nav2 其他服务器的插件模式这会非常眼熟。注意其中不含任何 dock 位姿或实例信息——这些是 dock 型号的通用属性如 staging pose、启动充电命令、检测方式等。你可以在 dock 的命名空间下按需添加额外参数例如timeoutdock_plugins: [dockv1, dockv3] dockv1: plugin: my_custom_dock_ns::Dockv1 dockv3: plugin: my_custom_dock_ns::Dockv3 timeout: 10.05.2 实例定义两种方式方式一嵌入 DockingServer 配置文件的docks参数适合只有少数几个 dock 的场景。指定插件类型与 dock 在某一坐标系下的位置[x, y, theta]docks: [dock1, dock2] dock1: type: dockv3 frame: map pose: [0.3, 0.3, 0.0] id: kitchen_dock dock2: type: dockv1 frame: map pose: [0.0, 0.0, 0.4] id: 42方式二外部 YAML 文件通过dock_database参数指定文件路径文件布局如下docks: dock1: type: dockv3 frame: map pose: [0.3, 0.3, 0.0] id: kitchen_dock dock2: type: dockv1 frame: map pose: [0.0, 0.0, 0.4] id: 42字段规则源码行为见 utils.hpptype与pose必填pose必须是长度为 3 的数组否则解析失败type可留空字符串前提是环境中只有一种 dock 类型此时findDockPlugin会默认返回唯一插件见 dock_database.cppframe缺省为map位姿可以位于任意坐标系odom、base_link等数据库与动作请求均支持id可选例如用于关联对应的 AprilTag若 dock 插件不使用它可省略。仓库还附带了一份测试用 dock 数据库样例 test_dock_file.yaml以及用于验证解析失败路径的坏文件缺少 type/pose、坐标转换错误等可帮助你理解解析规则。六、Dock 插件 API必须实现的六个关键函数插件接口在opennav_docking_core包中定义ChargingDock是抽象基类charging_dock.hppNonChargingDock继承它并把isCharging/disableCharging/hasStoppedCharging固定为抛异常non_charging_dock.hppisCharger()恒为false。6.1 位姿相关的两个函数getStagingPose(pose, frame)把 dock 位姿变换为用于进入停靠机动动作的 staging pose。若机器人不在预停靠容差内Nav2 会把机器人移动到该位姿。实现通常基于 TF 与 dock 位姿套用相对 dock 位姿的静态/参数化偏移。getRefinedPose(pose, id)利用传感器精化 dock 位姿。根据机器人检测 dock 的方式可能使用激光扫描数据或相机数据。6.2 停靠逼近中的两个函数isDocked()机器人逼近 dock 时此函数告诉控制器何时停止前进。实现方式依硬件而定若充电 dock 在充电开始前会通信可在这里实现握手若需要发送“enable”指令这里也是合适的发送点若充电 dock 无任何通信可通过电机力矩/电流检测接触或判断速度是否降为零最简情况下若没有其他反馈isDocked可直接调用isCharging。isCharging()逼近在isDocked报告后停止然后反复调用isCharging等待充电开始。可用sensor_msgs/BatteryState消息检查电源状态或充电电流。仅充电型插件使用。6.3 拔出中的两个函数disableCharging()拔出开始前调用防止充电触点磨损。若充电 dock 支持关闭充电电流应在此完成。仅充电型插件使用。hasStoppedCharging()控制器拔出过程中调用。当充电已停止且机器人回到 staging pose 时拔出成功。仅充电型插件使用。⚠️ 注意所有停靠/拔出函数都应快速返回因为它们会在控制闭环内被调用阻塞会卡死控制循环同时应保证isDocked在isCharging为 true 时也返回 true。接口还提供了两个关键查询方法getDockDirection()返回DockDirection{FORWARD, BACKWARD, UNKNOWN}决定机器人正走还是倒走进入 dockshouldRotateToDock()决定是否先原地旋转 180° 背对 dock 再倒行进入用于无检测的倒车停靠。七、开箱即用的 SimpleChargingDock 与 SimpleNonChargingDock这两个插件是带大量常用选项的参考实现对部分机器人可能已完全可用类声明见 simple_charging_dock.hpp 与 simple_non_charging_dock.hpp插件注册见 plugins.xml。7.1 getStagingPose对 dock 位姿施加参数化的平移与旋转偏移得到 staging pose沿 dock 朝向平移staging_x_offset并叠加staging_yaw_offset航向角simple_charging_dock.cpp。7.2 getRefinedPose 的两种用法盲法逼近返回的 dock 位姿直接等于 dock 数据库传入的位姿。在真实机器人上成功率可能下降受全局定位误差影响但对初始测试与仿真很有用此时start/stopDetectionProcess通常为空操作。更真实的用法使用 AR 标记、dock 位姿检测算法等。插件会订阅geometry_msgs/PoseStamped话题detected_dock_pose可与image_proc/TrackMarkerNodeAprilTag或其他自定义检测器配合。检测到的位姿未必就是要停靠的位姿因此提供若干参数来表达“docked pose 相对被检测特征 pose”的偏移。检测管理的灵活性源码实现见 simple_charging_dock.cpp对detected_dock_pose的订阅可通过subscribe_toggle参数动态管理外部检测进程可通过服务调用触发detector_service_name指定的 Trigger 服务超时由detector_service_timeout控制DockingServer会在getRefinedPose循环调用之前调用startDetectionProcess()在停靠动作结束无论成败后调用stopDetectionProcess()——这让插件可以在不需要时释放 GPU 等资源只在需要时运行检测。7.3 isDocked 的两种检测选项堵转检测检查轮子关节状态joint_states当电流/力矩超过设定阈值表明机器人已接触 dock 或其他物理物体位置阈值比较 dock 位姿与机器人位姿距离低于docking_threshold时isDocked返回 true。源码中堵转判定为关节平均速度低于stall_velocity_threshold且平均力矩高于stall_effort_thresholdsimple_charging_dock.cpp位置判定则为基座到 dock 位姿的距离小于docking_threshold。7.4 isCharging / hasStoppedCharging 的两种选项订阅sensor_msgs/BatteryState话题battery_state当消息current字段超过charging_threshold时视为充电中源码中即is_charging_ state-current charging_threshold_直接返回isDocked()为 true 即视为充电——适用于初始测试或低可靠性停靠尚无电池状态等信息的阶段。注意使用battery_state还是isDocked()由use_battery_status参数决定。7.5 调试话题可用于 RVizTopic描述类型dock_pose当前已变换的dock 位姿geometry_msgs/PoseStampedfiltered_dock_pose当前未变换的dock 位姿geometry_msgs/PoseStampedstaging_posedock 的 staging posegeometry_msgs/PoseStamped此外控制器还会在docking_trajectory话题发布碰撞检测用轨迹controller.cpp。八、完整参数参考8.1 DockingServer 参数参数描述类型默认值controller_frequency视觉控制闭环控制频率Hzdouble50.0initial_perception_timeout等待获得 dock 初始感知的超时sdouble5.0wait_charge_timeout停靠后等待充电开始的超时sdouble5.0dock_approach_timeout视觉控制逼近闭环尝试超时sdouble30.0rotate_to_dock_timeoutrotate-to-dock 闭环尝试超时sdouble10.0undock_linear_tolerance拔出控制闭环在 staging pose 的线距离容差mdouble0.05undock_angular_tolerance拔出闭环在 staging pose 的角容差raddouble0.05max_retries最大重试次数int3base_frame控制律使用的机器人基座坐标系stringbase_linkfixed_frame固定坐标系建议使用平滑的里程计系而非 mapstringodomodom_topic里程计数据话题stringodomrotation_angular_tolerance启用 rotate_to_dock 时退出旋转闭环的角容差raddouble0.05dock_prestaging_tolerance与 staging pose 的 X、Y、Theta L2 距离小于则跳过导航double0.5dock_plugins要加载的 dock 插件集合vectorstringN/Adock_database该环境使用的 dock 数据库文件路径stringN/Adocks替代dock_database直接在参数文件中指定的 dock 集合vectorstringN/Anavigator_bt_xmlNavigator 使用的 BT XML非默认时stringcontroller.k_phiphi 变化率与 r 变化率之比控制慢子系统收敛double3.0controller.k_delta航向误差反馈的常数因子控制快子系统收敛double2.0controller.beta路径曲率的常数因子必须为正决定曲率增大时速度下降快慢double0.4controller.lambda路径曲率的常数因子必须 ≥ 1决定弯道锐度lambda 越大弯越急double2.0controller.v_linear_min最小线速度m/sdouble0.1controller.v_linear_max最大线速度m/sdouble0.25controller.v_angular_max控制律产生的最大角速度rad/sdouble0.75controller.slowdown_radius目标位姿附近开始减速的半径mdouble0.25controller.deceleration_max最大减速度m/s²用于按距离计算速度上限v sqrt(2 * dist * deceleration_max)double2.5controller.rotate_to_heading_angular_vel启用 rotate_to_dock 时旋转至目标航向的角速度rad/sdouble1.0controller.rotate_to_heading_max_angular_accel旋转至目标航向的最大角加速度rad/s²double3.2controller.use_collision_detection是否使用碰撞检测避障booltruecontroller.costmap_topic使用的 costmap 话题stringlocal_costmap/costmap_rawcontroller.footprint_topic机器人 footprint 话题stringlocal_costmap/published_footprintcontroller.transform_tolerance变换发布后置时间表示该变换在未来有效的时间double0.1controller.projection_time碰撞前瞻时间sdouble5.0controller.simulation_time_step投影仿真的时间步长sdouble0.1controller.dock_collision_threshold距 dock 位姿多近时忽略碰撞mdouble0.3必填项dock_plugins与docks或dock_database二选一缺一不可。参数解析与动态校验在 parameter_handler.cpp 中实现负数参数更新会被拒绝controller_frequency必须 0且除插件命名空间含.的参数外的大多数参数支持运行时动态更新加锁后写回params_。另外注意一个已废弃参数dock_backwardsbool仍可读但会打印弃用警告请改用插件内的dock_direction参数。8.2 SimpleChargingDock 参数参数描述类型默认值use_battery_statusisCharging()使用电池状态消息还是isDocked()booltrueuse_external_detection_pose使用外部检测话题还是数据库位姿boolfalseexternal_detection_timeout最新检测更新超过该时间则判定失败double1.0external_detection_translation_x检测位姿到停靠位姿的 X 偏移mdouble-0.20external_detection_translation_y检测位姿到停靠位姿的 Y 偏移mdouble0.0external_detection_rotation_yaw检测位姿到停靠位姿的偏航偏移raddouble0.0external_detection_rotation_pitch俯仰偏移raddouble1.57external_detection_rotation_roll横滚偏移raddouble-1.57filter_coef外部检测方法的滤波算法系数double0.1charging_threshold电池状态电流高于此阈值时isCharging() truedouble0.5use_stall_detectionisDocked()使用堵转检测还是位置阈值boolfalsestall_joint_namesjoint_states话题中要跟踪的关节名vectorstringN/Astall_velocity_threshold触发isDocked() true的关节速度下限double1.0stall_effort_threshold触发isDocked() true的关节电流/力矩阈值double1.0docking_threshold不使用堵转检测时到停靠位姿的isDocked() true位姿阈值double0.05staging_x_offsetstaging pose 相对 dock 位姿的前向偏移负值向前mdouble-0.7staging_yaw_offsetstaging pose 相对 dock 位姿的角度raddouble0.0dock_direction机器人正向还是反向进入 dockstringforward或backwardrotate_to_dock启用无传感器检测的倒车停靠机器人正向到达 staging pose传感器可覆盖 dock 检测检测后原地旋转、仅凭初始检测位姿做航位推算倒进 dockboolfalsedetector_service_name启动/停止检测器的 Trigger 服务名如相机节点或 AprilTag 检测节点留空禁用服务调用stringdetector_service_timeout等待检测服务可用或响应的超时sdouble5.0subscribe_toggletrue 时在start/stopDetectionProcess调用时动态订阅/退订detected_dock_posefalse 且use_external_detection_pose为 true 时订阅保持整个插件生命周期适合检测节点常开常发boolfalse⚠️ 两个重要提示外部检测的旋转角度默认值为在image_proc与isaac_ros的 AprilTag 检测器下开箱即用而设计外部检测的旋转顺序在 ROS2 L-turtle 中已变更为 Rx → Ry → Rz原为 Rz → Rx → Ry。仅在以下情况保持旧行为external_detection_rotation_yaw等于 0.0或external_detection_rotation_pitch与external_detection_rotation_roll均等于 0.0。此外源码中rotate_to_dock与dock_direction存在一致性校验启用rotate_to_dock时dock_direction必须为backward否则配置阶段直接抛错simple_charging_dock.cpp。8.3 最小可用配置示例仓库测试配置 docking_params.yaml 展示了完整的最小配置骨架docking_server: ros__parameters: wait_charge_timeout: 1.0 controller: use_collision_detection: false transform_tolerance: 0.5 dock_plugins: [test_dock_plugin] test_dock_plugin: plugin: opennav_docking::SimpleChargingDock use_battery_status: true dock_direction: forward rotate_to_dock: false staging_yaw_offset: 0.0 docks: [test_dock] test_dock: type: test_dock_plugin frame: odom pose: [10.0, 0.0, 0.0] tolerance: 0.5九、行为树集成把停靠接入应用任务opennav_docking_bt提供DockRobot与UndockRobot两个 BT 动作节点头文件 dock_robot.hpp它们继承nav2_behavior_tree::BtActionNode。DockRobot节点暴露的端口与动作目标一一对应use_dock_id、dock_id、dock_pose、dock_type、max_staging_time、navigate_to_staging_pose以及输出端口success、num_retries和错误码/错误消息端口。示例行为树 application_example.xml 演示了典型的“拔出 → 执行任务 → 回桩充电”应用root main_tree_to_executeMainTree BehaviorTree IDMainTree Sequence nameApplicationTaskWithDocking !-- Force application success so we always attempt docking -- ForceSuccess Sequence !-- Undock the robot if currently on dock to start -- ReactiveFallback nameUndockIfDocked inverter IsBatteryCharging/ /inverter UndockRobot dock_type{dock_type} error_code_id{undock_robot_error_code} error_msg{undock_robot_error_msg} / /ReactiveFallback !-- Token Application -- NavigateToPose goal{picking_location} .../ Wait wait_duration5/ NavigateToPose goal{placing_location} .../ Wait wait_duration5 .../ /Sequence /ForceSuccess !-- Always dock back at charger at end -- DockRobot dock_id{dock_id} error_code_id{dock_robot_error_code} error_msg{dock_robot_error_msg}/ /Sequence /BehaviorTree /root注释中还给出了“低电量触发停靠”的常见改法用ReactiveFallback包一层inverterIsBatteryLow min_battery0.2//inverter加DockRobot dock_id{my_dock}即可在电量低于阈值时自动回桩。这与 README 反复强调的“停靠由应用层调用、而非嵌入 navigate-to-pose 内部”的设计一致。十、关于 Staging Poses 的设计考量Staging pose 是机器人为了开始停靠流程而需要导航到的位置。它的选取需要权衡足够近以便准确检测到 dock 的存在足够远保证即使 dock 位置略有偏移、或机器人定位不够完美仍然能检测到 dock并有足够的调整空间。同时在这个 staging pose 上机器人的充电触点或充电位置应朝向 dock。这样全局规划器就能以真实的机器人约束非圆形、非全向的运动学来建模到达停靠位姿的路径而不是让停靠过程本身变得更复杂。这正是 8.1 节中dock_prestaging_tolerance默认 0.5 m 的 L2 距离存在的意义机器人在容差内即认为已就位可直接进入视觉闭环。十一、源码级验证与测试如果你想深入验证上述行为仓库提供了完整的测试支撑单元测试test_dock_database.cpp、test_controller.cpp、test_simple_charging_dock.cpp、test_navigator.cpp 等分别覆盖数据库解析、控制律、插件行为与导航客户端集成测试test_docking_server.py 与 test_docking_server_unit.cpp 覆盖停靠服务端的完整动作流程坏文件用例test/dock_files/下test_dock_bad_*、test_dock_no_*系列文件用于验证数据库解析的错误路径BT 节点测试test_dock_robot.cpp 与 test_undock_robot.cpp。编译依赖上opennav_docking依赖nav2_graceful_controller螺旋控制律、nav2_costmap_2d碰撞检测、nav2_msgs动作/服务定义、pluginlib插件加载与nav2_ros_common完整依赖清单见 package.xml 与 CMakeLists.txt。总结OpenNav Docking 框架把“停靠”从导航动作中剥离出来做成一个由应用层调用的独立任务服务器DockDatabase 负责“在哪里停靠”dock 插件负责“怎么与 dock 交互”Controller 负责“怎么精确逼近”Navigator 负责“怎么先到 staging pose”DockingServer 负责把这一切编排成带重试与语义化错误码的动作流程。通过实现ChargingDock/NonChargingDock接口、配置 dock 实例数据库与SimpleChargingDock的参数即可为任意运动学、任意充电方式、任意传感器配置的机器人搭建完整的自动停靠与自动充电能力。赞分享机器人ROS自动驾驶【免费下载链接】navigation2ROS 2 Navigation Framework and System项目地址https://gitcode.com/gh_mirrors/na/navigation2点击查看免费下载相关推荐Zeek NetControl 框架实战指南统一网络主动响应 API 与插件架构解析Zeek NetControl 框架实战指南统一网络主动响应 API 与插件架构解析 NetControl 是 Zeek 内置的网络主动响应框架它用一套任务网络安全网络IDS5步精通Unity游戏插件框架BepInEx实战配置全解析5步精通Unity游戏插件框架BepInEx实战配置全解析 Unity游戏插件框架BepInEx为游戏模组开发者提供了完整的解决方案通过其独特的Doorst游戏开发插件系统Dotbot自动化测试框架构建可靠的配置验证流程Dotbot自动化测试框架构建可靠的配置验证流程 引言 在软件开发中配置管理是一个至关重要的环节。特别是对于dotfiles点文件这种用于配置用户环境的开发工具上一篇Azure OpenAI AI Search第三方登录完整指南OAuth集成实现详解下一篇移动端AI提速4倍Paddle-Lite量化方案全解析PTQ与QAT实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考