Trouble installing

[rlober]

Hey guys,

I am having trouble getting the WBIToolbox installed in Matlab. I am able to run the startup_wbitoolbox.m script successfully, I restart matlab from shell with simply matlab and I don't see the WBIToolbox anywhere in the simulink library. Just FYI I am using Ubuntu 12.04 and Matlab R2014b.

Also I noticed something in the README:

CODYCO_SUPERBUILD_DIR should be CODYCO_SUPERBUILD_ROOT

and,

addpath([getenv(CODYCO_SUPERBUILD_DIR)  /install/share/WBI-Toolbox/img])

should be

addpath([getenv('CODYCO_SUPERBUILD_ROOT')  /install/share/WBI-Toolbox/images])

I couldn't actually get these lines to work in Linux. I am not sure why but my matlab doesn't seem to properly load my environment variables. ie: getenv('CODYCO_SUPERBUILD_ROOT') returns an empty string '', while when I run echo $CODYCO_SUPERBUILD_ROOT from the command line I get the appropriate path. Any suggestions?

Thanks in advance, Ryan

[jeljaik]

@rlober Can you please first reopen this issue using the script create_issue.sh? (as described in https://github.com/robotology-playground/WBI-Toolbox/blob/master/CONTRIBUTING.md#notes-on-issues) It will provide us with some further information to better debug this issue. Nevertheless, regarding the environmental variables described in README.md, named CODYCO_SUPERBUILD_ROOT and CODYCO_SUPERBUILD_DIR these are just to make it easier to describe certains steps of the installations and they correspond to what's written in https://github.com/robotology-playground/WBI-Toolbox#compiling-the-toolbox-mex-files, i.e. CODYCO_SUPERBUILD_ROOT to the dir where you pulled the source code, e.g. ~/Software/codyco-superbuild and CODYCO_SUPERBUILD_DIR to the build directory where you compiled the superbuild, e.g. ~/Software/codyco-superbuild/build We find it useful to set these environmental variables.

[jeljaik]

Also assuming that you have properly compiled and installed WBIToolbox from codyco-superbuild, launching Matlab from terminal and not seeing the Toolbox in the Simulink Toolbox Browser means that Matlab has been launched outside the default ~/Documents/MATLAB home directory. As explained in this section https://github.com/robotology-playground/WBI-Toolbox#working-from-the-build-tree, the automatically generated script startup_wbitoolbox.m creates a file called pathdef.m in your user startup directory, usually ~/Documents/MATLAB where all the necessary directories are added to Matlab's path at startup (including the Toolbox). When you launch Matlab from terminal, you have to make sure you are located in this user directory (Note that this does not happen when you launch Matlab by clicking on its icon). You can avoid doing this everytime, by creating an alias for Matlab such as: alias matlab_codyco="cd ~/Documents/MATLAB && matlab"

However I'm just guessing here. Let's first see the log I asked you before and I'll be able to tell you more :sweat_smile:

[rlober]

Hey @jeljaik

So first off, thank you very much for the detailed response. I will just go ahead and say that as soon as I launched matlab from ~/Documents/MATLAB/ everything worked as you thought it would so big :+1:! You may consider making this point clearer in the readme.

I don't have a problem with using CODYCO_SUPERBUILD_ROOT and CODYCO_SUPERBUILD_DIR in the readme - I understood what you guys were trying to say - but seeing as how WBIToolbox is built in superbuild, it would make sense to stick to using only the environment variables described in the superbuild readme. Another option would be to add CODYCO_SUPERBUILD_DIR to the environment variables you have to set up as a part of superbuild. The pitfall here is assuming that when people have problems they will have read everything you wrote. I know it is stupid to say but there is a lot to digest in all of the codyco related repos and it is very easy to miss a step when you aren't a developer.

Just a personal opinion so take it with a grain of salt: I get the logic behind the create_issue.sh script but I don't know if it is a great idea to have a separate way of posting issues for a single project. It seems to me like having people post env variables every time they raise an issue could be very annoying and it deviates from the typical work pipeline of github. ...It is a very nice script though :smile:

Finally as for pathdef.m and starting up matlab... I imagine you guys have your reasons for not using the startup.m functionality - maybe not to mess with the user's matlab settings as a default. But it could be nice to include instructions on how to create a startup script for those lazy people like myself who just want to be able to open matlab from anywhere using just matlab as a command.

All I had to do was create a script called startup.m in the same directory as pathdef.m and restart matlab. Because Documents/MATLAB is a default matlabpath it will run the script on startup no matter where you launch it.

startup.m

%startup.m
path(pathdef());

You could also add this to your startup_wbitoolbox.m so that it creates startup.m or appends to it with path(path, pathdef()).

I know it seems like I am telling you guys how to do your jobs but that is not my goal. I just want to give you as much feedback on the user experience as possible as I start using WBIToolbox.

Thanks again, Ryan

[francesco-romano]

Hi @rlober You are right! I never noticed that startup.m is executed every time, but pathdef not (even if it is what mathwork suggests)! Sometimes I wonder what the guys in mathwork do.... My solution was to create an alias to matlab in bash:

alias matlab='cd ~/Documents/MATLAB && /path/to/matlab`

also because in OS X there is not matlab bash script in the PATH, and the alias trick is useful in every case.

But your idea is nice. We could add the following in the startup.m (or in the doc) (pseudo-code)

if strcmp(userpath, pwd) == 0
path(pathdef())
end

[rlober]

Hey @francesco-romano

Yeah I figure there is no "one size fits all" solution to this problem but it isn't too tricky to deal with, and the instructions are pretty clear.

[francesco-romano]

cc @S-Dafarra

[francesco-romano]

@diegoferigo see this comment