Replace bindings by WBT blocks through Simulink function calls #15

nunoguedelha · 2021-02-01T19:31:08Z

Implements #5 and subsequent fixes (refer to #5 (comment)).

Default iCub simulation should work exactly as before (should render same robot behavior), except that it should run approximately 3 times faster.

- Add Configuration block at the root level of the main model. - Set robot name from environment variable. - Fix `WBTConfigRobotSim` structure in configRobot.m. - Fix `confVisualizer.world_H_base` computation error ( H(4,:) was = [1 1 1 1] instead of [0 0 0 1] ) - Consolidate init.m, configRobot.m and initVisualizer.m.

…ggle button for finding the `Configuration` block. This makes clear that `RobotDynamicsWithContacts` library depends on a `Configuration` block.

… and `get_feet_jacobians`

- The frame name in a WBT is a static input parameter, not a input signal.

… that the feet frames are preset in the WBT blocks.

…straints related to that phase (supported features, table varying sizes, ...) - OSQP Matlab bindings not supported, nor `quadprog`. Use qpOASES Simulink block instead through a Simulink function `simFunc_qpOASES` sub-system. Selection is done through `setOSQP` and `useQPOASES` bool flags. - Some fields of the `robot_config` input of `step_block` Matlab System are modified or modifiable in run-time, so they cannot be Tunable. Don't set this input to `Nontunable`. - `Nontunable` inputs have to be initialized. - Cleanup `x_iDyn` variables formerly used for interfacing bindings functions. - Matrices need to be properly initialized (sparse iterative filling of matrix, as done in Matlab, is not supported, dynamic size matrices). - Unsupported features or functions like `optimoptions`, `quadprog` or `osqp` binding will cause the code generation compiler to fail even if they are wrapped in a if or switch condition. - Other features not supported in code generation are: `mat2cell`, implicit indexing ":".

- 'Size mismatch. Input 1 expected value of size [24 x 24]. Found size [:? x :?]. Mismatched varying and fixed sizes indicate a probable run-time error. If this diagnostic is incorrect, use indexing to explicitly make the varying size fixed.': Issue occurs due to imput `H` of `simFunc_qpOASES`. Simulink functions inputs are defined and set through ports, and ports need to have fixed sizes, in this case [3*<num_vertices>,3*<num_vertices>]=[24,24]. For the ports size, <num_vertices> is defined as the constant `contact_config.total_num_vertices`, while `H` size depends on `J_feet`, which is computed by `compute_J_and_JDot_nu()` from the non constant property `num_vertices` of the `Contacts` object. Set `num_vertices` `Contacts` property as `Constant`. - 'Size mismatch. Input 3 expected value of size [48 x 24]. Found size [:? x 24]. Mismatched varying and fixed sizes indicate a probable run-time error. If this diagnostic is incorrect, use indexing to explicitly make the varying size fixed.': occurs due to wrong size of 'A' built through `blkdiag`. - 'Function call resolved to MEX file '/Users/nunoguedelha/dev/osqp-matlab/osqp_mex.mexmaci64. Only MATLAB files are supported for code generation': conditional code is compiled even if the respective run condition is false (`obj.useOSQP=false`). So, flags `obj.useOSQP` and `obj.useQPOASES` have to be defined as constants. - 'Size mismatch (size [0 x 0] ~= size [3 x 29]). The size to the left is the size of the left-hand side of the assignment'. Can't assign a table (e.g. result of an operation) to a table of different size. For that reason, the pattern appending chunks to a table does not work: A = []; A = [A;B]. Refactor the computation of J, the stacked jacobians relative to the vertices that will be in contact.

