-
Notifications
You must be signed in to change notification settings - Fork 3
Command the Arm
For the best results, before rviz is run, the URDF and SRDF should uploaded to the ROS parameter server, and the @move_group@ node should be running, as the panel queries available functionality from it on startup. These preconditions should be met if the commands in all screen windows were successfully executed. If these conditions aren't met, RViz will start after a delay and the panel will have reduced functionality. Simply restart RViz after satisfying these conditions, and the panel will function normally.
The premade rviz configuration (@rcta_ws/config/rcta.rviz@) should already have the parameter name containing the URDF setup. However, if the text field next to "Robot Description:" is empty, you should type in "/robot_description" and click the "Load Robot" button to initialize the plugin using the URDF of the robot.
The "Planner Settings" group lists the available planning algorithms configured in the @move_group@ node and some basic parameters for requesting plan/execute commands. The most important option is the "ID:" dropdown list. All planning algorithms should work for both wrist pose goals and joint goals, but for best results, use "arastar.joint_distance" for joint goals and "arastar" for pose goals.
The "Tolerances" group should be self-explanatory and the defaults should be sufficient. In most cases the planner will hit the goal exactly anyway. Note that when executed from the state machine, the tolerances (and some other parameters available through this plugin) are fixed to certain values. If you'd like to compare against these values at any point, look at @rcta_ws/src/rcta/config/planning/move_arm_node.yaml@.
The "Workspace Parameters" group defines the effective workspace for the manipulator for any plan request. If the wrist is outside these bounds, planning will fail. The default should be ok, and once again you can compare against the @move_arm_node.yaml@ file to see the parameters in use when executed from the state machine.
The "Position Command" group defines the goal state for the active joint group. The joint groups should be self-explanatory. They are defined in the SRDF file (@rcta_ws/src/rcta/config/robots/roman/moveit/rcta_roman.srdf@).
The "Commands" group contains the controls for sending plan/execute requests to the arm. The "Plan/Move to Position" buttons send 6-dof wrist goals, and the "Plan/Move to Configuration" buttons send joint goals. "Copy Current State" will populate the command state using the current state of /tf and /joint_states.
Many visualizations are provided by RViz via the "MarkerArray" display (already added in the default RViz config file) on the "visualization_markers" topic. Some of these visualizations can be particularly expensive to render and can be disabled by unchecking their namespaces inside the MarkerArray display config.
Visualizations from the Move Group Command Panel:
- workspace
- rcta_roman_command
Some more, but commonly disabled, visualizations, from the arm planner itself:
- self_collision_model_bounds
- world_collision
- occupied_voxels
- self_collision
- start_config
- expansion
- goal_state
- trajectory
First, check is that the arm planner received the request. If the request was received, there should be a good number of logs in the @move@ window in screen with a recent warning that says "Planning!!!!!".
Second, check if the planner was able to find a path. If a path was not found in the allowed time, an error should have printed in the @move@ window indicating the number of states explored by the search.
If the number of states explored was 0, this likely means that the start state was invalid, either because the arm is in collision or the wrist is outside the workspace.
Robot collisions can occur if the arm is in collision with itself or the environment, or if the robot lies outside of the world's bounding box. The "collision_model_bounds" visualization will show you the world bounding box. You can check the command state in RViz, which should appear in red, rather than green, if the current state is in collision. If this is the case, you should resort to the roman_viewer for moving the arm out of collision. The sbpl planner and the jpl planner use different collision models, so it's possible that one planner will succeed where the other fails. If all else fails, Roman Viewer will allow you to move the arm with collisions disabled.
If the robot is outside of either the world bounding box or the workspace, the only solutions are to move the robot back into the bounding box, or to expand the bounding box. The workspace is defined in the Move Group Command Panel (or @move_arm_node.yaml@) and the world bounding box is defined in @rcta_ws/launch/moveit/roman/roman_move_group.launch@.
If the number of states explored was something high (on the order of 10's of thousands over 10 seconds), that means the planner was unable to find a path to the goal. This could mean the goal is infeasible. If you don't believe this is the case, you can increase the allowed planning time and try again. If you have to increase the allowed time to something outrageous (say...120 seconds), you should definitely send me the scenario.
If a plan was successfully computed, you can check the @ctrl@ screen, which should contain some relevant prints related to sending the joint trajectory to the ros->jpl translator. If it looks like the command was sent, check the limb servers to see if they've gone offline.
Try again, we had some instances of needing to send the same command twice to make the arm respond.
If you may have closed the Move Group Command Panel, you can retrieve the panel in RViz by navigation to Panels > Add New Panel
If the MarkerArray display topic is enabled, and the relevant namespace is enabled, this is likely the MD5 issue between Indigo and Jade. If you look at the output from the sender of the visualization messages (the move screen window in this case), you'll see an error printed regarding expected and actual MD5 sums of the messages.
The only fix for this is to make sure both the sender and receiver are compiled against the same version of visualization_msgs::MarkerArray, in particular, you should run the Indigo version of RViz against the planning software built against Indigo.