ActionsRenderingEngine response time

[kt10aan]

ARE seems to be quite inconsistent in the reaction times. The time for a command to start being executed can vary quite a lot. I understand that difference commands have different processing times etc, but often the waiting time for the same command (e.g. simple look at point command) is quite varied.

Is there an easy fix for that? And regarding my code, is it a good idea to replace it with a normal port and not an RPC port, at least for the command port? My point is that I try to get consistent reaction times for my actions.

[pattacini]

The commits done to the Cartesian Controller on Oct 21, 2014 come to my mind that can somehow explain the changes in ARE. Essentially, there was a bug - with position-direct control enabled - that was giving the "grant-to-go" while the Cartesian trajectory was not entirely completed in point-to-point movements. Once fixed, of course, the movements execution was eventually right but achieved with different timing; for this reason we had to tune again the parameters in the ARE configuration file accounting for the timeout and the speed of the controller.

However, we are using ARE since then without any "apparent" problem regarding the movements repeatability / timing. Could you detail a list of commands you send to the /ARE/cmd:io port, so that in principle we are able to replicate the problem and/or also provide the content of your configuration file?

If you replace the rpc communication with a send-and-forget command you won't be notified by the end-of-action event. If this is viable depends mainly on your application.

[kt10aan]

The config file was the one in the repository. The sequence of commands on which I test this a simple:
home->expect left->expect right->home->explore hand->home (I do these simple tests for ARE whenever I upgrade the software).

On the tests above I am using the stock ARE. Having said that, the software version is from somewhere in December 2014, so it doesn't include the bug fix.

On my own stuff, I am also using a modified ARE, but the only difference is that has additional actions. I was thinking of replacing the RPC ports with normal ports and having an internal bool variable for checking if a command has finished (i.e., not having to wait though the whole RPC command->action-> action done-> RPC reply cycle, in order to shave off some time.

[pattacini]

Well, the fix is from October 2014 hence I'd say it's in, right?

Concerning the blocking queries sent to the /ARE/cmd:io, you could go for a send-and-forget pattern for that communication and do polling on /ARE/rpc using the [status] request.

I'll set up tests to experiment on the timing problem. Stay tuned.

[kt10aan]

@pattacini, sorry, my mistyping, It does include the October 2014 fix. I had in my mind that it doesn't include the fix you mentioned for iKinGazeCtrl (issue #12)

[pattacini]

For testing, I've gone through the following steps:

• ARE is hacked at this code line, by replacing

if(!motorThr->point(command))
{
    reply.addVocab(NACK);
    break;
}

with

double t0=Time::now();
if(!motorThr->point(command))
{
    reply.addVocab(NACK);
    break;
}
double t1=Time::now();
yDebug("---------- point = %g [s]",t1-t0);

• ARE is launched with this context.
• To simplify the test, I queried ARE 10 times in a row with the command point (-0.35 0.0 -0.1) left sent to /ARE/cmd:io port, getting the timing reported hereafter:

trial	duration [s]
1	3.90264
2	4.39814
3	4.57924
4	4.03877
5	4.08696
6	4.10628
7	3.93541
8	4.24572
9	3.9722
10	4.12604

They seem to be quite consistent.
Could you run the same experiment on your robot and report on what you'll get?

[lornat75]

@kt10aan: bugs asides, this discussion makes me realize that experiments with HRI can be a nice scenario in which to evaluate the new extensions that @apaikan and @drdanz have introduced in YARP to improve determinism in scheduling and communication.

[pattacini]

Closing the issue.
Feel free to reopen it if you have new info on that.