Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simulation fails if run with sim command from workspace other than Base workspace #203

Open
2 tasks done
nunoguedelha opened this issue Mar 12, 2021 · 3 comments
Open
2 tasks done

Comments

@nunoguedelha
Copy link
Collaborator

nunoguedelha commented Mar 12, 2021

  • I already updated to the latest version I can use
  • I already checked similar issues using the search box

Description

If we run a simulation programmatically from a function workspace, using the command sim ...

myFunction()
...
function myFunction()

a = sim('initSimulator','SimulationMode','normal','SrcWorkspace','current');

end

... the simulation fails with the error message:

Error evaluating 'InitFcn' callback of SubSystem block '<some-system>'. 
Callback string is '%% initialize the simulation
cd(fileparts(which(bdroot)));
<some-init-script-from-where-myFunction-is-called>;'
Caused by:
Error evaluating 'InitFcn' callback of SubSystem block (mask) '<parent sub system path>/Configuration'. 
Callback string is 'source = get_param(gcb,'ConfigSource');

if strcmp(source, 'Workspace')
    object = get_param(gcb,'ConfigObject');
    WBToolbox.ConfigurationToMask(gcb, object);
end

WBToolbox.MaskToConfiguration(gcb);

clear object source
' 
[ConfigurationToMask] Failed to get WBTConfigRobot object from the workspace 

Platform

This can happen in simulation as when using the real robot.

Reproducibility

Steps for reproducing the behavior.

  1. Run MATLAB.
  2. Change directory to the root path of the repo matlab-whole-body-simulator, branch debug/issue-example.
  3. Change robot name to iCubGenova04
    >> setenv('YARP_ROBOT_NAME', 'iCubGenova04')
    
  4. Run the issueExample.m script.

Error Output

Error using issueExample>programmaticRun (line 6)
Error evaluating 'InitFcn' callback of SubSystem block (mask) 'test_matlab_system_2020b/Configuration'.
Callback string is 'source = get_param(gcb,'ConfigSource');

if strcmp(source, 'Workspace')
    object = get_param(gcb,'ConfigObject');
    WBToolbox.ConfigurationToMask(gcb, object);
end

WBToolbox.MaskToConfiguration(gcb);

clear object source
'

Error in issueExample (line 2)
programmaticRun(); - Show complete stack trace
Caused by:
    Error using issueExample>programmaticRun (line 6)
    [ConfigurationToMask] Failed to get WBTConfigRobotSim object from the workspace - Show complete stack trace

Additional information

  • OS: macOS Catalina 10.15.7
  • Version / Commit: 0db6ae4 (same content as v5.3)
  • Matlab Version: 2020b
nunoguedelha added a commit to ami-iit/matlab-whole-body-simulator that referenced this issue Mar 12, 2021
@nunoguedelha
Copy link
Collaborator Author

Analysis

The issue occurs in the InitFcn callback of the Config block, which calls ConfigurationToMask, and more specifically in line:

WBTConfigHandle = evalin('base', WBTConfigObjectName); % Get the handle

Here the function looks for the WBTConfigRobotSim (WBTConfigObjectName) systematically in the base workspace, even when we run the simulation from a function workspace and initialize all the parameters of the model in that same workspace.

Suggested Solution

A more robust approach would be to do instead the following:

  1. look for WBTConfigObjectName in the model workspace
  2. if it is not found there, look for it in the base workspace

This way, the user designing a model can chose to define the WBTConfigRobot object in the model workspace. This would be cleaner than using a workaround which copies the WBTConfigRobot to the base workspace. In general, when dealing with multiple models or when running a simulation using the sim command, it is safer to store all variables of a specific model in the respective model workspace.

What do you think @diegoferigo @traversaro ?

@diegoferigo
Copy link
Member

Nothing to object it the workaround you proposed maintains backward compatibility and solves the specific problem you described.

@traversaro
Copy link
Member

I think the proposed solution make sense, but perhaps people with Simulink experience may provide some input @gabrielenava @Giulero .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants