Skip to main content
Version: 10

Robot Hardware And Cameras Troubleshooting

Cannot connect to RealSense camera​

Problem: I cannot connect to my Realsense camera.

Solution: Reconnect the RealSense camera and confirm that the host detects it before debugging ROS:

lsusb | grep -i realsense
lsusb -t
realsense-viewer
apt list --installed 'librealsense2*'

Use a USB 3 port and cable. If realsense-viewer is missing or cannot open the device, install librealsense by following the maintained upstream Linux distribution instructions for the host Ubuntu release, including its udev rules. Do not install packages from an older Ubuntu release.

Cannot launch RealSense after performing driver update​

Problem: RealSense streams no longer launch after updating librealsense or the ROS wrapper.

Solution: Do not use the removed moveit_studio/bin/install_librealsense.sh script or install the old Focal package versions. Confirm the installed components and rebuild the workspace after changing them:

realsense-viewer --version
ros2 pkg prefix realsense2_camera
sudo apt update
sudo apt install ros-jazzy-realsense2-camera ros-jazzy-realsense2-description
# If this workspace builds the RealSense wrapper from source, rebuild and source it:
colcon build --symlink-install --packages-up-to realsense2_camera
source install/setup.bash

Install librealsense from one source only; mixing distribution packages, the vendor repository, and source installs can load incompatible shared libraries. Check the maintained RealSense ROS wrapper documentation for its current librealsense compatibility guidance.

RealSense node messages that "reduced performance is expected"​

Problem: One of the cameras does not come up properly when MoveIt Pro is launched:

[realsense2_camera_node-15] [RealSenseCameraNode]: Device 123456789012 is connected using a 2.1 port. Reduced performance is expected.

Solution: 1. Verify that the cable and USB port are both rated USB 3. 2. Unplug the cable from the camera and the computer and plug it back in. 3. Open the realsense-viewer and perform a hardware reset by clicking “More” and selecting “Hardware Reset”. 4. Try connecting a different cable.

Cannot configure the Robotiq gripper on a Universal Robot​

Problem: When I launch my Universal Robot equipped with a Robotiq gripper, I get an error message Cannot configure the Robotiq gripper and cannot control the gripper.

Solution: If you have both the "Robotiq Grippers" and "rs483" URCap installed, they have compatibility problems. Disable the "Robotiq Grippers" URCap. Refer to Example UR5 Hardware Setup Guide for details.

Camera panes lag behind the robot​

Problem: Video is smooth but visibly behind reality, and the same camera looks noticeably more responsive in a viewer that reads the camera's own stream directly.

Solution: This happens when a camera that already produces an encoded stream is being decoded to raw frames, republished on a ROS topic, and re-encoded for the browser. Each step adds delay to arrive at the same picture. Relay the camera instead, by listing it in MOVEIT_WEBRTC_PASSTHROUGH as comma-separated <ros topic>=<source url> pairs:

MOVEIT_WEBRTC_PASSTHROUGH=/cameras/head/image_raw=rtsp://robot.local:8554/head

Set it in the environment moveit_pro run inherits, or in the deployment's .env; Compose forwards it into the container that runs the video server.

The pane is unchanged in the UI — the topic still appears in the camera list and still opens at the same place. Only the route its pixels take changes: the stream is passed through to the browser without being decoded or re-encoded.

Notes:

  • Only list a topic whose frames originate as an encoded stream. A simulated camera publishes raw images with no upstream URL and must keep the default path.
  • An RTSP source is pinned to TCP. Relayed cameras are usually reached across a tunnel or NAT where UDP is dropped, and probing UDP first costs seconds before the first frame appears.
  • A pair the video server cannot use — a topic containing anything but letters, digits, _, ., - and /, or a URL that is not rtsp/rtsps/rtmps/ https/srt/wheps — is skipped with an ignoring MOVEIT_WEBRTC_PASSTHROUGH entry line in the video server's log. Cleartext rtmp:// and http:// are refused deliberately: their TLS forms reach the same sources, and a relayed camera is remote by definition. That topic falls back to the ROS encode path, so the symptom is the original latency; check the log if a camera you listed did not get faster.
  • The ROS topic keeps publishing, so anything subscribing to it — recording, perception Behaviors — is unaffected.