Add Contact.msg to sensor_msgs package

[BartlomiejK2]

Description

Adding Contact.msg related to issue #286.

Additional Information

Message was implemented in message-only package contact_msgs.

[ros-discourse]

This pull request has been mentioned on Open Robotics Discourse. There might be relevant details there:

https://discourse.ros.org/t/new-contact-message-for-sensor-msgs/45055/1

[tfoote]

Connecting this back to past discussions:

There's a similar proposal with unanswered questions here: ros/common_msgs#28

In particular this needs to be a self describing message such that someone can interpret the message in the future without knowing everything about the specific system and algorithms that use this information should be able to make useful decisions based on the information from the message itself.

For example what is the contact sensor's threshold? Is it a reed switch and how much throw does it have? Is it a pressure sensor if so what's it's sensing threshold? Is it an ultrasonic what's it's minimum distance/deadband? Is this a single sensor or part of an assembly with a larger potential contact surface area? Is this a virtual sensor for simulated contacts? Does this only measure one direction of contact/pressure?

How would a subscriber differentiate a button contact versus a bumper contact? Also maybe capacitive sensors are another modality that should be captured.

What are the category of sensors that you expect to cover? Can one message cover them all? What are the planned use cases that this should cover, and what's out of scope? In particular this idea of what's the scope of this message is important to identify if it's useful at the level of a standard message or is it something that should remain application specific?

Contact is a very abstract term and we need to make sure that this message is unambiguous in it's scope so that we don't get different people ascribing different information to the same fields.

This is something that I'd generally support but it needs to be much more clearly defined than a bool and a header for "simple contact".

[peci1]

When I saw this proposal, I understood it as a "logical" contact. I.e. something that is produced by various thresholding or other postprocessing methods after they decide whether there was contact or not.

[BartlomiejK2]

@tfoote thank you for feedback!

In particular this needs to be a self describing message such that someone can interpret the message in the future without knowing everything about the specific system and algorithms that use this information should be able to make useful decisions based on the information from the message itself.

For example what is the contact sensor's threshold? Is it a reed switch and how much throw does it have? Is it a pressure sensor if so what's it's sensing threshold? Is it an ultrasonic what's it's minimum distance/deadband? Is this a single sensor or part of an assembly with a larger potential contact surface area? Is this a virtual sensor for simulated contacts? Does this only measure one direction of contact/pressure?

How would a subscriber differentiate a button contact versus a bumper contact? Also maybe capacitive sensors are another modality that should be captured.

Like @peci1 said, this message is a logical contact that defines whether there is contact between sensor defined as frame and another, unknown object, which can be used i many various types of contact sensors, without any specifications regarding this sensors.

What are the category of sensors that you expect to cover? Can one message cover them all? What are the planned use cases that this should cover, and what's out of scope? In particular this idea of what's the scope of this message is important to identify if it's useful at the level of a standard message or is it something that should remain application specific?

This message will cover all contact sensors/bumpers that only detect contact, but don't give additional information about forces or torques. I think that in this scenario geometry_msgs/WrenchStamped can be used or another new type of Contact message.

[tfoote]

When I saw this proposal, I understood it as a "logical" contact. I.e. something that is produced by various thresholding or other postprocessing methods after they decide whether there was contact or not.

If it's a post processed potentially fused result it doesn't sound like a good fit for a sensor message then. Can you explain what process you're looking to document the output of which isn't a sensor?

message is a logical contact that defines whether there is contact between sensor defined as frame and another, unknown object, which can be used i many various types of contact sensors, without any specifications regarding this sensors.

How can I effectively use this message without knowing context about what the sensor is? Some sensors will detect a blade of grass in contact, some won't. Some will detect glass some won't. Some will have a deadzone some won't. If the contact sensor has a bumper attached the contact may not be coincident with the sensor. If the sensor is directional it may not detect certain types of contacts. This extra context is what allows the information to be reused. If there's an estimation mechanism we would like to know some sort of confidence interval. Or if there's a physical size of the sensor surface we'd want to represent that. Without this extra information the message itself is hard to process.

