MoveItPy() Fails to instantiate due to lack of sensor, however no 3d Sensors are in my system/defined/utilized.

[atomoclast]

Description

Attempting to use the Python API interface for MoveIt, and unable to instantiate due to No 3D sensor plugin(s) defined for octomap updates, however my system doesn't have any sensors (or any 3D sensors defined in the config/).

I did confirm in the MoveItConfigsBuilder() that sensors_3d={}, which confirms there's no sensors configured.

Your environment

• ROS Distro: Humble
• OS Version: Ubuntu 22.04
• Source Version.
• Branch: main, commit f06f38be08451c6bdeaa56c9606765f78f94f65d
• Which RMW (Fast DDS or Cyclone DDS)? FastDDS

Steps to reproduce

1. Clean install of Humble Desktop
2. Build from Source using the instructions shown here: https://moveit.ros.org/install-moveit2/source/
3. Launch a robot with no 3D sensor configured in gazebo (or hardware). (We are using a UR3e the debian packages ros-humble-ur*
4. Launch the MoveGroup that's auto-generated by MoveIt Setup Assistant.
5. Start iPython, and run:

   
   import time

generic ros libraries

import rclpy from rclpy.logging import get_logger

moveit python library

from moveit.core.robot_state import RobotState from moveit.planning import ( MoveItPy, MultiPipelinePlanRequestParameters, ) rclpy.init() logger = get_logger("moveit_py.pose_goal")

instantiate MoveItPy instance and get planning component

test = MoveItPy(node_name="test")

### Expected behaviour
I create a successful `test` instance of MoveItPy

### Actual behaviour
It fails.

### Backtrace or Console output

[WARN] [1710857505.846298791] [moveit_4286721667.moveit.ros.occupancy_map_monitor]: Resolution not specified for Octomap. Assuming resolution = 0.1 instead [ERROR] [1710857505.846321517] [moveit_4286721667.moveit.ros.occupancy_map_monitor]: No 3D sensor plugin(s) defined for octomap updates [ERROR] [1710857505.848801350] [moveit_4286721667.moveit.ros.moveit_cpp]: Failed to load any planning pipelines. [FATAL] [1710857505.848823616] [moveit_4286721667.moveit.ros.moveit_cpp]: Failed to load planning pipelines from parameter server [INFO] [1710857505.848932383] [moveit_4286721667.moveit.ros.planning_scene_monitor]: Stopped publishing maintained planning scene. [INFO] [1710857505.848944699] [moveit_4286721667.moveit.ros.planning_scene_monitor]: Stopping world geometry monitor [INFO] [1710857505.848950698] [moveit_4286721667.moveit.ros.planning_scene_monitor]: Stopping planning scene monitor

[TheSpeedM]

The No 3D sensor plugin(s) defined for octomap updates is an error that is also raised in my project (or the default ur_moveit_config for that matter) when starting up a working MoveIt config, but doesn't seem to effect the working of the project.

The line Failed to load any planning pipelines. suggest that the error is somewhere in the launch or config. You might want to look more into that. A quick search points me to a similar problem this person #2409 was having.

[atomoclast]

@TheSpeedM, Thanks for the reply! I still can't get it to work though. I have the C++ interface working fine (so I may just proceed with that for now), but I did look at #2409, and attempted to pattern match it.

I was trying to run the script within IPython, so it didn't have any config file loaded into it directly.

What I've done now is:

1. Created a yaml config that's identical to the one in the tutorials.
2. Created a launch file that creates a MoveItConfigBuilder, and passes the yaml path to the moveit_cpp() method. I then pass that to a Node() as a parameter. (with use_sim_time set to True.
3. I launch my Gazebo Launcher (it brings up Gazebo, thejoint_state_broad_caster, thecontroller_manager,rviz`, etc..
4. I launch my move_group node.
5. Try to launch the python script launch file (with use_sim_time=True as well...and it fails.

It appears it's not reading from the published /join_states from Gazebo, since it reads there's a collision (which exists in the default URDF positions since the robot is in an encloser. However in Gazebo, the robot is in a valid initial state.)

I'm not exactly sure why it's not able to read from Gazebo properly? Nor does it seem to be sending the request to the move_group node that I have running.

As I said earlier. I have both the Gazebo Launch and the Move_Group Launch files working with the C++ node I previously wrote, and I see it working with them.

Not sure where the issue is, and I've been trying to debug it. Any other potential suggestions?

Thanks!

[github-actions[bot]]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.

[github-actions[bot]]

This issue was closed because it has been stalled for 45 days with no activity.