Gpio command controller

[mcbed]

Controller to send commands to gpio interfaces allowing specific command interfaces for each gpio.

[mcbed]

Do you think there could be some interest in such a controller ? Currently I use it in galactic so is it interesting to adapt it for rolling ?

[boilerbots]

I am building a system with Advantech EtherCAT modules and I want to use this controller or something similar. I think this gets a little confusing with comand_interfaces and state_interfaces.

What about dividing up Digital vs Analog interfaces instead? This would allow digital interfaces to have a single bit represent their state and floats for analog ports. The digital interfaces could define their direction and enforce that or just always be treated as bidirectional and depending on the hardware behind them you either read the value of the port or the internal state of the register.

The same thing would work for Analog ports.

[mcbed]

I am building a system with Advantech EtherCAT modules and I want to use this controller or something similar. I think this gets a little confusing with comand_interfaces and state_interfaces.

What about dividing up Digital vs Analog interfaces instead? This would allow digital interfaces to have a single bit represent their state and floats for analog ports. The digital interfaces could define their direction and enforce that or just always be treated as bidirectional and depending on the hardware behind them you either read the value of the port or the internal state of the register.

The same thing would work for Analog ports.

Hi, I think that splitting Digital and Analog IO would reduce the generality of the controller but I am open to discussion. Also, in its current version, the controller is intended to only provide commands to the interfaces tagged in the command_interface parameter. The state_interface flag does not exist yet in this controller, it was just a discussion argument, but the feedback of all command_interfaces is published in the ~/gpio_states topic as control_msgs::msg::DynamicJointState, thus my previous question: do you think it is the most relevant message type, even if the type joint is confusing, or should we add a new control_msgs type like DynamicGPIOState? Do you think we should add an gpio_broadcaster as well ? Btw, in all cases, all other GPIO states are published by the joint_state_broadcaster.

[codecov-commenter]

Codecov Report

Merging #342 (72b56d7) into master (e7f9962) will decrease coverage by 6.03%. The diff coverage is 20.21%.

@@            Coverage Diff             @@
##           master     #342      +/-   ##
==========================================
- Coverage   35.78%   29.74%   -6.04%     
==========================================
  Files         189        7     -182     
  Lines       17570      743   -16827     
  Branches    11592      428   -11164     
==========================================
- Hits         6287      221    -6066     
+ Misses        994      162     -832     
+ Partials    10289      360    -9929     

Flag	Coverage Δ
unittests	29.74% <20.21%> (-6.04%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...de/diff_drive_controller/diff_drive_controller.hpp	100.00% <ø> (ø)
...ontroller/test/test_load_diff_drive_controller.cpp	12.50% <0.00%> (ø)
diff_drive_controller/src/odometry.cpp	42.16% <11.11%> (ø)
...ive_controller/test/test_diff_drive_controller.cpp	17.62% <12.08%> (ø)
diff_drive_controller/src/speed_limiter.cpp	46.55% <13.33%> (ø)
...troller/include/diff_drive_controller/odometry.hpp	20.00% <20.00%> (ø)
...iff_drive_controller/src/diff_drive_controller.cpp	32.13% <24.11%> (ø)
...mand_controller/src/forward_command_controller.cpp
...ectory_controller/test/test_trajectory_actions.cpp
...int_trajectory_controller/test/test_trajectory.cpp
... and 192 more