Strings as commands for FT300

[NikolasE]

The current way to send commands to the FT300 is via strings in a service. To zero the sensor, one has to send a "SET ZRO" (Not to be confused with "SET ZERO"). This leads also to parsing code like

strncpy(get_or_set, &buff[0], 3); strncpy(nom_var, &buff[4], strlen(buff) -3);

What do you think about a srv format like this:

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
---
bool success
string res

This leads to much cleaner code on both sides and the client does not have to remember string-commands.

(I volunteer to implement the changes)

[shaun-edwards]

@NikolasE, thanks for the suggestion. I think this would indeed be an improvement. With this kind of change, we have to be careful to think about backward compatibility. We wouldn't want to break any code that is currently working with the string based service. I believe there are few options:

• Support both the new and old services, simultaneously (2 service servers with different names). Add a deprecated warning to the old string based service
• Support either string based arguments or integer commands in a single service. Add a deprecated warning whenever the string argument isn't empty.
• Add a deprecated warning to jade and then replace the service in kinetic.

What do you think? I think the second option may be the most user friendly and maintainable.

[NikolasE]

The second option looks ok. What do you think about a ROS_WARN if the command-string is not empty?

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

[shaun-edwards]

Addressed in #93