Issue non-blocking movements and create new wait() command

[PeterBowman]

At the time of writing, you cannot issue a stopControl command during a blocking operation like movj, relj or movl (see BasicCartesianControl/ICartesianControlImpl.cpp) without creating a new client instance.

My proposal: make these RPC commands return immediately, and add a new wait method to the ICartesianControl interface (as in CartesianServerLib/xRpcResponder.cpp at old asibot-main code). We'd have to deal with restoring previous reference speeds after the command has finished execution (ref).

[jgvictores]

LGTM!

[PeterBowman]

BTW movl and similar commands currently return VOCAB_OK even if the cmc was forced to abort, e.g. because of exceeding the hardcoded joint velocity limit. The proposed wait command could take care of this and return failure vocabs in such circumstances.

[PeterBowman]

Cf. yarp::dev::ICartesianControl::waitMotionDone:

http://www.yarp.it/classyarp_1_1dev_1_1ICartesianControl.html#af1a253cb67ed5cf091854a58248e6446

[jgvictores]

LGTM!

[PeterBowman]

The wait period is no longer hardcoded, we can now tweak it on runtime via RPC config params: 1f62c00 (#121 (comment)).

[jgvictores]

Cool!!!

[PeterBowman]

Hmmm. Having a timeout is nice, but it's designed to work only on the server side. If network delays/errors occur, how can I enforce a timeout on the client side, too?

[jgvictores]

• Delays: well, we just wait some more.
• Disconnection: tried a yarp rpc (client) against a read port (emulates a server, as yarp rpc --server is not working). Writing something from the client, awaiting for response, then killing the read port actually makes the client die:

  yarp: BottleImpl reader failed, unrecognized object code 25
  Cannot make connection
  yarp: Alternative method: precede port name with --client

This is, I think server-side wait is enough.

[PeterBowman]

Nice to know that, thanks!