Yarp RPC simulink block

[yeshasvitirupachuri]

Summary

A simulink block that provided yarp rpc functionality.

Motivation

Currently, for the pHRI standup experiment in simulation I need to set the robot and the human models to be in an initial configuration and then connect their hands through linkattached plugin. It is currently done through rpc from terminal commands. It will be an asset to have this functionality done through simulink directly.

[traversaro]

How do you imagine this block to work? RPC and dataflow blocks are fundamentally different paradigm, but indeed there are some convenient ways of combining the two.

[yeshasvitirupachuri]

@traversaro The block functionality should be such that at the start of the simulation it connects to rpc port of linkattacher plugin and sends commands to connect then hands of both the agents involved in physical interaction.

[traversaro]

As the logic of this seems quite hardcoded, perhaps a good strategy is to write your own block in your project containing this logic following the example in https://robotology.github.io/wb-toolbox/mkdocs/create_new_library/ and https://github.com/robotology/wb-toolbox/tree/master/example .

[yeshasvitirupachuri]

@traversaro thank you
Also discussed with @diegoferigo about this and decided to have a simple implementation first.

[diegoferigo]

@Yeshasvitvs @traversaro Yes as discussed f2f before opening the issue, this RPC functionality can be developed in 2 steps:

1. A block that does not take any inputs nor outputs. The RPC command will be sent the first loop of the simulation and then the block will become a no-op. From Simulink side, the block will take the following two mask parameters:
   1. The name of the rpc port
   2. The command to send
2. As an improvement, I would add an input signal (double for simplicity but used as boolean) that contains a trigger. Every rising edge 0 ~> 1 the RPC command will be sent.

We should discuss how to implement a timeout in order to avoid that the simulation get stuck if the remote does not return (since RPC usually is a blocking call). A first idea would be spawning a thread for executing the call and wait that it joins or kill it after the timeout, but this would be the only case we use this approach in the entire toolbox. I'm not sure it is the only one. Any idea @traversaro?

[traversaro]

Any idea @traversaro?

If we just need this at startup (option 1), for the time being I would play it safe and I would just not return from the first loop of simulation until the RPC has returned, or fail the simulation if the RPC did not returned after a timeout.

If option 2 is instead chosen, indeed blocking in the middle of the simulation may not be an option, especially when there is no explicit time synchronization. The idea of spawning a specific thread seems good.

[diegoferigo]

cc @VenusPasandi

[traversaro]

I think we could take inspiration from Simulink's ROS Call Service block https://www.mathworks.com/help/robotics/ref/callservice.html regarding the timing aspects.

[diegoferigo]

In my opinion this is a simple task for someone that wants to learn how to add a new block (we also have a new tutorial which should cover the entire process). Since it has low priority, I would mark it also as good first issue.

[yeshasvitirupachuri]

I will get to this task soon after HDEv2 and before starting the work with the controller

[diegoferigo]

Great! You'll be the first tester of the new tutorial 😍