To be a common standardized message we should be able to have a generic interface in rviz that's unambiguous about what it's represeting.

I again go back to the questions of what are the use cases that you want this to cover? If I'm thinking of different use cases than you are based on the message description then it's not well enough defined. We need to balance simplicity with usefulness. We have worked hard to build a strongly typed message set that allows logged data to be self describing. To be added here we should keep those same expectations.

[BartlomiejK2]

@tfoote

If it's a post processed potentially fused result it doesn't sound like a good fit for a sensor message then. Can you explain what process you're looking to document the output of which isn't a sensor?

You are right, this message does not contain information about output of the sensor, so I think that it needs to be moved to different package or more information needs to be added (e.g. sensor surface area, type of sensor used, normalized value, confidence interval).
For the first option unfortunately I did not find any standard package that this message can be put in, but I think that this information is useful in many scenarios, when data from sensor is processed by other system. In my case, I need information that there is contact between leg of the robot and ground for generating control signals to joints via non-linear MPC. Raw sensor data is processed by micro-controller so I do not care about raw data, only if there is contact or not (defined by some internal logic in micro-controller).

How can I effectively use this message without knowing context about what the sensor is? Some sensors will detect a blade of grass in contact, some won't. Some will detect glass some won't. Some will have a deadzone some won't. If the contact sensor has a bumper attached the contact may not be coincident with the sensor. If the sensor is directional it may not detect certain types of contacts. This extra context is what allows the information to be reused. If there's an estimation mechanism we would like to know some sort of confidence interval. Or if there's a physical size of the sensor surface we'd want to represent that. Without this extra information the message itself is hard to process.

I have written above some of examples for additional information for sensor_msg, other than that I do not have so much knowledge about contact sensors, considering the fact that there are multiple types of them, their algorithms can be different etc..

I again go back to the questions of what are the use cases that you want this to cover?

Use cases I want to cover are all algorithms using information about robot being in contact with something, like one explained above, where I do not need to know about additional information about sensor or its raw data, but only binary information that guarantees, that indeed there is contact between defined frame in header and unknown object.

Like I said about sensors with good force readings, WrenchStamped is good type that can be used ass post-processed message, like in ForceTorqueSensorBroadcaster in ros2_control.

[tfoote]

For the first option unfortunately I did not find any standard package that this message can be put in, but I think that this information is useful in many scenarios, when data from sensor is processed by other system. In my case, I need information that there is contact between leg of the robot and ground for generating control signals to joints via non-linear MPC. Raw sensor data is processed by micro-controller so I do not care about raw data, only if there is contact or not (defined by some internal logic in micro-controller).

This is a valid use case. However it doesn't seem that this message is a good generalization to support that use case. This message is not particularly useful outside of that context. In particularly your statement

but only binary information that guarantees, that indeed there is contact between defined frame in header and unknown object.

A few things here, "guarenteeing" contact is not something that is possible outside of a simulation environment when there's full observabilty. There's always levels of uncertainty especially for unknown objects. And secondly frames cannot be in contact with things, bodies are what make contact and they may make contact not coincident with the sensor. For example if you have a contact sensor on the toe of a robot, but it steps on something with it's heel only the contact sensor will still report no contact, even though the robot is strongly making contact and potentially can stand without the sensor triggering. Consumers of this information need to be able to have logic to understand these differences and a generic message for this should capture that information to allow downstream users to process it appropriately.

I would suggest for your use case that you create a custom message for your use case that captures your requirements and not try to generalize it until you have a working example. Typically for messages going into these core packages at this point we're looking for already used messages that have been validated in multiple use cases already and they may undergo a small transformation before being standardized. But because of our stability needs we hold a high bar of validating use cases before applying them, because if we want to change messages here it has a very high impact in the community.