On Monday, at 11:50, Eric Perko wrote:
| If you have other means of guaranteeing that the messages are compatible, can you
| also guarantee that fields with the same semantics have the same names? Without
| that, how would the ROS system know those messages, even though they have different
| names, are "compatible"?

I can guarantee that the messages are compatible by using the brain of the user
connecting the two ports. But, more seriously, no, I have no other mean than
checking the actual type of the messages (not considering the parameter names).


| $ cat velocity.msg
| float64 velocity # units: m/s
| 
| $ cat battery_level.msg
| float64 battery_pct # units: percentage, 0-1

I agree that there are good reasons to include the parameter names in the
digest. However, it does not magically add more semantics than the raw type.

Consider this:

% cat velocity.msg
float64 velocity # units: m/s
% cat speed.msg
float64 speed # units: m/s

Or this:

% cat global.msg
float64 velocity # global frame
% cat local.msg
float64 velocity # local frame

The digest guess will be wrong in both cases about the "compatibility" of the
messages.

I am more or less in the situation with the "velocity" and "speed" message,
with a third component declaring an external remote method than can be
connected either to "velocity" or "speed". Those components do not know each
other, they have no need to agree on the "naming" of their parameters (of
course, they have to agree on the data type, which they do by sharing a common
include file). The third component declares a remote method, like a function
prototype. It can declare it with whatever parameter names, just like you
would do in C.

Or in pseudo-code :
Component 1:
 export some_service(out double velocity);
Component 2:
 export other_service(out double speed);

Component 3:
 use any_service(out double celerity);


So, yes, including the parameter names may prove useful in some situation.
But, for instance, existing compilers do not currently make their
"compatibility" decisions based on this information.

That said, I am not trying to change the digest computation algorithm. Just
trying to find a way to implement this with ros.