[Bf-committers] CAD/Robotics extensions to Blender (Was Re: CVS commit: editobject.c)

[Herman Bruyninckx]

On Tue, 27 Jul 2004, Ton Roosendaal wrote:

>> - creation of "mechanical" devices, which has traditionally a somewhat
>>   different user interface than animation and games.
>
> If that would mean like an new articulated Object type (let's say "Robot") 
> with its own specific editing controls and methods, and which can be used for 
> animations as well?

I don't think it needs so much robot-specific additions. Let me try to
make myself clear: the current way of building armatures is that you
point-click-move with the mouse and create a serially connected set of
links connected by spherical joints. Later, you can/should add
constraints if you don't want spherical joints; or you should connect
different serial armatures together. What I have in mind is a second
"factory" method, in which you can select the kind of joint at each
click (basically 1D revolute or 1D prismatic or 1D helical), and the
geometry of the armature link (basically, dimensions in X, Y and Z).
Other extra properties of joints are: limits and "zero position".
A possible third factory method to create armatures is that you _first_
create the shapes, placing XYX frames at the positions where you later
want to add a joint between two shapes; then you select such a frame and
indicate what kind of joint you want to attach to what axis of that
frame; and then you select a second shape to connect to that.

This is for the UI stuff. For the algoritmic stuff, it would consists of
inverse kinematics algorithms with the same API, except maybe that one
can select the most appropriate algorithm from a set of available
alternatives. I have an overview of "kinematic families" here:
  <http://www.orocos.org/documentation/kindyn-doc.html#kinematic-families>
Each of these families can be given a much more efficient IK than the
general purpose IK algorithms in Blender.

[...]
> And if such articulated Robot models can be interactively positioned, moved 
> with IK and force 'feedback'? 
What do you mean exactly with "force feedback"?

>> - addition of IPOs that are common in robotics, e.g., for redundant
>>   systems, with so-called "trapezoidal acceleration profiles" etc
>
> That's new for me, but sounds intersting! :)
It's old science in robotics :-) Look here for some more technical
details, but don't expect miracles:
  <http://www.orocos.org/documentation/interpolation-api.html>
I don't yet have documentation online (or code implemented) for the
realistic dynamics IK, but it is not too hard. I mean, two-three weeks
for a undergraduate student. Because this is one of my hopes: I'm
teaching a robotics course, and Blender is very attractive to young
people, and I want them to be able to code useful robotics stuff into
Blender, because writing code is the best way to _really_ understand an
algorithm.

>> [...] But it would be nice to get an idea about the
>> "veto proneness" of the "robotics additions"  I suggested above.
>> If you think they are of really secondary importance, than I'd better
>> start looking elsewhere :-)
>
> Well, it all starts with showing the ideas, prototypes, or a proposal. This 
> is new!
Hopefully (don't hold your breath!) our summer interns will be able to
show some "proof of concept" examples, where we do the kinematics
implementations outside of Blender, and just move the Blender objects
via a Python plugin...

> A fork can be done too. As for example could be possible for the game engine 
> (a game-blender) and/or when another engine likes to have Blender as 'level 
> editor', and so on. This could also benefit in development towards beter 
> modules in Blender to keep compatiblity...

I don't like to speak about "forks", but about "modules": a common
infrastructure (with maybe some configuration possibility to include or
not specific sets of features), on top of which one adds one or more
"domain specific" application modules. The common infrastructure would
contain things like: the UI, the file formats, the geometric database
and modelling functionality. Modules could be: CAD-like modelling;
animation; robotics; ...

However, finding the most appropriate boundaries to make modules is not
an easy task :-)

Herman

-- 
   K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480