Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Considering adding one or more arms to a mobile robot, a series of mobility enhancements came to mind:
Added a launch file for roarm_driver with the ability to override the usb connection on start up. For example, if using udev rules to set the name of the port:
ros2 launch roarm_driver roarm.launch.py serial_port:=/dev/roarm_port
Namespaces can be used to isolate one arm from another, allowing the universal TF tree to remain conflict-free. roarm_driver will use the current namespace to select the appropriate joint_states to act on. If not using namespaces, the base of the arm can be renamed with a launch argument allowing a joint to be defined without conflicting with the chassis' base_link.
Moved the description generation system to use xacro to compile descriptions on the fly in a launch file.
Added the ability to rotate the gripper mount with an argument to support when owners change the factory orientation.
Created an example mounted.display.launch.py to show how two arms can be configured on one base:
Added README documentation supporting these mobility features. Added a new section 9.
These extended features have not been tested against the Moveit2 examples, but since by default they don't change anything if unused, I don't anticipate problems. Let me know if you see otherwise.
To see an example of using these features in cross package way, refer to:
desribe.with.arm.py