Gpio command controller

[Wiktor-99]

As I discussed with @christophfroehlich I've opened new pr with gpio controller.

This PR is a follow-up to the thread and implements a controller to send commands to GPIO interfaces, allowing specific command interfaces for each GPIO.

I have made the following changes compared to the original PR:

• I utilized the 'DynamicJointState' message for both the command and state interfaces (this allows sending commands with specific GPIO values without having to worry about the order of ports in the command message).
• I added a parameters file, and the new input parameters file will look something like this:

gpios:
  - gpio1
  - gpio2
command_interfaces:
  - gpio1:
    - ports:
      - dig1
      - dig2
  - gpio2:
    - ports:
      - ana1

• I've done significant refactoring and have added many new UTs.

[christophfroehlich]

Sorry for the late feedback.

Great work, I successfully tested this controller, see the linked PR to the demos. I made some changes to the docs and minor changes to the code wrt. error handling and parameters, but I don't have write access and had to open a PR in your fork (you forked from @mcbed and not from this repo).
The only breaking change: I renamed the ports parameter to interfaces to be aligned with the naming from the joint_state_broadcaster.

The only thing I'd like to discuss: Is it ok to assume that every command interface has a state interface with the same name? If this is not the case, the current implementation blows up:

[ros2_control_node-1] [ERROR] [1730671224.262784257] [controller_manager]: Caught exception of type : St13runtime_error while claiming the state interfaces. Can't activate controller 'gpio_controller': State interface with key 'flange_vacuum/vacuum' does not exist

I suggest one of the options:

• make the state interfaces parameterizable, if parameter is empty then publish all (like joint_state_broadcaster does, but only for the configured gpios)
• just use state interfaces existing for the command ifs names, but continue gracefully
• add a validation check to have a more user-friendly error

[Wiktor-99]

Thanks for feedback!

Renaming ports to interfaces is reasonable.

I followed first options and implement parameterizable state interfaces. Currently you can configure command interfaces and state interfaces separately. When no state interfaces are specified then controller fetches them from urdf (only for configured gpios). With such implementations you don't have to specify command or state interfaces if you want to broadcast all states of configured gpios.

I've tested it with mentioned example and UTs and seems to work.

[Wiktor-99]

I've fixed it. Now the CI no should be green.

[christophfroehlich]

Thanks a lot. I tested this again and updated the demo w.r.t. of the gpio_states topic.

[Wiktor-99]

Great! I don't know code of conduct but if I can I could help with reviewing linked example.

[saikishor]

Just few minor suggested changes from my side

[christophfroehlich]

@saikishor raised a legitimate question: Should we allow zero command interfaces for this controller (what happens actually then?)? or should we set the limit size>0 here, and create a gpio_controllers/GpioStateBroadcaster for broadcasting states only?

[christophfroehlich]

Great! I don't know code of conduct but if I can I could help with reviewing linked example.

Your review is very welcome!

[Wiktor-99]

When we don't configure any command interface then controller will just behave as broadcaster and will publish state of configured gpios (explicitly configured or taken from urdf). Probably we should't create commands topic it might fixed.

If we want to separate to controller/broadcaster we could fallback to initial version and use same interface name for commands and states and then add broadcaster.

[christophfroehlich]

One last comment @saikishor brought up: Using DynamicJointStates for the commands feels semantically more than wrong here. Should we add a copy and name it more appropriate? DynamicResourceValuesor something better. Even for the broadcaster it is questionable.