In https://github.com/robotology/blender-robotics-utils/blob/master/script/urdfToBlender.py we have a URDF --> Blender rig converter that is working fine on some URDF model, but creating problems on some other models. However, debugging the problem is tricky as we do not have a clear mathematical definition and/or understanding of how the Blender Armature system ( https://docs.blender.org/manual/en/latest/animation/armatures/structure.html#chains-of-bones ) works. In this issue we will document this with mathematical notation, so it will simplify future mantainance of the software.

Unless noted otherwise, the notation used for expressing homegenous transforms is the one defined in https://research.tue.nl/en/publications/multibody-dynamics-notation-version-2, and as LaTeX formulas will be used in the issue, please install an appropriate plugin such as https://chrome.google.com/webstore/detail/mathjax-plugin-for-github/ioemnmodlmafdkllaclgeombjnmnbima?hl=en for Chrome or https://addons.mozilla.org/en-US/firefox/addon/green-pi/ for Firefox to visualize them in the browser.

cc @Nicogene

We noticed that when the user loads an already saved animation, the control panel does not correctly display the list of joint angles. The problem happens because the joints are loaded and displayed when the user presses the configure button. But when we load a configuration with an animation, the button configure is disabled, and the RCB panel is instead enabled. AS a consequence Blender cannot find the joints and the error occurs. The problem was solved by making sure that when the animation is loaded the button remains enabled, and all the rest is instead disabled.

@Nicogene and I implemented the drag and drop feature in Blender. We added a button to the RCB panel called Drag & Drop with which the user can use the mouse to reach a certain target.

The way to use the feature is described below:

1. The user selects the Base Frame and the End Effector Frame according to the joint he/she wants to move.
2. Press the button Drag & Drop to activate the feature. Once the button is pressed the user loses control of Blender.
3. The user moves the mouse pointer in the 3D space of Blender and clicks the right mouse button to drop the position.
4. The user clicks on the right mouse button to deactivate the drag and drop feature and to bring back the control to Blender.

The video below displays a robot animation done through the usage of the drag and drop feature:

https://user-images.githubusercontent.com/19833605/167880668-5176a0c1-3110-41dc-be9f-8e0565752430.mp4

This PR adds a section in the panel for reaching a cartesian target defined in terms of transformation (xyz position + rpy rotation) with the end-effector frame, respect to the base frame.

End effector frame and base frame can be selected by combobox as is shown in this video:

https://user-images.githubusercontent.com/19152494/165498930-224c3871-620a-4c6c-9162-7e30c3578265.mp4

This PR adds some improvements to the RCB Panel which ease the interaction with the robot, in particular:

• the user can now upload a .json to configure the robot's parts.
• the robot's parts are now displayed in a very intuitive list where its state (connected/disconnected) is highlighted through the use of an icon

This PR adds an extra check in the RCB panel, for skipping the targets that are outside the joints' boundaries.

The limits are already set in the rig, but also if the joint in the rig does not goes over the limit, in the blender UI the angle value is not capped and it seems that from the API you get that value that is outside the boundaries, leading to a situation where the target can never be reached by the real robot.

TO BE TESTED(at least on the simulator)

Moreover, we handled the case when the urdf is not saved in the scene. In this case the "cartesian" section is disabled. Finally, we committed the visuomanip rig containing its urdf, in order to use the "reach target" panel.

This PR adds the list of the controllable joints from the blenderRCBPanel. When enter the values in the entries set the keyframes that form your animation.

This video displays the new behaviour of the panel

https://user-images.githubusercontent.com/19833605/159922346-0bc9cd53-1a5a-4ea1-a7f7-453bdbdc1547.mp4

This PR made the converter a panel that can be installed as addon in blender as follow:

$ cd ~/.config/blender/<blender_version>/scripts/addons/
$ ln -s /where/you/cloned/blender-robotics-utils/script/urdfToBlender  urdfToBlender

Going to Edit > Preferences > Add-ons > Testing:

If everything went fine you should have this panel on the right under the Tools section:

After clicking "Select the urdf" it will be opened a file browse such as:

After selecting the urdf, the script creates the rig of the robot in term of armature and meshes.

The rig generation is now automatically triggered by icub-models commits (see https://github.com/robotology/icub-models/pull/107)

This trigger in icub-models triggered the conversion of the V2_5 and V2_7 iCub urdf (see action) and here is the resulting commit to master of blender-robotics-utils: https://github.com/Nicogene/blender-robotics-utils/commit/6d285513ed8e0fb72592fa9221c1cb6ba1e02faa

It is now possible to create a rig from an urdf in a headless system as follow:

(Windows Powershell)

 "C:\Program Files\Blender Foundation\Blender <blender_version>\blender.exe" --python-use-system-env -b -P "C:\where\you\have\blender-robotics-utils\script\urdfToBlender.py" -- --urdf_filename "C:\where\you\have\model.urdf" --blend_filename "C:\where\you\want\to\save\myrobot.blend"

(Linux & macOs)

$ blender --python-use-system-env -b -P "/where/you/have/blender-robotics-utils/script/urdfToBlender.py" -- --urdf_filename "/where/you/have/model.urdf" --blend_filename "/where/you/want/to/save/myrobot.blend"

Currently, when setting the target to reach (or when using the drag and drop), the right part reaches the target as expected, but the left does not. We need to fix this. The suspect is that we are falling in a singularity of the kinematics: https://github.com/robotology/idyntree/issues/994

In #9 we added the possibility to publish rigs in blender-robotics-utils as soon as a change in the urdfs is made in icub-models. We should add the trigger also when just the meshes are charged.

The urdfToBlender script support for basic geometric shapes, unfortunately, Blender does not support natively boxes as primitive shapes, for now, all the box are imported as cubes, printing a warning.

We can exploit the scale.x scale.y scale.z for deforming the cube.

When we tried the panel on the real robot, we experienced several issues on some arm's joints triggering delta's greater than 5 degrees. On other joints like the one on the head and torso that threshold was fine. Probably we have to think to put different thresholds for the parts, but this is very tricky to generalize on all the possible robots.

One thing that we can do is to make the threshold "smarter" if the safety guard is triggered several consecutive times for a part, the threshold is increased for that part.

We managed to control multiple parts of iCub, but for the moment we are controlling them sequentially. This may lead to discrepancies between the animation and the movements, also if the performances are pretty satisfying so far.

The best thing would be to command all the parts in parallel via:

• Use multithreading (this may introduce other problems, counting also that we are using python)
• Use controlBoard_remapper