Planning and Control Troubleshooting
Unclear reason for failure of PlanMTCTask motion planning behavior
Problem: My PlanMTCTask behavior fails with error code PLANNING_FAILED.
Solution: Activate MoveIt Studio's solution instrospector by clicking the bug icon on the PlanMTCTask node in the behavior tree to inspect each stage's solutions/lack of solutions and better understand the nature of the failure. If you are already familiar with the Rviz Motion Planning Tasks plugin you can also use it by launching the Developer RViz configuration:
moveit_pro rviz
Unclear planning scene state
Problem: I am unclear about the the current state of the planning scene.
Solution: Launch the Developer RViz configuration and use the Planning Scene widget view the scene robot and geometry used by MoveIt:
moveit_pro rviz
Robot is stuck in collision
Problem: The robot arm got into collision during jogging-based teleoperation and the robot cannot be moved.
Solution: To resolve the collision, use MoveIt Pro's Jog Collision Checking to carefully disable collision checking and jog the arm out of the collision. If the collision occurred during jogging-based teleoperation and collided with an object modeled in the planning scene, this can occur if the rate of arm movement is greater than the rate of collision checking. To increase the rate of collision checking, the following parameters can be tweaked in the MoveIt Servo YAML configuration file in your robot configuration package:
collision_check_rate: 10.0 # [Hz] Collision-checking can easily bog down a CPU if done too often.
You must restart MoveIt Pro for these changes to take effect.
Missing Info messages in the UI
Problem: I am not seeing logged messages published at the Info level appear as a "Toast" message in the top right corner of the UI:
I have a line in my custom behavior
shared_resources_->logger->publishInfoMessage(...);that I expect to run but I don't see the logged message coming through in the UI.
Solution: Change the log level output in the UI by pressing the log level bell icon in the top right corner of the UI and checking the info level box.
Joint values cannot be copied from joint jog panel
Problem: When I attempt to copy joint values from the joint jog panel in MoveIt Studio, I see the following message in MoveIt Studio:
Text cannot be copied over an insecure (non-HTTPS) connection.
Solution: If possible, access MoveIt Studio in your browser via localhost and not an IP address.
Multi-machine Solution: Since most distributed systems using MoveIt Pro are on a closed network, the web-based user interface is hosted as an insecure connection without HTTPS. Browsers may attempt to enforce various protection strategies from insecure connections, such as prevention of text copying. To enable all features of the user interface, make sure to allow insecure connections in your browser settings. When running MoveIt Pro locally, you can set Chrome to allow insecure connections from local hosts. However, on a multi-machine set-up the web UI is hosted at a separate IP address and Chrome may not be as permssive. Allow insecure connections, by clicking on the title bar and selecting "allow insecure connections".
Docker compose returns an error requiring unique items
Problem: When I attempt to start a docker service using docker compose (for example docker compose exec dev bash), I see the following error:
validating /home/user_ws/docker-compose.yaml: services.agent_bridge.device_cgroup_rules array items[0,2] must be unique
Solution: Make sure you are using the same docker-compose.yaml as MoveIt Pro to start the service.
Details: The docker-compose.yaml in your user workspace requires a unique definition for each service the MoveIt Pro Developer Platform uses (without duplicates on later versions of MoveIt Pro and docker-compose). If you attempt to start a different service with a name that is currently in use (such as docker compose exec dev ... while MoveIt Pro is running) you will see an error like this.
The moveit_pro run command loads your MoveIt Pro configuration before starting the docker services, so running docker compose without all the configuration parameters defined in your environment will result in a different service than one that was started with moveit_pro.
If you redefine some parameters in the user workspace docker-compose.yaml, such as cgroup rules, an error will also occur.
We recommend first removing any erroneous duplicated service definitions from the docker-compose.yaml and then utilizing moveit_pro shell or moveit_pro dev to enter a shell within the MoveIt Pro container, which can help prevent some such errors from occurring.
Note: If you use moveit_pro configure to change your user workspace while MoveIt Pro is running, moveit_pro shell may return this error.
The robot I see with moveit_pro rviz does not match the robot in the Visualization panel on the web interface
Problem: Using RViz I see a different robot (or robot configuration) than the one I see in the MoveIt Pro web UI
Solution: Make sure your configuration package's config.yaml uses the same URDF as the robot_state_publusher.
Details: When setting launch_robot_state_publisher: False in config.yaml MoveIt Pro will expect the node to be launched by another process. It is the responsibility of that process to load the same URDF as the one given to MoveIt Pro. In config.yaml, ensure that the following lines point to the same URDF used by the robot_state_publisher node (note that the SRDF and URDF may be in two separate repositories if needed):
# Parameters used to configure the robot description through XACRO.
# A URDF and SRDF are both required.
# [Required]
robot_description:
urdf:
package: "<ROBOT_DESCRIPTION_PACKAGE>"
path: "description/my_robot.xacro"
srdf:
package: "<MOVEIT_PRO_CONFIGURATION>"
path: "config/moveit/my_robot.srdf"
# Specify any additional parameters required for the URDF.
# They will pe passed to the URDF xacro as arguments
# [Optional]
urdf_params:
- ip_address: "0.0.0.0"
- additional_arguments: "example_arg"