Add GPIO Tool controller - Controller that can manage different tools (grippers, lifts, forks) and states (automatic/manual) that can be set and determined using IOs (analog or digital)

[sachinkum0009]

This Pull Request introduces the IO Gripper Controller, an implementation for controlling a gripper using IOs. The controller supports functionalities such as open, close, and reconfigure, which can be triggered either through an Action Server or a Service Server. Additionally, the controller publishes the gripper’s state via joint_states and provides dynamic_interfaces to expose all command and state interfaces.

Features

• Action and Service Integration: Offers flexible control of gripper operations through action or service calls.
• State Publishing: Continuously publishes the gripper's joint states and dynamic interface values for real-time monitoring.

Interfaces

Published Topics

1. joint_states [sensor_msgs::msg::JointState]:

   • Publishes the state of the gripper joint and its configuration joint.

2. dynamic_interfaces [control_msgs::msg::DynamicInterfaceValues]:

   • Publishes all command and state interfaces related to the gripper's IOs and sensors.

This addition enables better modular control of robotic grippers, paving the way for seamless integration in complex robotic systems.

Contributions via pull requests are much appreciated. Before sending us a pull request, please ensure that:

1. Limited scope. Your PR should do one thing or one set of things. Avoid adding “random fixes” to PRs. Put those on separate PRs.
2. Give your PR a descriptive title. Add a short summary, if required.
3. Make sure the pipeline is green.
4. Don’t be afraid to request reviews from maintainers.
5. New code = new tests. If you are adding new functionality, always make sure to add some tests exercising the code and serving as live documentation of your original intention.

To send us a pull request, please:

• Fork the repository.
• Modify the source; please focus on the specific change you are contributing. If you also reformat all the code, it will be hard for us to focus on your change.
• Ensure local tests pass. (colcon test and pre-commit run (requires you to install pre-commit by pip3 install pre-commit)
• Commit to your fork using clear commit messages.
• Send a pull request, answering any default questions in the pull request interface.
• Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.

[sachinkum0009]

This PR depends on this PR

[bmagyar]

this should go into the doc folder in the rst format. For an example please check the joint_trajectory_controller.

[destogl]

Please also write docs extensively about the internal state machine and also internal functionalities and external interface. As template, use the docs from another controller and adjust the content.

[destogl]

First set of comments. The second one comes tomorrow.

[destogl]

Please also write docs extensively about the internal state machine and also internal functionalities and external interface. As template, use the docs from another controller and adjust the content.

[destogl]

This should be optional.

[sachinkum0009]

I will update the required code for the optional. Thanks.

[destogl]

optional

[destogl]

optional

[destogl]

everything configuration related is optional.

[destogl]

optional.

[destogl]

Suggested change

	"~/gripper_close", close_service_callback, rmw_qos_profile_services_hist_keep_all,
	close_service_callback_group_);
	"~/gripper_close", close_service_callback, qos_services, close_service_callback_group_);

[destogl]

Proposal here. Can we do this general check only when activating the controller, i.e., on_activate because later when we're switching states we know already which states do we expect, and then we check only those.

The main idea is to avoid so many iterations in every control step is this is not even necessary.

[destogl]

Can we also please add tests with different initial states of the gripper? To make sure that we recognize it correctly.

[destogl]

I find generally this function somewhat inconsistent with the closing state checks. Can we unify this a bit. Especially the part when setting low and high states. I would except there more or less copy-paste code, or better yet calling subfunctions as we constantly do the same.