- 'Dimension 1 is fixed on the left-hand side but varies on the right ([23 x 1] ~= [:? x 1])'. 's' from the right side of the equation, is computed in `State.ode_step()`. Its size appears dynamic because it is set as `s = y(end,:)`. Setting `s = y(end,1:numel(obj.s))` solves the problem. Same fix for `s_dot`. - 'Dimension 1 is fixed on the left-hand side but varies on the right ([4 x 4] ~= [:? x 4])'. Replace all instances of ':' by explicit indexes in `State.ode_step()`. - 'Dimension 1 of field 'motorGrpI' is fixed on the left-hand side but varies on the right ([23 x 1] ~= [:? x 1])': replace `(obj.robot_config.N_DOF,1)` by `size(s)`. - 'Simulink does not support persistent variables in System objects inside MATLAB System blocks.': replaced persistent variable by a class property.

- This was leading to a wrong configuration of the GetBiasForces WBT block, and subsequently, the wrong computation of the robot generalized accelerations, causing the robot to stay still indefinitely.

…lines - When a vertex is in contact, the respective line in `Aeq` is only zeros. When all the vertices of the feet are in contact with the ground, `Aeq` is a null matrix, and such null block in the overall contraints matrix causes qpOASES solver to fail, and the contact forces to be null. - For avoiding this issue, we use directly the lower/upper bounds inputs for the solver problem variable. The constraint F=0 is set using the "lb=ub=0" inputs, while an unconstrained F is obtained by setting "lb=-inf, ub=inf". This could have been obtained also by having `Aeq=Identity` and changing dynamically `beq` between 0 and inf the same way as lb, ub. - Minor fix in `expandedIdxesVerticesAtZeroVel` computation: vectorization through (:) operation instead of (1:end).

nunoguedelha · 2021-02-03T04:43:44Z

Ping @GiulioRomualdi , @Giulero .

… at 40ms - treat the visualizer as atomic unit - set its sample time to 40ms - treat the fake controller as atomic unit - set its sample time to 1ms

nunoguedelha · 2021-02-04T02:43:17Z

For the last commit, refer to #5 (comment).

Giulero · 2021-02-04T15:17:56Z

Hi @nunoguedelha ! Maybe I've something wrong in my configuration, but I've got this error

An error occurred in the block 'test_matlab_system_19/RobotDynWithContacts/MATLAB System' during compile.
Caused by:
Simulink detected an error 
 'Simulink encountered an error while allocating a handle object in MATLAB System block 'test_matlab_system_19/RobotDynWithContacts/MATLAB System'. Create the handle object only once in the corresponding System object 'robotDynWC.step_block'.'.

 The error occurred for MATLAB System block 'test_matlab_system_19/RobotDynWithContacts/MATLAB System'.    

 To prevent this error, use one of the following:
 * Modify the System object to avoid code that does not support code generation.
 * Change 'Simulate using' parameter to 'Interpreted Execution'.

Also, when the simulink model stops the file manager moves to /lib/RobotDynamicsWithContacts.

Giulero · 2021-02-04T15:24:12Z

init.m


 % Do you want to enable the Visualizer?
 confVisualizer.visualizeRobot = true;

 %% ADD CONFIGURATION FILES
+% Select the robot name from YARP_ROBOT_NAME
+robotName = getenv('YARP_ROBOT_NAME');
+


Does it make sense to add to the path src and lib here? I had to add them manually

That shouldn't be necessary if you launch the right version of test_matlab_system_19.mdl from the repo root path. When the model is loaded, the PostLoadFcn function runs the following commands:

% Set path to the utility functions and to WBC library import wbc.* addpath(genpath('./src')); addpath('./lib/RobotDynamicsWithContacts');

which adds all the required paths, including those you mentioned. for some reason you're loading the wrong mdl version. Try starting MATLAB from scratch...

Giulero · 2021-02-04T15:25:54Z

lib/+iDynTree2WBTmappers/KinDynComputations.m

+    %   Detailed explanation goes here
+
+    properties (Access = private)
+        w_H_b (4, 4) double;;


Double semicolon

Fixed in next commit.

Giulero · 2021-02-04T15:26:16Z

