ControlBoardWrapper2 better state output port

[barbalberto]

As discussed few time ago I started to implement an output port with more info than just the encoders.

I used a thrift file to generate the class that will be sent through the port, a new port called stateExt:o (just dummy name).
The data sent now are

• list of joint name (useless on yarp, I know, see ControlBoardWrapper2 ROS topic #209)
• vector of encoders
• vector os velocities
• vector of torques

For now the data is filled with dummy names and numbers just to see if it works as expected.

I pushed the code on a branch called ControlBoardWrapper2_NewOutputPort.
The CMake flag CBW2_USE_YARP_THRIFT has to be enabled in order to compile the needed code and generate this new port.

This is a first implementation, more data can be added and I would like to use this redmine also to discuss what we think it is useful to put in this structure.

As explained in #209 the wrapper is now able to create a ROS topic by activating the CMake flag CB2_USE_ROS_MSG.
When both are enabled, the stateExt:o port will use the very same class generated from the .msg (instead of the one generated from the .thrift) for better compatibility between the 2 way of broadcasting data.
This is not mandatory, but I think it is a nice option to have.

If I remember correctly, we were also interested in receiving data from the motor side and for this we agreeded to have a separated wrapper boradcasting the stateExt data for the motor side (when activated by the user config file).

Will the structure of the 2 wrapper (joint side and motor side) be the same or shall be different?

What we would kile to have in those structures?

[traversaro]

Some thoughts :

How the user is expected to access this new streamed state? getEncoderSpeed and getTorque should switch to the new streaming state instead of rpc?

I am a bit afraid of changing the streamed data structure just because the user have enabled the CB2_USE_ROS_MSG. This would mean that any client should check at runtime if the stateExt is "thrift" or "ros" and parse the message accordingly. Furthermore the message on the topic and the one on the port would still have to be different, because Yarp uses the degrees as on-wire angle unit of measure, while ROS JointState message uses radians.
Personally I would prefer that yarp message and the ROS topic to be always different, even if they are both active, to avoid confusion.

Still related to the ROS/YARP relationship: which kind of advantage we get by streaming joint names? I guess that is part of the semantics of the Yarp controlboard that the joint names are constant for the lifetime of the controlboard, and the user can already get the joint name using the appropriate method of the IAxisInfo interface.

A nice feature would be having a configuration time parameter for enabling/disabling the broadcasting of the ros topic. I think of the following user case: a user does not normally use ROS at all, so he doesn't want the cbw to publish a ROS topic that is not going to be used. At some point he wants to run some kind of software that requires the ROS topic, it would be nice if he could enable the ROS topic publishing just by modifying the robotInterface configuration files (exploiting all the nice yarp-config workflow) instead of having to recompile yarp.

[barbalberto]

How the user is expected to access this new streamed state? getEncoderSpeed and getTorque should switch to the new streaming state instead of rpc?

yes, no changes from the user perspective

Please consider that this is aVERY VERY PRELIMINARY DRAFT!!! It is simply a proof of concept to see if and how this feature could work.
This discussion has been opened to define how the final version should be.

A nice feature would be having a configuration time parameter for enabling/disabling the broadcasting of the ros topic.
I agree!! This is also my idea, I think that the ROS msg can be compiled anyway because it does not introduce any ROS dependency and then the user can choose to use it or not.
Right now I used cmake flag becuase I was testing stuff and I wanted to compile only the specific files I was testing.

About Yarp/ROS: there is no need for the 2 structures to be the same, it was just a test.

Personally I would prefer that yarp message and the ROS topic to be always different, even if they are both active, to avoid confusion.
I agree.

The point of this test was answering the question:
"IF I have to send the very same data through both yarp and ros, do I need do have both a .thrift AND a .msg, generate 2 structures, open 2 ports one for yarp and one for the topic?"
and the answer is no. Theoretically I could just have the .msg file and only open the ros topic and both yarp and ros will be fine reading the same data.
(Then also opening a yarp port is better for yarp clients)

I am a bit afraid of changing the streamed data structure just because the user have enabled the CB2_USE_ROS_MSG. This would mean that any client should check at runtime if the stateExt is "thrift" or "ros" and parse the message accordingly.
That's the point, as long as the structures contains the same data, the client does not need to know if it was generated using a .msg or a .thrift and will happily read the data regardless of it.

It is true that the measurement units are different for the angles but maybe for the analog sensor wrappers broadcasting other types of data this can be useful (I mean... if we are going to support it )

Btw, let's move ROS related comments on #209.

About how the YARP structure should be, I think adding the joint controlMode and Interaction mode could be useful, so the GUIs can stop flooding the network with get messages and the user will always have the most updated value.

Do we need other data here? Currents? PID output?

[traversaro]

@barbalberto How the thing evolved? I saw that thrift and rosmsg data structures diverged, we are now going for distinct yarp and "ros" states?

[barbalberto]

Done, this port is now the standard for yarp controlBoardWrapper2