sensor message type for touch

[Ingo Lütkebohle]

Hi,

I'd be interested in defining robot-and sensor-independent "touch" sensor message type(s). common_msgs/sensor_msgs currently does not have any.

On the PR2, there are two specific message types: pr2_msgs/PressureState and fingertip_pressure/PressureInfo. The former communicates raw I2C sensor values, whereas the latter communicates where the sensors are located exactly (e.g., for arrays of touch sensors), and the conversion factors to Newtons.

As haptics are a hot topic, I'm sure there are many different sensors out there and it would be cool to process their data in a general manner. Intuitively I would assume that the two message types mentioned above generalize fairly well to other types of sensors, and we could benefit from having a common type for code using touch/force information. However, I'm not an expert by any means, so if you are familiar with other sensors, please speak up, ideally with references to other message!

What do you think?

Ingo

[Tully Foote]

There's also been some discussion in a ticket here: https://github.com/ros/common_msgs/issues/28 

--
You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drive...@googlegroups.com.
To post to this group, send email to ros-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/a2d9a4c3-220f-44b9-a2bc-7e164bb2115b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joe Romano]

I'd be for it. I think that a good generalization would really help unify the various touch-based software packages out there, but it is going to be very tricky since all the sensors are so different. Here is one suggestion I had been thinking over for awhile:

Base the messages on something like the various spatial sensitivities and frequency bands that researchers have discovered to be common in animals (including humans):

http://en.wikipedia.org/wiki/Mechanoreceptor

http://www.cns.nyu.edu/~david/courses/sm12/Readings/Westling1987.pdf

(Springer has a number of good books to pick from)

This would help categorize sensors into those that could detect things like steady-state pressure, dynamic fluctuations, fast response, slow response, etc. into more abstract categories.

It would require some processing of each sensor to make it's data fit the category, but in the end I believe it would be more useful than a raw data message - which is going to inherently look very different for all these sensors.

[Ingo Lütkebohle]

Hi Joe,

thanks for your feedback! I've been very impressed with your work on the PR2 sensor actions, and know the paper about it, which includes some of the things you mention, IIRC.

Regarding the different sensors, I think what you're talking about is called a sensor model, right? So, technically speaking, we'd characterize the sensors according to their sampling frequency, the temporal window length, the size of the area they match, and maybe the type and shape of the response function? Would that be sufficient to derive the characteristics you talk about?

Personally, I think communicating this sensor model is very interesting to achieve generality, and would actually come in handy for many other sensor types, too (just thinking of cameras with varying exposure lengths, but that's another topic ;-).

However, I also think that having raw sensor values available is a must for a rapidly developing field such as haptics. We cannot think of everything right now, and having the raw values as a fall-back seems important, particularly also during development. The combination of a message for raw values, and a message with more "interpreted" values would be ideal, I think.

cheers,
Ingo

[Joe Romano]

Yes, I definitely agree with what you are saying.

Having the raw data easily is going to let people develop things we haven't thought of. Should we do a pass over all the currently available common technology and look for the common data they provide to construct this general sensor_msgs type? What I was suggesting should probably come later, and be a consumer of this raw data (as long as we thing the raw data can be published at the rates/bandwidth we need, I know that kind of thing has been problematic for camera data in ROS).

So how would we start working on this when it is something so hardware dependent?

If it means getting some free sensors in the mail then sign me up! I'd be happy to write drivers in my free time :)

[Christian Holl]

I am also currently searching for a sensor message for touch sensors.


I would say there should be something like the wrench message.
http://docs.ros.org/api/geometry_msgs/html/msg/Wrench.html

Now you probably say a button can't measure force. But it actually can do.
It can tell you that the force it senses is higher than the force its spring can withstand before it closes/opens the contact.

So for the final message I would propose additional vectors:
Vector 3 min_force;
Vector 3 max_force;

Where in max_force and min_force are the same for a button.
When pressed the value of that would go into the value of the force.

So the message would be:

touch_sensor:
Header header

Vector3  force
Vector3  force_min
Vector3  force_max

Vector3  torque
Vector3  torque_min
Vector3  torque_max

Btw. I am not sure if torque should go in there as well...

Maybe we just need the force or create a different message for torque sensors.

And then there also should be somehow sort of an array in that message, if you have a sensor which is like a skin, featuring multiple sensors.