[Robotics] Summary of my work on Blender for Robotics

[Herman Bruyninckx]

On Wed, 1 Sep 2010, Izaak Van Crombrugge wrote:

> As my assignment comes to an end, I would like to inform you on the results.
> 
> The results are not always usable scripts, sometimes it are insights about what
> is possible and not possible (yet / any more).
> The assignment was to extend Blender 2.5 with Python scripts. The baseline was
> "Add UI panels that are useful for robotics and that make Blender more
> accessible."
> 
> Peter Roelants has worked mostly on the start of a SimCreator. He has documented
> his results on http://wiki.blender.org/index.php/Robotics:SimCreator .

To put things a bit in perspective: Leuven has/is hiring four students this
Summer, to work on this topic of a "Robotics Panel" (whatever that will
mean eventually :-)). Although I am very happy with the work they did/are
doing, the result is, of course, not nicely integrated yet; that would be
too much for these students, not only because they have no real robotics
background and miss the high-level overview and ambitions. Anyway, Leuven
will do an effort to integrate the work of all students and to deliver it
in a nice package to be integrated into the Morse source tree. But that
will take some time, and we didn't want to hold any of the results back for
too long, so there is some "release early" stuff available...

Don't base any of your developments on that stuff, because it will
definitely still change a lot :-)

> These are the topics I have been working on:
> 
> COLLADA 1.5
> ===========
> Together with Peter Roelants, we have looked into the use of COLLADA 1.5 as a
> standard format for saving and interchanging files. We have tried to do this
> starting with the ColladaImEx, the Importer/Exporter script of Blender 2.4x. We
> have ported part of this code to Python 3 and Blender 2.5. There is some usable
> code that is capable of importing a simple mesh, but it is quite experimental and
> may not be up to date with the newest naming changes in the Python API.
> 
> Working on this code and with the feedback of the mailing list, it became clear
> to us that:
> - Neither COLLADA 1.5 nor Blender 2.5 are completely stable enough to do this.
> - To avoid double or triple work, the full COLLADA 1.5 support should be
> implemented in the native importer/exporter of Blender. This is implemented using
> OpenCollada in C++. Most physics and kinematics features are absolutely no
> priority for the current developers (understandable as Blender still is an artist
> tool in the first place and implementing those features is a lot of work).

The good news is that COLLADA is getting on the radar of quite a number of
robotics projects, so I expect we could get things done by coordinating
these efforts. We'll have to discuss the strategy behind that...

> - I believe that if we really want the full physics and kinematics support, then
> an extra C++ developer may be needed to work on this.
Yes.

There is another issue with COLLADA, which does not require any coding, but
requires agreement amongst us about _how to use_ COLLADA. Let me try to
explain a bit more:
- the nice thing about COLLADA is that is has already brought a lot of
   (documented!) structure into the problem of representing robots and
   scenes, etc.
- I suggest to use that structure in morse to store stuff.
- so, introducing directories with "kinematic library", "visual scene", etc
   makes sense, but only when we have a documented procedure about how to
   use them, what to store where and in which format.


> - The current status of the COLLADA support in Blender 2.5 is not very clear and
> documentation on it is hard to find. I guess the best way to start on it is by
> following the Committers Mailing List on all COLLADA issues.
> 
> 
> Grouping and Linking/Appending
> ==============================
> In Blender 2.4x a "trick" was used to link objects in the scene that can be
> moved. In 2.5 this is No Longer Possible! The only way to get a decent working
> scene, is by Appending the objects. Saving such files is not memory efficient and
> makes synchronizing files hard.

I think the way to go is to use the COLLADA features to build armatures and
scenes: this would not only bring a _portable_ way of doing things, but it
also makes a lot of sense, in my opinion. "Sense" in the sense that we
would only reinvent the wheel if we would try to do it our own way...

> One possible workaround is to make scripts that remember what objects are
> appended, store those actions in a config file and saving only this file. When we
> want to reopen the file, we use a script that reconstructs the scene by appending
> the objects as described in the config file. This is like simulating the linking
> process through Python scripts.

COLLADA does not use "scripts" for those purposes, but "URLs", which is
fine, I think, because most of this linked information is not to be
"executed", just "loaded" (or, inversely, "saved").

> Pro:
>  - Makes linking possible.
> Contra:
>  - A lot of work to make these scripts.
>  - Not as robust and user friendly as the build in linking
> Conclusion:
>  - The linking mechanism should really be extended.
>  - Suggestion: an extra type of linking ("Game Linking") that makes it easier to
> import groups with their own id, that can be moved and that keep all there
> physics and game behaviour. But this can only be done in the source.
> 
> 
> Use of Armatures (problems with physics)
> ========================================
> One of the results of iTaSC is that armatures now also work dynamically in the
> Game Engine. This makes it possible to do real time IK solving in a simulation.
> It was suggested to use armatures for all kinds of joints (like a skeleton). But
> this is not really possible. The connections of the armature look like a Rigid
> Body Joint, but they do not work like that. They are actually a parent-child
> relation. Such a relation can not work properly for Rigid Bodies: the child
> object can not move because it is parented.
> Example: http://www.sendspace.com/file/vjwqq8 (press P in 3D view).

The problem with "physics" is not so important: the physics in Blender is
too simple for real robotics problems anyway, and the (simulation of the)
interaction between robots and their environment has to be re-engineered
anyway, I guess... It's not a high priority as far as I am concerned.

> Constraint Generator script (WIP)
> =================================
> Other problems with the armatures is that the Armature Constraints are not really
> physics constraints. The Rigid Body Joints (RBJs) are. The solution is to use
> objects and link them together using RBJs. I am currently working on a UI script
> to automate the creation and configuration of such Joints. This is still Work In
> Progress, but I hope I can continue working on it as it will be a handy feature,
> especially now the RBJ UI is partly broken in Blender 2.5 (The 6DOF is not
> configurable in the UI).
> It will be documented on the wiki:
> http://wiki.blender.org/index.php/Robotics:Scripts/constraintGenerator.

Cosntraints are a mess in Blender, for the time being. This is a
fundamental issue, which Benoit Bolsee has started to solve in a
fundamental way, but that work has to be continued. For the time being, the
lesson should be: don't rely on the current implementation of constraints.

> View Menu + Snapping
> ====================
> I have made a script that provides easy to use controls that may be handy when
> composing a simulation scene. It is described in the wiki
> http://wiki.blender.org/index.php/Robotics:Scripts/viewPanel. It also has a
> "snap" or "drop on ground" function with visual support and can be installed as
> an add-on.

I think this is the most interesting contribution of Izaak: he has really
found out and documented how to add/change panels, and that is going to be
a key part of the breakthrough of morse in robotics, since it helps novice
users to more rapidly do something useful in Blender :-)

The works still needs to be discussed a lot, mostly wrt useability, what
kind of features to support, how to include a "workflow", how to name
things, etc.

> Others
> ======
> - Packing Logic Bricks: I have been testing how to save Logic Bricks in a config
> file (using the standard configparser Python class) and reloading them. This
> could come in handy when COLLADA files would be used for the objects.
> - Info SimCreator: Added the info (read out the *.info file) when selecting
> objects and scenes. It would be interesting to show a preview image, but for now
> there is no neat way to do this directly in de Blender 2.5 UI.
> 
> 
> If anyone has questions or remarks, I will continue to participate in the BFR
> mailing list.

Thanks!!!!

Herman