search

ros-industrial / industrial_core

ROS-Industrial core communication packages (http://wiki.ros.org/industrial_core)
156 stars 181 forks source link

Add endianness detection using the ping message #80

Closed gavanderhoorn closed 7 years ago

gavanderhoorn commented 10 years ago

Just something I thought of, but we could possibly detect endianness of the controller by sending it a ping (a simple_message ping). Checking the fields in the reply should make it clear as to what endianness the server is using. The ping would be send before all other traffic.

If not for automatic installation of byte-swapping handlers, this could be used to detect misconfiguration by the user (ie: he/she specified the wrong launch file parameter). A nicer error message could then be given to the user, instead of the current 'could not load array' or 'no handler registered for message type'.

shaun-edwards commented 10 years ago

+1...this is by far the most common issue people have when talking to hardware. It's particularly bad for drivers that have to support both (i.e. motoman and fanuc).

gavanderhoorn commented 10 years ago

@gavanderhoorn wrote:

The ping would be send before all other traffic.

This is actually rather difficult: all currently implemented state servers start to immediately send JOINT_STATUS data (or equivalent) upon connection. As state clients and joint relays are independent processes, we cannot influence their connection order, or even predict which will connect first.

This makes the described approach rather useless (at least with the way things currently work).

gavanderhoorn commented 8 years ago

I think the only way for this to be realistically implementable is to do auto-detection of endianness based on incoming data in the industrial_robot_client nodes. The various drivers being as they are don't have the capability to properly respond to PING messages, and even if they do, the issue with the joint states being broadcast immediately remains.

Making the (de)serialisation routines runtime replaceable / configurable in combination with auto-detection would also remove the need for the three variants of the simple_message libraries.

gavanderhoorn commented 7 years ago

This is not possible without changes to all the robot driver server sides that we have.

All drivers begin transmitting messages as soon as they see a connection on their robot_state port, which would mean that we would either have to implement some sort of state machine that connects, checks msgs, disconnects, configures the correct deserialisation routines and then reconnects, or the drivers would have to be changed to wait for some sort of 'start' or 'enable' msg before starting to transmit messages (in other words: the drivers would get a state machine).

I'm going to close this as I don't think we have the resources to address this properly now, and the system we have in place does, however primitive it is, work to a certain extent.