Addition of Dual MoveIt Configured Oberon7

[crvogt]

Summary

This PR launches two scenarios, one in which two oberon7 arms are loaded into an empty world, and another where they are mounted to the rexrov.

Test two arms in empty world

Launch the Gazebo simulation
roslaunch dave_demo_launch dave_two_arm_demo.launch

To control the arms with RViz, run
roslaunch oberon7_moveit_config oberon7_multi_planning_execution.launch

Test two arms mounted to rexrov

Launch the Gazebo simulation
roslaunch dave_demo_launch dave_oberon7_moveit.launch
This will load the arm controllers.

To control the arms with RViz, run
roslaunch rexrov_oberon7_moveit rexrov_dual_arm_moveit_planning_execution.launch moveit_controller_manager:=rexrov

Dependencies

• Oberon7 MoveIt Configuration and Gazebo Controllers uuv_manipulators#8
• Add MoveIt and ros-controller dependencies to noetic Dockerfile HonuRobotics/dockwater#21

Known issues:

• Arms seem a bit heavy for rexrov, resulting in significant front tilt
• Warning messages for: URDF base link with inertia, total robot state not known
• Error messages: no PID values set

[mabelzhang]

I just noticed this is a draft PR. Should we wait for anything or can we start reviewing?

[crvogt]

@mabelzhang I'll change it, it was just meant for while I was adding documentation.

EDIT: Currently testing dockwater for dependency additions

[j-herman]

@crvogt I've been playing with this for a few hours - no luck yet, but I'll keep looking.

I tried building the docker environment with only ros-noetic-moveit, rather than all of the packages, as Brian suggested. It's significantly faster than including everything and I haven't found any problems from that yet (I'm running with everything installed in the local environment and getting the same results in both) but since I haven't seen any arms so far that may change.

There are some issues with getting the arm controllers to load that I think I will be able to track down with a little more time. The problem seemed to be that ros-noetic-ros-control is not being installed automatically on my system, either in or out of docker, and so I was missing the position_controller/JointGroupPositionController altogether. Rosdep isn't catching it. I resolved that, and the correct controllers are showing up in the robot1 and robot2 namespaces in the empty world demo, but the controller manager still can't load the arms. I think it's looking in the wrong place.

The errors:
[ERROR] [1645390477.223237566, 0.442000000]: Could not load controller 'arm_controller' because controller type 'position_controllers/JointTrajectoryController' does not exist. [ERROR] [1645390477.223279258, 0.442000000]: Use 'rosservice call controller_manager/list_controller_types' to get the available types Error when loading 'arm_controller'
One of these pops up for each arm and hand. rosservice call robot2/controller_manager/list_controller_types gives the correct output, as does the equivalent call for robot1.

When I load the full demo, I'm getting a lot of path-related errors. Here's a snippet:

[Wrn] [SystemPaths.cc:459] rmFile or path does not exist [omn"337m"m/] [3[Wrn] [SystemPaths.cc:459] File or path does not exist [""] [file:///home/carson/uuv_ws/src/uuv_manipulators/oberon7/oberon7_description/meshes/serial_arm/visual/Base.dae]ile:///home/carson/uuv_ws/src/uuv_manipulators/oberon7/oberon7_descri[Err] [Visual.cc:2956] No mesh specified3mrm]om [Wrn] [SystemPaths.cc:459] File or path does not exist ["/home/carson/uuv_ws/src/uuv_manipulators/oberon7/oberon7_description/meshes/serial_arm/visual/Base.dae"] [/home/carson/uuv_ws/src/uuv_manipulators/oberon7/oberon7_description/meshes/serial_arm/visual/Base.dae]
I haven't been able to find where the local path from your machine is sneaking into the xacros, but I blame the MoveIt Assistant.
I'm running the bimanual_task branches in uuv_manipulators, dave, and Dockwater, with the one change in the dockerfile as described above.

[crvogt]

@j-herman Thanks for checking it out. I modified the paths in the uuv_manipulators - oberon7.urdf.xacro file to rely on the package rather than the absolute paths. The arms in the dave_two_arm_demo.launch should now show up. With docker, I'm not seeing any unexpected behaviours on a new build.

[j-herman]

@crvogt Sounds good, that should hopefully fix it! I'll give it another shot and report back.

[j-herman]

Arms are showing up in both demos now, and the arms are controllable via RViz - validated with random pose for all four move groups in both scenarios.

I had to manually install ros-noetic-joint-trajectory-controller to get rid of the other errors. Or, possibly a better option, ros-noetic-ros-controllers in its entirety. This doesn't get installed with ros-noetic-desktop-full, but I haven't run anything that needed more than ordinary position controllers since I last reinstalled ROS, so I hadn't noticed. May need to be added in docker as well...?
Anyhow, this should be good to go other than dependency issues. I'll approve this PR and the one for uuv_manipulators, but maybe you want to wait to merge them until the dockerfile is sorted out?

One other thing I saw - seems like you need to wait for everything to fully load in Gazebo before starting RViz, or else the connections aren't made correctly. Worth a mention in the documentation, I think, in case everyone else is as impatient with the startup sequence as I am :)