Cannot open Matlab desktop when using "batch" option

[matl-hsk]

webots/src/controller/launcher/webots_controller.c

Line 905 in e9f93ae

new_argv = add_single_argument(new_argv, &current_size, "-batch");

@nilsjor
Unfortunately the change introduced in commit b43d3cd prevents (at least on Mac) to open Matlab desktop.
If Matlab is started with the argument "-batch" the command "desktop" cannot be run and produced the error

Error using matlab.internal.lang.capability.Capability.require
Support for user input is required, which is not available on this platform.
Error in desktop

Hence this should be reverted to the arguments "-nodisplay", "-nosplash", "-nodesktop", "-r" instead.

[omichel]

Thank you for this bug report.
Could you please provide a patch for this with a PR?

[nilsjor]

First of all, I should mention that I think the fix #6364 is great since it gives the user the option to choose.

Could you please help me understand what the actual issue is? You mention that batch "prevents to open Matlab desktop". This is also the point of using nodesktop.

Reading the documentation for macOS and Windows, we can see that the options "-nodesktop" and "-nodisplay" (as well as "-nojvm") are only present for macOS.

My experience on Windows is that the -batch is a strict improvement—as described here. Especially since the other options are deprecated and/or not supported. What functionality is it that you have lost on Mac?

[nilsjor]

Upon re-reading your comment a little more, I think it is becoming clearer to me.

Are you calling the command desktop as part of your controller code? If so, could you clarify what the use-case for this would be?

[matl-hsk]

Several points:

• I completely agree, that in case you just want matlab to interpret the code, the batch option should be used. This is the official way currently recommended from mathworks and seems to work best.
• Background of the issue: I wanted to use the matlab environment (command window and debugging options). The webots documentation says.

add "desktop; keyboard;" to the beginning of the controller code to bring up matlab.

However, this does not work anymore in batch mode, at least not on Mac.

• Possible solution: Seems to get complicated there since matlab has different startup options on different OS and more over some are not officially supported.

For the last point, my suggestion would be that someone with windows and linux first tests if "desktop; keyboard;" brings up matlab in batch mode on linux and windows:

1. Create a file "test.m" with the content "desktop; keyboard;"
2. from the terminal call "matlab -batch test.m" and report the result.

[nilsjor]

Thanks for the explanation! I see you are referring to the page https://cyberbotics.com/doc/guide/matlab#using-the-matlab-desktop.

I would say that this raises a more general question about the "correct" way that webots should support debugging controllers in real time...
If the same controller algorithm was written (and compiled) in C/C++ or Java, I would never assume to be able to debug it in webots during execution. I am also hesitant to whether this could be achieved using python.

For my own part, i have always used extern mode for debugging, by launching the controller separately from an open MATLAB instance directly. This would also be how I would go about it with pycharm, or any other graphical IDE for other languages.

I guess the question boils down to: What should the intended use-case for controllers written as m-files be?

When speaking with colleagues, there seems to be two perspectives:

1. A controller is a function, running autonomously in the background. Similar to python, M-files incur some overhead since each controller requires its own MATLAB interpreter to be spun up. However, this overhead is minimized by using the -batch option.
2. Unlike the other languages, MATLAB is a scripting language, and its primary users are not experienced programmers. For this reason, the graphical user-interface should be easily available for every controller run this way.

Personally, I am of the opinion that it's natural that access to GUI elements and debugging is lost when running controllers through webots. However, since the documentation encourages the use of desktop and keyboard, the functionality should be restored for now. I believe that for the the issue to be considered fixed, the documentation should be updated too.

@omichel, could you please give your perspective on this?

[nilsjor]

Also regarding the tests, I can confirm on Windows that desktopand keyboard are not supported during batch execution.

Error using matlab.internal.lang.capability.Capability.require (line 94)
Support for user input is required, which is not available on this platform.

Error using keyboard
Debugging is not supported in this configuration.

[omichel]

@nilsjor: I do fully agree with you and I believe using extern controllers is the way to go when you want to debug a controller outside of Webots. We should probably somehow add such explanations in the documentation. @matl-hsk: did you try to run a MATLAB controller as an extern controller?

[matl-hsk]

I just started using webots and was following the documentation + example. Have not tried another way. Can you point me to the documentation of how to start and use a Matlab based controller from the Matlab GUI?

[matl-hsk]

Also regarding the tests, I can confirm on Windows that desktopand keyboard are not supported during batch execution.

Then at least this behavior is consistent across the OS.
My suggestion for the PR:
Leave the "batch" option in the config GUI which leads to the behavior as is now if enabled. If not enabled then a full blown Matlab with GUI and bells and whistles is started. Calling "desktop" and "keyboard" is not longer supported as it's support in Matlab is patchy across different OS.

[nilsjor]

I just started using webots and was following the documentation + example. Have not tried another way. Can you point me to the documentation of how to start and use a Matlab based controller from the Matlab GUI?

I see. That's a shame that you ran into this issue. The gist of it is that you need to set some environment variables, which helps webots know what to do.

Paradoxically, I find the the "old" way (2023a) of running external controllers to be better for MATLAB, see this documentation here.

A script I was using for debugging the new argsument-passing looked something like:

% General setup
WEBOTS_HOME = 'C:\msys64\home\Nils\webots';
setenv('WEBOTS_HOME', WEBOTS_HOME);

WEBOTS_VERSION = 'R2023a';
setenv('WEBOTS_VERSION', WEBOTS_VERSION);

setenv('PATH', strcat(WEBOTS_HOME,'\lib\controller', ';', getenv('PATH')))

if strncmp(WEBOTS_HOME, 'C:\msys64', 9)
  setenv('TEMP', 'C:\msys64\tmp');
end

% Project-specific
WEBOTS_PROJECT = 'C:\msys64\home\Nils\webots\projects\robots\mir\mir100';
setenv('WEBOTS_PROJECT', WEBOTS_PROJECT);

WEBOTS_CONTROLLER_NAME = 'keyboard_matlab';
setenv('WEBOTS_CONTROLLER_NAME', WEBOTS_CONTROLLER_NAME);

WEBOTS_CONTROLLER_ARGS = '';
setenv('WEBOTS_CONTROLLER_ARGS', WEBOTS_CONTROLLER_ARGS);

%% Run launcher
cd(strcat(WEBOTS_HOME,'\lib\controller\matlab')); clear
launcher

The new launcher webots-controller will set all those environment variables on its own, but it has also been written to use batch...

[nilsjor]

@omichel, I have a suggestion for how to resolve this issue:

1. Leave the batch command as it is, in both webots main application and the "webots-controller" extern launcher.
2. Add an option to the webots-controller (perhaps "--desktop") which will launch the matlab controller not with -batch, but with -nosplash -r. This means that a full GUI will run. With breakpoints, debugging, workspace etc...
3. Change the documentation to reflect this. Make it clear that any sophisticated debugging (other than just printf) should be handled in external mode.

These changes should be small enough to go to the next revision, i.e., master branch.

[omichel]

Yes, that seems a very good idea. @matl-hsk: do you also agree?

[matl-hsk]

Not sure if I completely understand the suggestion, in particular where you want to add the option and where not. But in general it sounds similar to what I proposed here: #6362 (comment)

--> I agree to anything that works.

[nilsjor]

Great! I am working on a PR which will implement the suggested changes. For this reason I will close #6364. Thanks for the contribution :)

Feel free to discuss further while this issue remains open.