Revision history [back]

Afaict, the constants to use with that service are -- as is often the case -- documented in the service definition itself (this one):

uint8 COMMAND_GET_SERIAL_NUMBER=1
uint8 COMMAND_GET_FIRMWARE_VERSION=2
uint8 COMMAND_GET_PRODUCTION_YEAR=4
uint8 COMMAND_SET_ZERO=8
uint8 command_id
string command  # deprecated, please use command_id with a value of COMMAND_*
---
bool success
string res

So legal values would seem to be: 1, 2, 4 and 8, corresponding to GET_SERIAL_NUMBER, GET_FIRMWARE_VERSION, GET_PRODUCTION_YEAR and SET_ZERO respectively.

The value of command_id is used in this switch to call the corresponding function

I am interested in using whatever the equivalent of "SET ZRO" is now to zero out my FT300 sensor before using its readings.

I'm not a Robotiq user myself, but iiuc, you'd have to use the value corresponding to COMMAND_SET_ZERO (ie: 8) for that.

After some digging I've learned I need to use rosservice call robotiq_ft_sensor_acc [command_id] [command], [..]

As it's deprecated, you'd probably leave command (ie: the string field) empty.

And note that if you'd write a (short Python) service client, you'd actually use the constant name, not the value it maps to directly.

Afaict, the constants to use with that service are -- as is often the case -- documented in the service definition itself (this one):

uint8 COMMAND_GET_SERIAL_NUMBER=1
uint8 COMMAND_GET_FIRMWARE_VERSION=2
uint8 COMMAND_GET_PRODUCTION_YEAR=4
uint8 COMMAND_SET_ZERO=8
uint8 command_id
string command  # deprecated, please use command_id with a value of COMMAND_*
---
bool success
string res

So legal values would seem to be: 1, 2, 4 and 8, corresponding to GET_SERIAL_NUMBER, GET_FIRMWARE_VERSION, GET_PRODUCTION_YEAR and SET_ZERO respectively.

The value of command_id is used in this switch to call the corresponding function

I am interested in using whatever the equivalent of "SET ZRO" is now to zero out my FT300 sensor before using its readings.

I'm not a Robotiq user myself, but iiuc, you'd have to use the value corresponding to COMMAND_SET_ZERO (ie: 8) for that.

After some digging I've learned I need to use rosservice call robotiq_ft_sensor_acc [command_id] [command], [..]

As it's deprecated, you'd probably leave command (ie: the string field) empty.

And note that if you'd write a (short Python) service client, you'd actually use the constant name, not the value it maps to directly.

Afaict, the constants to use with that service are -- as is often the case -- documented in the service definition itself (this one):

uint8 COMMAND_GET_SERIAL_NUMBER=1
uint8 COMMAND_GET_FIRMWARE_VERSION=2
uint8 COMMAND_GET_PRODUCTION_YEAR=4
uint8 COMMAND_SET_ZERO=8
uint8 command_id
string command  # deprecated, please use command_id with a value of COMMAND_*
---
bool success
string res

So legal values would seem to be: 1, 2, 4 and 8, corresponding to GET_SERIAL_NUMBER, GET_FIRMWARE_VERSION, GET_PRODUCTION_YEAR and SET_ZERO respectively.

The value of command_id is used in this switch to call the corresponding function function.

I am interested in using whatever the equivalent of "SET ZRO" is now to zero out my FT300 sensor before using its readings.

I'm not a Robotiq user myself, but iiuc, you'd have to use the value corresponding to COMMAND_SET_ZERO (ie: 8) for that.

After some digging I've learned I need to use rosservice call robotiq_ft_sensor_acc [command_id] [command], [..]

As it's deprecated, you'd probably leave command (ie: the string field) empty.

And note that if you'd write a (short Python) service client, you'd actually use the constant name, not the value it maps to directly. See robotiq_ft_sensor/nodes/rq_test_sensor.cpp for a C++ example of how that would work.

Edit: the contants are also mentioned in the documentation of the rq_state_get_command(..) function.

That is all non-user-facing documentation though, so it would have been nice if this change had received a bit more attention -- perhaps in the form of an announcement somewhere in a Robotiq support/information channel.