Are the tool analog inputs available?

[NikolasE]

I haven't found out how to read the analog inputs of the tool, did I miss it?

[ThomasTimm]

It should be published as part of the i/o messages

[NikolasE]

The io-messages are parsed from the masterboarddata (or something like that) and the tool inputs are not in this data block. I succeeded with the rtde-Interface, an example is in my fork: https://github.com/NikolasE/ur_modern_driver/blob/master/scripts/rtde_example.py

[ThomasTimm]

Ahh yea, I never noticed that.
It can also be parsed from the Tool data block, that way we won't have to set up another connection.

[NikolasE]

How much work is it to get and parse the tool data block? And how fast is it?

[ThomasTimm]

a rough estimate is 100-200 lines of code injected the right places :)
The data rate is 10 hz afair.

[NikolasE]

If you point me to the right places, I could be tempted to fill them. The modern_driver works well so if I'd love to contribute.

[NikolasE]

I started to implement the ToolData: https://github.com/NikolasE/ur_modern_driver/commit/13dc20e8549e1d149a8e8529598005e710ecc7ed

I wrote some parsing functions to have clearer code and to simplify the implementation of other data-packages.

So far, I did not succeed in parsing the floats, and I saw that you read floats like this:

	memcpy(&mb_data_.masterBoardTemperature, &buf[offset],
			sizeof(mb_data_.masterBoardTemperature));
	offset += sizeof(mb_data_.masterBoardTemperature);
	mb_data_.masterBoardTemperature = ntohl(mb_data_.masterBoardTemperature);

ntohl returns an uint32_t and in the current implementation, the value I get is always zero. Could you maybe explain your approach here a bit?

What do you think about fixing the parseFloat-function and then rewriting the other functions with the parse* so that it's a bit more readable?

BTW: I fixed the indentations. Why do you use double indents?

[gavanderhoorn]

I just wanted to mention ros-industrial/universal_robot#272 (comment) here as a point of discussion.

@ThomasTimm: what is your opinion on this? Is ur_modern_driver intended as a transparent bridge (dumping raw UR protocol msgs as ROS msgs on topics, delegating responsibility of interpreting those messages to consumers) or as a proxy / facade with a ROS API (and interpreting the data itself, making sure ROS msgs are stand-alone and unambiguously interpretable without needing robot configuration data and / or importing UR domain concepts into consumers)?

With the addition of the ToolData msg in ros-industrial/universal_robot#272, we have taken a step in the direction of a transparent bridge. I think we need to carefully consider this, as transparent bridges make proper abstraction more difficult.

[gavanderhoorn]

I'm closing this as we've officially deprecated this package.

Refer to the announcement on ROS Discourse.