Is it possible to configure environment server with empty collision map?
I have a robot with an arm_navigation stack configured to use a collision map, and it works fine. However, if arm_navigation is started with no visible environment obstacles, the environment server will not complete its configuration sequence and disallow planning motions. This is the typical output:
Waiting for environment server planning scene registration service /register_planning_scene
Publishing an empty point cloud does not seem to make the environment server happy, so is there a way about this use case?. Currently I'm publishing a dummy cloud with a single point outside the workspace of my robot (a hack that works in the meantime).
Further details on what's going on: An environment server instance is not completely constructed because it gets stuck in a loop, which requires waking up this CollisionSpaceMonitor callback to break it.
Edit The problem statement can be generalized to saying that apparently the collision map is not updated when an empty point cloud is published. I'm using the collider node, and with an already configured environment server, the octomap cells are not updated if I go from an environment with obstacles to one without any.
TIA.
While we are still waiting for a proper solution, what about starting the environment server with "use_collision_map:=false" and then restart it with "true", once a populated collision map is available?
The use_collision_map parameter is read only once in the constructor of the environment server, so unfortunately that won't work.
I meant, shutting down the whole environment server and then bringing it up again. In this way the use_collision_map parameter will be read again. Maybe ros::shutdown() + the restart parameter in roslaunch could do the trick.
You could think of doing that. It just seems a more complicated hack than the one I already have in place, which is to publish a minimal obstacle slightly outside the reach of the robot _until_ the environment server successfully initializes. Note that this is _still_ a hack, though.
Reported as Issue 5198, so it does not get lost.