Open shaun-edwards opened 11 years ago
We have already implemented an IO interface for motoman (DX100) robot. With bit of help we can make it more general.
The current implementation uses another simple message. The message is composed of pairs, IO address and command. Command represents reading, writing and read value (in case of reply from the controller).
@liborw: is this code publicly accessible? I'm wondering if you considered (and how you dealt with) issues with consistency?
@liborw, @gavanderhoorn, It seemed like this could be the start of a new feature discussion. Was there any resolution on this. This is definitely a feature of interest to a lot of users, but we (SwRI) doesn't have the resources to put to it.
I looked into @liborw code and I think I can implement something for an ABB robot. Maybe we should add a standard configuration file to map I/O units and addresses to human readable form. Or perhaps we can add identifiers instead of I/O addresses, but that would depend greatly on each manufacturer's controller capabilities.
@Samsagax, The difficulty in this issue is standardizing IO addressing across robot platforms. @gavanderhoorn is currently putting together a plan for this. While we could implement specific solutions for different robots, it makes sense to take a generic approach so we can standardize at a driver level. This will allow for code portability across vendor platforms.
@gavanderhoorn is currently putting together a plan for this.
@gavanderhoorn, are you open for help?
@gavanderhoorn, ping...it looks like @Samsagax is willing to help out.
@shaun-edwards: I'd seen it, just hadn't had time to respond yet.
@Samsagax: please contact me off-list (to avoid cluttering this issue).
See also ros-industrial/rep#7.
This issue has been moved from: ros-industrial/ros_industrial_issues#2 (submitted by @clay-flannigan)
Native robot I/O should be supported through standard ROS-I interfaces. Most industrial controllers have built-in (embedded) I/O standard functions like fence-status, gripper-close, etc. They generally also support general purpose I/O. Exposing these I/O points would remove the requirement for separate networked I/O from the ROS PC.