lib/+iDynTree2WBTmappers/KinDynComputations.m

+    properties (Access = private)
+        w_H_b (4, 4) double;;
+        s;
+        base_pose_dot (6, 1) double;;


Double semicolon

Fixed in next commit.

Giulero · 2021-02-04T15:31:03Z

lib/+iDynTree2WBTmappers/KinDynComputations.m

+                    J_LRfoot = simFunc_getFrameFreeFloatingJacobianRFoot(obj.w_H_b,obj.s);
+                otherwise
+                    error('Unsupported "getFrameFreeFloatingJacobian" input parameter.');
+                    ack = false;


Not sure about this. If the error occurs, the program should exit and the ack will be not changed, isn't it?

Absolutely. There was actually a warning. I kept the ack variable for conserving the previous interface of the usd KinDynComputations methods. I had in mind that that we might want to get back to using the bindings if some day we manage to generate C++ code from that. For that reason I created a KinDynComputations class inside a new package matlab-whole-body-simulators/lib/+iDynTree2WBTmappers.

For the sake of coherence, I removed the call to error in this method, as the ack is checked by the caller, which triggers an error on its own.

Fixed in the next commit.

Giulero · 2021-02-04T15:36:08Z

lib/+wbs/@Contacts/Contacts.m

+            indexesVerticesAtZeroVel = (allIndexes(mapVerticesAtZeroVel)-1)*3+1; % each vertex has 3 components
+            expandedIdxesVerticesAtZeroVel = [indexesVerticesAtZeroVel;indexesVerticesAtZeroVel+1;indexesVerticesAtZeroVel+2];
+            expandedIdxesVerticesAtZeroVel = expandedIdxesVerticesAtZeroVel(:);
+            J = J_feet(expandedIdxesVerticesAtZeroVel,1:end);


Love your vectorization! :D

:D actually it was the easiest solution to have a code supported by the code generator (dynamic matrices building is not supported), and have a variable J.

Giulero · 2021-02-04T15:39:09Z

lib/+wbs/@Robot/Robot.m

                error('[Robot: get_feet_jacobians] Unable to retrieve the left foot jacobian');
            end

-            if (~obj.KinDynModel.kinDynComp.getFrameFreeFloatingJacobian(obj.RFoot_frameID, obj.J_RFoot_iDyntree))
+            [ack,J_RFoot] = obj.KinDynModel.kinDynComp.getFrameFreeFloatingJacobianLRfoot('RFoot');
+            if (~ack)
                error('[Robot: get_feet_jacobians] Unable to retrieve the left foot jacobian');


Typo: left -> right

bad copy paste :D
Fixed in next commit.

nunoguedelha · 2021-02-04T20:05:13Z

Hi @nunoguedelha ! Maybe I've something wrong in my configuration, but I've got this error

An error occurred in the block 'test_matlab_system_19/RobotDynWithContacts/MATLAB System' during compile.
Caused by:
Simulink detected an error 
 'Simulink encountered an error while allocating a handle object in MATLAB System block 'test_matlab_system_19/RobotDynWithContacts/MATLAB System'. Create the handle object only once in the corresponding System object 'robotDynWC.step_block'.'.

 The error occurred for MATLAB System block 'test_matlab_system_19/RobotDynWithContacts/MATLAB System'.    

 To prevent this error, use one of the following:
 * Modify the System object to avoid code that does not support code generation.
 * Change 'Simulate using' parameter to 'Interpreted Execution'.

Also, when the simulink model stops the file manager moves to /lib/RobotDynamicsWithContacts.

Hi @Giulero , it stops in RobotDynamicsWithContacts everytime it stops due to an error, otherwise it stops in the original repo root folder matlab-whole-body-simulators. I would say this is a normal behavior.
I never saw this error before. Could you start MATLAB from scratch and try again?

nunoguedelha · 2021-02-04T21:07:58Z

