WBC release 2.5.2 #115
WBC release 2.5.2 #115
Conversation
…licate of floating-base-balancing-torque-control
- Replaced Gazebo interface blocks (setTorque, getPosition, etc) by:
- RobotDynWithContacts,
- IMUsensor,
- RobotVisualizer.
- Added configRobotSim.m config file specfic to the simulation, making
sure there were no collisions with configRobot.m.
- Defined Visualizer init configuration.
…kHz and the controller at 100Hz
- Define additional joints for the simulation robot model: neck joints.
The neck joints are not part of the joints controlled by the high-level torque controller.
- Fixes in the controller sub-system for settling the same Config.tStep sample time in all
the sub-system blcoks:
- Set "Inf" sampling time in reflected inertia block.
- Replaced the Holder blocks from the WBT library by a re-implementation in the "utilityBlocks"
library ("Joint Torque Saturation", "LFoot to base link transform", "RFoot to base link transform",
"State Machine").
- In the "neck transform" block, replaced port read of neck joints by input from the simulator.
(Routed neck position from main inputs of the controller system)
(Added selectors to the controller inputs for removing the neck joints, as these are processed
separately)
- Added a zero order hold to the clock input of the state machine, otherwise the sampling time type
becomes "continuous" and propagates throughout the model, preventing the compilation.
- Added a unit delay between the controller output and the simulator.
- Other minor fixes in the controller sub-system, inr:
- Removed "measured joint torques" from the visualizer.
- Routed the joint acceleration "measurements" from the main input to the joint reflected
inertia block (tags are not authorized across sub-systems when treating the parent sub-system
as an atomic unit).
- Treat the controller sub-system as an atomic unit.
…UM_BASED_TORQUE_CONTROL" as atomic unit. - Moved "Dump and visualze" into "MOMENTUM_BASED_TORQUE_CONTROL" sub-system. - Moved the "STATE_MACHINE" clock outside the controller sub-system. - Removed zero-order holder in front of that clock. - Set all controller input ports sample time to inherited. - Treat "MOMENTUM_BASED_TORQUE_CONTROL" sub-system as an atomic unit. - Replaced delay block by memory block between the controller and the simulator. - Fixed model tasking and sampling time options: Removed "Treat each dicrete rate as a separate task" option, which was causing data rates transition problems between the simulator (1kHz) and the controller (100Hz). - The model is now fully compiling.
…d joints in simulation
- Used QP interface with constraints lower bound input "lbA". Set lbA=-Inf. - For more details refer to original issue tracker https://github.com/dic-iit/element_ironcub-control/issues/164
…+ configuration) - Base position was set to [0 0 0.619], tuned to get positive contact forces from the very first simulation step.
…r as an atomic unit at 40ms sampling time
…ualizer at 10ms - Tuning tests 1 to 3 (Refer to #121) - Tuning tests 4,5,6 Controller Motor reflected inertia ON/OFF / Harmonic Drive inertia ON/OFF / Coupling ON/OFF Simulator Motor reflected inertia ON Simulator Friction = 0.2
- Test 7
Controller Motor reflected inertia OFF
Simulator Motor reflected inertia ON
Simulator Friction = 0.2 for all except the ankle pitch and roll = 0.6
=> More stable for the first 5s then same instability and divergence.
- Changed the initial joint configuration in order to bend the knees. - lower by 10cm the desired CoM hight: `StateMachine.CoM_delta(:,3) = -0.10`.
…`. Increase KD gains. - No need to add an offset to the desired CoM since the initial joint configuration already has the knees bent. There is enough margin to maintain the CoM hight when transitioning the CoM to the left or ight foot. - Increase the Gain.KD_CoM and Gain.KD_postural as the velocity feedback in the simulator is accurate. This stabilizes significantly the joint trajectory. At this point, the YOGA with support on left foot works and is stable. The robot falls when attempting the second YOGA on the right foot.
…GA left foot only
…lab-simulator Integrate the YOGA++ (floating-base-balancing-torque-control) with the matlab-whole-body-simulator
|
@gabrielenava can we release this version of whole-body-controllers without waiting for all the features listed in #94, or do you think there could be problems? For several internal issues it would be great to get this out (i.e. released, inside a conda package) soon, thanks! |
I think it is ok, the only issue it may be worth to address now is the documentation update #90, just to ensure that all changes and features are correctly documented |
Ok, @nunoguedelha do you think it is feasible? Which part of the documentation need to be updated? |
|
Well, actually #90 it's the only thing missing from #94 right?
I think this can be too long if we want to trigger the release tomorrow. And I think it wouldn't be a big deal to leave such thorough documentation for the following release. I was targeting to submit the PR documenting the YOGA+matlab-whole-body-simulator before tomorrow morning (your time), plus the merges to master, such that we put the tags. |
|
So basically, to be clear, I think we should do this merge after #126 where I'm documenting the stuff from the new model (YOGA+mwbs). |
|
Thanks, I did not noticed #90 was so complex, probably we can do a release even without all of #90 ? @gabrielenava |
Update with w.r.t. changes from after #122.
…a package +floatingBaseBalancingTorqueControlWithSimulator This avoids to: - Add the model parent folder path to the Matlab path, as well as for every new model (example) installed. It would quickly become a mess with the installation of multiple examples, with problems of file names collision. - Having 'folder1/folder2/model.mdl' and 'folder1' in the Matlab path wouldn't work well either because we wouldn't be able to call 'folder2/model.mdl' for opening the model from anywhere. - From there, the easiest solution is to use namespaces provided by Matlab packages.
To clarify, we can mark the new release of 2.6 or something like that, and then leave for 3.0 the revamped docs, the rename, etc etc. |
I did not remember either that the target of #90 was so high, with
I just meant what @nunoguedelha wrote in #115 (comment) plus a general check to verify that all readmes and wiki are updated.
Ok to me, I made already a pre-release (2.5.1), is it fine to call this release |
…Simu.mdl model init
Ok for me, @nunoguedelha ? |
|
Fine to me. So we agree that #126 goes first? I'm about to finish that one... |
Yes. |
- minor hack: in the main CMakeLists.txt of the whole-body-controllers, the script returns to the caller before running 'add_subdirectory(controllers)'. As a result, the respective CMakeLists.txt doesn't run, so we had to add the copy commands directly to the main CMakeLists.txt.
- Update README (after #122) - Converted floating-base-balancing-torque-control-with-simulator into a package +floatingBaseBalancingTorqueControlWithSimulator - Added the package installation through CMake.
|
#126 is merged on devel. We can proceed with this one. We create a merge commit, or do a fast-forward of master? @gabrielenava @traversaro |
|
It seems, from the commits tree history of the repo, that the common practice here is to fast-forward the master. Am I right @gabrielenava ? |
|
@gabrielenava , I've done a fast-forward merge, such that you just have to apply the tag |
|
@gabrielenava , since we had clearly agreed on the release, I allowed myself to rename the PR to WBC release 2.5.2. Hope you don't mind. Also reopened #94 since there is still the documentation to do. See you tomorrow. |
See the associated issue: #94
cc @nunoguedelha