Torque sensor

[izamalloa]

Torque sensors messages have to be modified:

• Specs: rightnow it doesn´t report enough information. For example, axes amount, precision or security factor.
• Torque: Units? the torque has to be reported in Nm @ibaiape we will work together on this.

[vmayoral]

Thanks for raising this issue @izamalloa. @ahcorde, you've compiled the driver so your input is probably very helpful here.

[ibaiape]

After some input from @rkojcev:

• Most (only) torque sensors measure a single axis.

• Taking information from the sensor by name (x, y, z, torque_x, force_x...) feels simpler and more natural when receiving multiple values.

• Usually a force & torque sensor implies a full-blown 6 axis sensor, there's few examples where that's not the case (few but not inexistent, for example me-systeme sells a couple of models which measure X and Y torque and Z force).

Initial research on force sensors shows more variety, having found sensors measuring 1, 2, or all 3 axes. Not only that but the single-axis measurement could be any one of them (to measure pressure on the shaft end to end with Z, or bending force with X/Y), the same with the 2 axis ones.

Taking this into account I'd suggest the following system, with explanations on each below the list:

• Torque sensors' reading message give info about a single axis.

• Force sensors' reading message give info on all 3 axes, passing NaN in not measured axes to avoid misunderstandings.

• Force&torque sensors' reading message give info on all 6 axes, passing NaN in not measured axes to avoid misunderstandings.

Torque: As this information would be related to either a motor or a servomotor, they would publish it themselves (similar to the servomotor's temperature) instead of the torque sensor on it's own topic.

Force: This information would also be relative to another component, either an end-effector, a robot base, or a motor/servomotor. Passing all 3 axes is done for simplicity, both in usage (user/developer accesing the information by name, not taking into account what axes the sensor measures) and design (all force sensors send the same msg instead of having one msg&topic for it for each possible combination, like: X, X&Y, X&Z, Y...).

The idea behind this, using an example: I need to change force sensor A from my motor, which I exchange for force sensor B. A measures just the Z axis, while B measures all 3 axes.

• If HRIM defines separate msg files for different axis combinations, and therefore different topics, I'd have to either change my software or previously had contemplated the possibility of that information coming from any of multiple sources.

• On the other hand, with the sensors publishing the same message, the change would require no modification on the software side, even if I wouldn’t take full advantage of the sensor’s capabilities (the 2 axes the software ignores).

To me, this is closer to HRIM’s approach. This would also mean that different capabilities don’t force you to change any part of the process, which would, as an extra, provide some freedom on the search of possible replacements. It could also facilitate improvements, as you would be able to take into account extra information without changing the topics/msg files.

Extendable later on with more specific messages if the need arises, you’d still need the complete one anyways.

Force&Torque:

Why not separate force & torque (have a topic for all force info and another for all torque):

1. Because the torque sensor would only communicate a single axis instead of 3, so it’d already need a separate torque specific message that would only be used by F&T sensors.

2. Because I strongly believe (keep in mind my lack of experience on the field) that separating related data in safety critical information is a mistake, as it’d add lag on the processing of that information (controller would have to take some time, even if minuscule, to correlate the readings). I might be overthinking this, or wrongly assuming it’d take longer than it really would, but I believe safety critical data communication must focus on transfer speed and data integrity. (I have some experience on this front working on the autopilot, which used multiple sensors for stabilization)

As with the force sensor, you’ll still need the complete message (most common one too), more specific messages could be added if the need arises.

ADDENDUM

I conceptually dislike passing null values in readings (not so much in specs for example), as it feels that the focus on those topics should be to pass the needed information in the smallest and most consistent way possible. However, I do believe that if we don’t contemplate passing null values in some instances the complexity will exponentially go up on harder to standardize components.

Plus, it’s a common thing to pass null values in some instances. For example when passing a new goal for a motor without modifying the current effort, you’d pass a NaN value for the effort.