MoveIt 2

MoveIt 2 – definition

MoveIt 2 is the ROS 2 motion-planning framework maintained by the MoveIt community. It provides components for robot kinematics, collision checking, planning-scene management, trajectory generation, and execution through ROS 2 interfaces. Its core configuration is based on a robot description in URDF and an optional Semantic Robot Description Format (SRDF) file.

In mobile robotics, MoveIt 2 is not a replacement for a UGV navigation stack. A differential-drive platform such as Leo Rover normally uses Nav2 for global path planning, local control, obstacle avoidance, and recovery behaviors. MoveIt 2 becomes relevant when the UGV carries an articulated or controlled payload, such as a pan-tilt camera, LiDAR tilt unit, sensor mast, inspection head, or other mechanism described in URDF.

The framework represents the robot and its environment as a PlanningScene. A planner searches for a collision-free configuration trajectory between a start state and a goal state. In ROS 2 deployments, the main planning node is commonly exposed through the move_group interface and can execute trajectories through ros2_control controllers.

MoveIt 2 in a UGV architecture

MoveIt 2 and Nav2 address different planning problems. Nav2 plans the movement of the vehicle base primarily in a 2D environment, while it can use 3D sensor data for perception and costmaps. MoveIt 2 plans the state of joints or kinematic chains defined in the robot model. They can operate in one ROS 2 system, but they should not be treated as interchangeable components.

Function	Typical ROS 2 component	UGV example
Base localization and navigation	Nav2, SLAM Toolbox, AMCL	Driving Leo Rover between inspection waypoints
Joint-space or pose planning	MoveIt 2	Positioning a pan-tilt depth camera before data capture
Joint command execution	ros2_control and a trajectory controller	Sending a trajectory to a sensor-mast actuator
Environment collision representation	MoveIt 2 PlanningScene	Preventing a roof-mounted sensor unit from entering a restricted pose

A UGV model may include a virtual planar joint for the mobile base. This represents base motion in the kinematic model, but it does not automatically provide robust mobile-base navigation. The base still requires odometry, localization, a costmap, velocity control, and obstacle handling. These functions are normally implemented with Nav2 and the robot-specific base controller.

Robot model and required ROS 2 interfaces

MoveIt 2 requires a consistent transform tree, robot description, joint limits, and controller interfaces. The model must use coordinate conventions compatible with ROS standards. REP 103 defines standard units and coordinate conventions, while REP 105 defines common mobile-robot frames such as map, odom, and base_link.

For a mobile platform with an actuated sensor payload, the minimum model usually includes the following elements:

robot_description – URDF generated, for example, from a Xacro file, containing links, joints, visuals, collisions, and inertial properties.
robot_description_semantic – SRDF configuration defining planning groups, disabled collision pairs, and named states.
joint_states – ROS 2 message stream of type sensor_msgs/msg/JointState for all controllable payload joints.
tf and tf_static – transforms connecting the UGV base, payload links, sensors, and navigation frames.
ros2_control hardware and controller configuration – commonly used when a planned trajectory must be sent to physical actuators.

The base frame should remain unambiguous. For a Leo Rover deployment, a common structure is map → odom → base_link → payload_link → sensor_link. Navigation components publish or consume the first three frames, while MoveIt 2 uses the payload links to calculate allowed joint configurations and collisions.

Planning pipelines and collision checking

MoveIt 2 supports pluggable planning pipelines. The default configuration commonly uses the Open Motion Planning Library (OMPL), which provides sampling-based planners such as RRTConnect and PRM. Other planning and optimization components may be available depending on the ROS 2 distribution and installed MoveIt packages.

For UGV payloads, planning quality depends more on a correct collision model and realistic joint limits than on the choice of planner alone. Collision geometry should include the chassis, wheel envelopes where relevant, battery housing, sensor enclosure, mast, and static payload mounts. A simplified model is acceptable when it remains conservative.

The PlanningScene can receive external collision objects. For example, a mapped wall, shelf, or protected measurement area can be represented as a box, mesh, plane, or octomap-derived obstacle. This is useful when a camera mast must not rotate into a nearby structure while the rover is parked.

planning_pipelines:
  pipeline_names: [ompl]

ompl:
  planning_plugin: ompl_interface/OMPLPlanner
  request_adapters:
    - default_planner_request_adapters/ResolveConstraintFrames
    - default_planner_request_adapters/FixWorkspaceBounds
    - default_planner_request_adapters/FixStartStateBounds
    - default_planner_request_adapters/FixStartStateCollision
    - default_planner_request_adapters/FixStartStatePathConstraints
  start_state_max_bounds_error: 0.1

The value 0.1 in this example is a configuration value expressed in joint units, usually radians for revolute joints or metres for prismatic joints. It is not a universal safety limit. Limits must be set from the actuator, gearbox, mechanical stop, and payload specifications.

Use with Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive platform that can be integrated with ROS 2. Depending on the configuration, its onboard computer may be Raspberry Pi based. MoveIt 2 should therefore be assigned a narrow task with defined computational requirements, such as planning the motion of a compact sensor payload, rather than acting as the main navigation component.

A practical Leo Rover configuration can combine Nav2 for driving and MoveIt 2 for payload positioning. Before collecting an RGB-D scan, Nav2 brings the rover to a target pose. MoveIt 2 then plans a safe pan-tilt orientation. The sensor data can be published after joint motion reaches its commanded state.

Raph Rover may be suitable when the payload requires greater mass capacity, additional sensing hardware, or a larger compute unit. In research systems, this can include a multi-sensor inspection head, a stabilized camera assembly, or a LiDAR mounted on an actuated mechanism. The same ROS 2 separation applies: Nav2 controls vehicle movement, while MoveIt 2 controls the articulated payload.

Limitations in mobile-robot deployments

MoveIt 2 does not provide autonomous driving out of the box. It does not replace wheel odometry, state estimation, SLAM, costmaps, velocity smoothing, or differential-drive control. A planning result is only valid for the robot model and collision environment available at planning time.

Several limitations should be evaluated before deployment:

Planning can fail when TF data, joint states, or collision objects are stale or inconsistent.
A URDF collision model that omits cables, protruding sensors, or payload geometry can produce unsafe trajectories.
Dynamic obstacles require PlanningScene updates and, where necessary, replanning logic implemented by the system integrator.
Raspberry Pi-based configurations may require reduced collision-mesh complexity and simpler planning scenes to maintain acceptable planning latency.
MoveIt 2 trajectory execution requires a correctly configured controller and hardware interface. A valid plan alone does not move physical hardware.

Normative references and technical sources

The following primary sources define the ROS conventions and interfaces relevant to a MoveIt 2 deployment on a mobile robot:

MoveIt 2 Documentation – architecture, configuration packages, planning pipelines, PlanningScene, and ROS 2 integration.
REP 103 – standard units of measure and coordinate conventions for ROS.
REP 105 – coordinate frames for mobile platforms, including map, odom, and base_link.
ros2_control documentation – hardware interfaces, controllers, and trajectory execution concepts.
Leo Rover technical documentation – platform-specific ROS 2, hardware, and integration information.