Separate the Two Failure Modes
The reported UR3e system showed two distinct symptoms: MoveIt initially marked every robot state as colliding, and later accepted a planned trajectory without moving the physical robot. Do not treat either symptom alone as proof of a ROS-to-robot communication failure. In this case, the robot eventually moved through the test trajectory after the configured joint limits were corrected, confirming that the control path could operate.
| Observation | Supported conclusion | Next check |
|---|---|---|
| Every MoveIt state is red or orange | The planning scene or robot model requires investigation. | Inspect collision meshes, attached-tool modeling, and MoveIt shell output. |
| MoveIt reports successful execution but the robot remains stationary | Successful planning does not prove physical execution. | Run the trajectory-controller test independently. |
| Robot moves after correcting joint limits | The ROS-to-UR control connection is functional for that test. | Concentrate troubleshooting on the MoveIt configuration and model. |
Verify the Control Path Independently
The reported network used robot address 192.168.0.4, PC address 192.168.0.2, Docker host-network address 172.17.0.1, and container address 172.17.0.2. The control launch command assigned reverse_ip:=192.168.0.2. Those values document the arrangement but do not, by themselves, prove that the reverse connection is routable through Docker.
- Launch
ur_control.launch.pywith the stated robot and reverse addresses. - Start the External Control program on the teach pendant using the configured host address.
- Run
test_joint_trajectory_controller.launch.pybefore adding MoveIt. - If the test goal violates the configured joint limits, correct the limits in
test_goal_publishers_config.yamland repeat the test. - Confirm physical motion and review the launch-terminal output. In the reported case, the robot moved after the joint-limit correction.
ros2 launch ur_bringup ur_control.launch.py ur_type:=ur3e robot_ip:=192.168.0.4 launch_rviz:=false reverse_ip:=192.168.0.2 limited:=true
ros2 launch ur_bringup test_joint_trajectory_controller.launch.pyDiagnose the MoveIt Collision State
Once the independent test moves the robot, stop diagnosing the issue as a general ROS-UR connection failure. The remaining evidence points toward the MoveIt path, with the robot meshes specifically identified as a possible cause. Capture the output from the shell running MoveIt while planning and executing; a visually successful RViz action can conceal the distinction between planning, controller acceptance, and physical motion.
An end effector was physically attached but not represented in the URDF. That mismatch is relevant to collision-model accuracy, but the evidence does not establish it as the cause of the persistent collision indication. Inspect the planning-scene geometry and collision meshes for overlap at the current joint state, then retest planning only after the displayed state is collision-free.
Keep Calibration Separate from Execution
The available evidence states that calibration should not be directly connected to whether commands execute. It also notes that ur_calibration was not found in the Foxy branch, but does not establish whether its absence is expected or identify a supported replacement. Do not use that package observation as proof of the no-motion cause.
Use the physical test trajectory as the decision boundary: if it fails, continue checking controller output, goal limits, and network reachability; if it succeeds, investigate MoveIt, its robot description, and collision geometry. This prevents calibration and model-accuracy questions from obscuring a separately verified execution path.
FAQ
Why does MoveIt show every UR3e state in collision?
The evidence does not identify a confirmed root cause. Inspect the MoveIt shell output, planning-scene geometry, and UR collision meshes, especially when the physical tool is not represented in the URDF.
Why does the UR3e plan successfully in RViz but not move?
Planning success does not confirm physical execution. Run test_joint_trajectory_controller.launch.py; in this case, correcting the joint limits in test_goal_publishers_config.yaml allowed the robot to move and isolated the remaining fault to the MoveIt path.
Can missing UR3e calibration data prevent all robot motion?
The supplied evidence says calibration should not be directly connected to whether commands execute. Verify motion with the trajectory-controller test before investigating calibration or model accuracy.