Rework completed. @Giulero

…rary use of qpOASES

nunoguedelha · 2021-02-04T22:29:40Z

@Giulero , @GiulioRomualdi , I've updated the README for reflecting the Config.USE_OSQP flag deprecation.

Giulero · 2021-02-05T08:25:33Z

I tried starting Matlab from scratch and run test_matlab_system_19.
Same error :(

nunoguedelha · 2021-02-08T14:17:49Z

I tried starting Matlab from scratch and run test_matlab_system_19.
Same error :(

Hi @Giulero I'm trying to reproduce it in my environment...

nunoguedelha · 2021-02-08T18:18:32Z

Let's see if @CarlottaSartore (MATLAB 2019b + Linux) and @VenusPasandi (MATLAB2020b + Linux) have the same issue.

I definitely can't reproduce it (MATLAB 2019b + MacOS).

CarlottaSartore · 2021-02-09T12:47:49Z

My computer Configuration:

Ubuntu 18.04 LTS
matlab-whole-body-simulator
Matlab 2019b

commit e14d45088f4f4ec1896f075311538739b35c70dc (HEAD -> feature/replace-bindings-by-wbt-blocks, origin/feature/replace-bindings-by-wbt-blocks)
Author: Nuno Guedelha <nuno.guedelha@iit.it>
Date:   Thu Feb 4 23:27:04 2021 +0100

    Update the README w.r.t. the deprecation of Config.USE_OSQP and temporary use of qpOASES

IDynTree v2.0.2
WBtoolbox

Merge: 9a3848b 44f3d8b
Author: Diego Ferigo <diego.ferigo@iit.it>
Date:   Tue Nov 24 14:23:23 2020 +0100

   Merge pull request #194 from CarlottaSartore/feature/CreateCMMSimulinkBlock
   
   Created CMM Simulink Block

blockFactory

commit 4cbac726a49f6ca9a168c1d3578fd9df5a4861ed (HEAD, tag: v0.8.1)
Author: Silvio Traversaro <silvio.traversaro@iit.it>
Date:   Fri Jan 31 00:14:17 2020 +0100

    Update FindMatlab.cmake file to the version in CMake 3.16.3
    
    Ref:  https://gitlab.kitware.com/cmake/cmake/raw/v3.16.3/Modules/FindMatlab.cmake

Able to run ~1 sec of simulation (then the robot falls) and get this error

An error occurred while running the simulation and the simulation was terminated
Caused by:
MATLAB System block 'test_matlab_system_19/Robot visualizer/MATLAB System' error occurred when invoking 'stepImpl' method of 'Visualizer'. The error was thrown from '
'/home/csartore/iit_ws/robotology-superbuild/build/install/mex/+iDynTreeWrappers/updateVisualization.m' at line 21
'/home/csartore/iit_ws/matlab-whole-body-simulators/src/robotVisualizer/Visualizer.m' at line 42'.
Invalid value for Matrix property

VenusPasandi · 2021-02-09T13:58:50Z

Let's see if @CarlottaSartore (MATLAB 2019b + Linux) and @VenusPasandi (MATLAB2020b + Linux) have the same issue.

@nunoguedelha , I got the same error as @Giulero said #15 (comment) as following

An error occurred in the block 'test_matlab_system_19/RobotDynWithContacts/MATLAB System' during compile.
Caused by:
Simulink detected an error 
 'Simulink encountered an error while allocating a handle object in MATLAB System block 'test_matlab_system_19/RobotDynWithContacts/MATLAB System'. Create the handle object only once in the corresponding System object 'robotDynWC.step_block'.'.

 The error occurred for MATLAB System block 'test_matlab_system_19/RobotDynWithContacts/MATLAB System'.    

 To prevent this error, use one of the following:
 * Modify the System object to avoid code that does not support code generation.
 * Change 'Simulate using' parameter to 'Interpreted Execution'.

nunoguedelha · 2021-02-09T14:14:48Z

Just for clarifying for anyone else joining the discussion:

@CarlottaSartore : Able to run ~1 sec of simulation (then the robot falls) and get this error

This error is an old error in the visualizer that occurs only when the robot gets to that weird position..

@VenusPasandi : I got the same error as @Giulero said #15 (comment) as following

this is what we are analyzing.

@VenusPasandi , could you please specify your machine configuration?

Apart from MATLAB version (2020b), do you share the same configuration (superbuild, etc) as @CarlottaSartore ?

nunoguedelha · 2021-02-09T18:03:09Z

After discussing with @VenusPasandi and @CarlottaSartore , we confirm that both the configurations they used are identical except for the MATLAB version. I will upgrade my MATLAB version tomorrow and analyze the problem. Let's wait until Friday at least before we merge this PR.

S-Dafarra · 2021-02-10T16:12:01Z

With Ubuntu 20.04 and Matlab 2020a I had the same error as @CarlottaSartore in #15 (comment).

The robot was kind of exploding. Not sure what is the expected behavior.

S-Dafarra · 2021-02-10T16:13:11Z

Btw, I suggest checking also the terminal output in which you launched Matlab. In my case I had:

sdafarra@iiticublap104:~$ matlab
MATLAB is selecting SOFTWARE OPENGL rendering.
Gtk-Message: 16:10:16.586: Failed to load module "canberra-gtk-module"
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.
Internal qpOASES error. Trying to solve the problem with the remaining number of iterations.

that may explain why the robot was exploding.

nunoguedelha · 2021-02-11T12:31:27Z

Btw, I suggest checking also the terminal output in which you launched Matlab. In my case I had:

Yes absolutely. At that point the robot was already under the floor a priori. We were having a a similar error way before this PR. Regarding the pqOASES failure, we were planing to handle the error more properly, allowing a given number of consecutive failures while using the last valid QP result, and stopping the simulation if that max number is reached. I've just opened #16 for this.

For clarifying, the robot falling and sinking in the ground is an expected behaviour. The controller used in the test model is a fake controller, we are sending 0 torques to the joints and letting the robot fall on the ground to check the contacts handling.

S-Dafarra · 2021-02-11T12:45:20Z

For the record, this is what I see

whole_body_simulators.mp4

I also noticed that in the Diagnostic Viewer I have the message

Warning: The new value for the Matrix property may cause rendering problems.
In iDynTreeWrappers.updateVisualization (line 21)
In Visualizer/stepImpl (line 42)

It is printed at every visualization update. I confirm that the qpOases errors appear only when the robot is down below the ground.

nunoguedelha · 2021-02-11T17:10:57Z

For the record, this is what I see

Unfortunately, lately I cannot see videos attached to Github or Gitlab from Linux (probably because of Linux 20?). But I guess it matches my previous description.

Regarding the Warning, I have seen this for a while but as it is not a priori critical nor related to recent developments, I never had time to pay much attention.

nunoguedelha · 2021-02-12T05:54:28Z

After installing MATLAB 2020b, I've reproduced the issue:

Analysis ongoing...

nunoguedelha · 2021-02-12T07:25:39Z

WIP: Issue analysis (in Matlab internal code)

Error message Create the handle object only once in the corresponding System object found in the xml error definition file /Applications/MATLAB_R2020b.app/resources/SystemBlock/en/MATLABSystem.xml, mapping the key HandleObjectPersistentUnsupported.

A search on this keyword led to the help page /Applications/MATLAB_R2020b.app/help/simulink/ug/memory-management-of-handle-objects-in-generated-code.html.

We ruled out an issue related to the mask of the library.
Considering the keyword and the use cases addressed in the help page, we could guess that the issue is related to the section "A Handle Object That a Persistent Variable Refers To Must Be a Singleton Object".
Some persistent variable might be pointing the object step_block, or there is some problem with the "tunable", "nonTunable" parameters of the Matlab System block. Further analysis ongoing...

If the first 2 lines in setupImpl methhod of class step_block (the main Matlab System block) are commented, the problem does not occur:

        function setupImpl(obj)
%             obj.robot = wbs.Robot(obj.robot_config,obj.physics_config.GRAVITY_ACC);
%             obj.contacts = wbs.Contacts(obj.contact_config.foot_print, obj.robot, obj.contact_config.friction_coefficient);
            obj.state = wbs.State(obj.physics_config.TIME_STEP);
            obj.state.set(obj.robot_config.initialConditions.w_H_b, obj.robot_config.initialConditions.s, ...
                obj.robot_config.initialConditions.base_pose_dot, obj.robot_config.initialConditions.s_dot);
        end

The problem is in the very first line obj.robot = wbs.Robot(obj.robot_config,obj.physics_config.GRAVITY_ACC);.

Found where the problem is...

The issue occurs when we create a local structure in a function, set one of the fields as a handle pointing to a class object, and return that structure to the calling method which then sets another class property with that. The function "return" is done "by copy", not by reference, and this is probably what is triggering the error. I'll detail better later.

Fixing...

nunoguedelha · 2021-02-12T15:25:51Z

@VenusPasandi @CarlottaSartore @Giulero @S-Dafarra I've edited the analysis #15 (comment).

The fix is working. Pushing it in a few.

… in MATLAB System block" - The error was occuring only after upgrade to MATLAB 2020b. (Check #15) - Removed parent class "handle" from KinDynComputations class definition. - Saved changes in 2020b format file `robotDynamicsWithContacts_lib_2020b.slx`. - Exported changes in 2019b format file `robotDynamicsWithContacts_lib.slx`. - Renamed test model files adding respective suffixes 2019b, 2020a and 2020b. (test models content haven't changed apart from the Simulink version)

nunoguedelha · 2021-02-12T16:35:21Z

Fix pushed and tested. @Giulero, @GiulioRomualdi or @CarlottaSartore , can you please review the fix (very few changes) such that we merge and unblock the other depending PRs?

Additional info for the review

main functional hange is

Removed parent class "handle" from KinDynComputations class definition

because of this, the call to a class method changing the class object has to return the updated object (change in Robot.m).
This fix allowed to have the property robot_config of "step_block" as Nontunable again.
Added also robot_config to the library mask (minor change for coherence, no functional impact except that this parameter appears clearly as an input of the library, as it was already the case for contact_config and physics.config).

nunoguedelha · 2021-02-15T17:50:14Z

Hi @GiulioRomualdi , @Giulero , any news on the approval? Sorry to insist, it's just that this PR is critical for improving the simulator performance in another project depending on it, specially this week. CC @CarlottaSartore

nunoguedelha · 2021-02-15T19:28:35Z

Thx @Giulero ! Merging

nunoguedelha added 11 commits January 13, 2021 18:28

Add mask to the RobotDynamicsWithContacts library interface with to…

060de8a

…ggle button for finding the `Configuration` block. This makes clear that `RobotDynamicsWithContacts` library depends on a `Configuration` block.

Replace the binding methods in Robot constructor, set_robot_state…

a23498c

… and `get_feet_jacobians`

Replace the binding methods in Robot.get_mass_matrix

fbab277

Replace the binding methods in get_bias_forces, get_feet_JDot_nu

7bb5ea1

Remove unused methods get_frame_jacobian and get_frame_JDot_nu

657d30a

- The frame name in a WBT is a static input parameter, not a input signal.

Replace the binding methods in get_feet_H

23b4bec

Renamed iDynTree2WBTmappers.KinDynComputations methods to highlight…

9f361f4

… that the feet frames are preset in the WBT blocks.

nunoguedelha changed the base branch from master to prerel/prepare-v2.0.0-alpha February 1, 2021 19:31

nunoguedelha self-assigned this Feb 1, 2021

nunoguedelha mentioned this pull request Feb 1, 2021

Improve whole-body and contacts simulator core execution speed #5

Closed

nunoguedelha requested review from Giulero and GiulioRomualdi February 1, 2021 19:35

Fixed wrong gravity vector in robot configuration.

ccc1b65

- This was leading to a wrong configuration of the GetBiasForces WBT block, and subsequently, the wrong computation of the robot generalized accelerations, causing the robot to stay still indefinitely.

Base automatically changed from prerel/prepare-v2.0.0-alpha to devel February 1, 2021 22:35

nunoguedelha added 2 commits February 2, 2021 02:17

Fixed mapping of new contacts and computation of respective indexes

228d700

nunoguedelha force-pushed the feature/replace-bindings-by-wbt-blocks branch from 80e74c9 to f2184bd Compare February 3, 2021 04:37

nunoguedelha marked this pull request as ready for review February 3, 2021 04:41

nunoguedelha added 2 commits February 4, 2021 02:13

Deprecate Config.USE_OSQP and Config.USE_QPOASES.

fa2e18b

Improve the simulation speed while using the visualizer by running it…

b204833

… at 40ms - treat the visualizer as atomic unit - set its sample time to 40ms - treat the fake controller as atomic unit - set its sample time to 1ms

Giulero reviewed Feb 4, 2021

View reviewed changes

Minor fixes after review of #15.

35d4d92

nunoguedelha requested a review from Giulero February 4, 2021 21:10

Update the README w.r.t. the deprecation of Config.USE_OSQP and tempo…

e14d450

…rary use of qpOASES

Giulero approved these changes Feb 15, 2021

View reviewed changes

nunoguedelha merged commit 266512a into devel Feb 15, 2021

nunoguedelha deleted the feature/replace-bindings-by-wbt-blocks branch February 15, 2021 19:31

nunoguedelha mentioned this pull request Jun 8, 2024

Robot fixed base sinks into the ground at constant speed #94

Open

Replace bindings by WBT blocks through Simulink function calls #15

Replace bindings by WBT blocks through Simulink function calls #15

Conversation

nunoguedelha commented Feb 1, 2021 • edited Loading

nunoguedelha commented Feb 3, 2021

nunoguedelha commented Feb 4, 2021

Giulero commented Feb 4, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nunoguedelha commented Feb 4, 2021

nunoguedelha commented Feb 4, 2021

nunoguedelha commented Feb 4, 2021

Giulero commented Feb 5, 2021

nunoguedelha commented Feb 8, 2021

nunoguedelha commented Feb 8, 2021

CarlottaSartore commented Feb 9, 2021 • edited Loading

VenusPasandi commented Feb 9, 2021

nunoguedelha commented Feb 9, 2021

nunoguedelha commented Feb 9, 2021

S-Dafarra commented Feb 10, 2021

S-Dafarra commented Feb 10, 2021 • edited Loading

nunoguedelha commented Feb 11, 2021

S-Dafarra commented Feb 11, 2021

nunoguedelha commented Feb 11, 2021

nunoguedelha commented Feb 12, 2021

nunoguedelha commented Feb 12, 2021 • edited Loading

WIP: Issue analysis (in Matlab internal code)

Found where the problem is...

nunoguedelha commented Feb 12, 2021

nunoguedelha commented Feb 12, 2021

Additional info for the review

nunoguedelha commented Feb 15, 2021

nunoguedelha commented Feb 15, 2021

nunoguedelha commented Feb 1, 2021 •

edited

Loading

Giulero commented Feb 4, 2021 •

edited

Loading

CarlottaSartore commented Feb 9, 2021 •

edited

Loading

S-Dafarra commented Feb 10, 2021 •

edited

Loading

nunoguedelha commented Feb 12, 2021 •

edited

Loading