suggestion for additional note on iKinCartesianSolver wiki entry

[frank-foerster]

Hi,

This is a suggestion rather than an issue.

I just spent a few hours trying to get the iKinCartesianSolver to work with the simulator using the iCub_Simulator_Startup script.
The script / resource finder did not pick up the correct configuration file despite the correct --context parameter. The reason for this "misbehaviour" was the circumstance that I still had the name of our physical robot stored in the $YARP_ROBOT_NAME env. variable. If the latter is set to an existing robot that has been imported (using yarp-config) to the local user dir ($HOME/.local/share/yarp/), the resource finder will pick up the cartesianSolver.ini in the respective robot directory instead of the one in the specified context directory - apparently the former has a higher priority than the latter - odds are that the former will specify the physical robot rather than the simulator such that the solver will look for the wrong ports.

Changing $YARP_ROBOT_NAME to iCubSIM did the trick for me as there's no such robot directory.
As cartesianSolver.ini appears to be one of the few configuration files located directly in the robot directories I guess this problem is rather specific to the cartesian solver.

So in order to potentially save someone else a few hours of debugging I suggest to add a sentence recommending a change of the robot name when trying to use the solvers with the simulator to the wiki page.
I don't have write access, so I can't do it myself.

[pattacini]

Hi @frank-foerster
I can see your point but I would honestly discourage to add further info specifically to iKinCartesianSolver in this respect for two main reasons:

1. The search among various contexts is a core functionality of our infrastructure, comprising the behavior in the presence of YARP_ROBOT_NAME env variable, which is intended exactly as it happened in your case.
   For this, have a look for example at discussions in Doubts about Configuration Files in YARP #42, where hints and heads-up are also given to inspect which files from which contexts will be used.
2. Therefore, this behavior is definitely not specific to iKinCartesianSolver, which should rather remain agnostic of where its configuration files are actually located.

I'm sorry you wasted a few hours, but this "undesired" event could have happened also with e.g. pf3dTracker, iKinGazeCtrl, camCalib and other modules that have their conf files in the robots' directories - which is still a robot dependent behavior anyway. Users are allowed and even encouraged to add robot specific files therein without limitations.

[frank-foerster]

Hi @pattacini ,

thanks for the explanations regarding the design. I was not suggesting to hardcode or state the location of iKinCartesianSolver's config file in the Wiki, but rather just add some qualifier.
For example in the line under --context, where it says

"allow specifying a different path where to search the configuration file",

one could simply add something like

"(this option may be inefficacious if the robot name stored within YARP_ROBOT_NAME does not match the target robot as could be the case when switching between simulator and physical robot)"

As said this is just a suggestion, that would have saved me and potentially others some headaches. If you prefer it spartanic and minimalistic this is obviously up to you as the module developer.

So just to clarify: the cartesianSolver.ini located in the the robots/\<our_robot_name\> subdir is the one supposed to be read by the solver when the target is the physical robot as this file is robot- rather than context-/application-dependent, correct?
What is the purpose of the file of the same name in the context/cartesianSolver subdir? Or is this some leftover from older times?
Also: the simulator appears to be a bit of a special case here, as there is no robot "context" to be imported, correct? I couldn't see any when looking into $ICUB_ROOT/app/robots. Is there a recommended name to be assigned to YARP_ROBOT_NAME when using the simulator? I chose it more by guessing...

Also, thanks for linking issue/discussion #42.

[pattacini]

The thing is that iKinCartesianSolver does not represent a special case, hence there's really no need to highlight more clearly the warning in the documentation, otherwise we should replicate it within the documentation of each single module.

Further, the warning should have been more something like "Beware of the context search policy" 😄 with an appropriate link to e.g. http://wiki.icub.org/yarpdoc/yarp_data_dirs.html, because the role of YARP_ROBOT_NAME is only one of the many aspects the user needs to account for.

Coming to your questions

There is a specific hierarchy established among robot and module contexts, which also considers the case of files located either in local or installed directories. The whole story is detailed in the documentation linked above and in other resources you can find in our wiki as well as in #42.

The (quick) take home message is that robot contexts gain priority over modules own contexts (even if user specifies explicitly the --context option) and local contexts have priority over installed contexts; the rationale is that information tuned by the user for his own experiments (i.e. local context) and/or for his own robot (i.e. robot context) need to shadow defaults values (i.e. installed context). Be careful since, in this framework, the installed robot context also shadow local module own contexts.

Therefore:

• context/cartesianSolver is not a leftover but represents the module own installed context with fallback values.
• To run iKinCartesianSolver along with the simulator, follow the instructions announced in Use yarprobotinterface instead of simCartesianControl #146. In particular, you have to launch: $ iKinCartesianSolver --context simCartesianControl --part [left|right]_arm.

Hope this better clarifies how to deal with contexts.

[pattacini]

A further quick note. I definitely suggest to use frequently in debugging this command:

$ yarp resource --context moduleName --from fileName

to inspect which file will be loaded from which context.

The tools yarp resource and yarp-config context are also discussed in #42.

[frank-foerster]

Hi,
the "Beware of the context search policy" would be ok with me and would have triggered me to re-read the search policy description.
I have seen the mentioning of yarp resource in issue #42 and will use it in the future.

Thankfully, modules (or the ResourceFinder) also print on the command line where they look for files and which one they load - that's how I finally saw what went wrong.

Thanks for the link to #146. Does that mean that simCartesianControl will be phased out?

[pattacini]

@frank-foerster, just added the warning to a couple of modules, i.e. iKinCartesianSolver and iKinGazeCtrl.

simCartesianControl is already no longer available in our repo, starting from the commit referenced in #146.

[frank-foerster]

Ok, thanks a lot. Let's hope the warning will help someone or save them time.