Re: Announcement: GDHE 3.2

On Thu, 26 Jun 2003, Matthieu Herrb wrote:

[...]
>  > - how difficult would it be to extend GDHE to interactively
>  >   _construct_ robot models, including definition of kinematics
>  >   objects, such as Tool Centre Point etc.?
> 
> The main difficulty is that GDHE currently can't be used directly to
> get 3D inputs from the user. You can add sliders or numerial input
> widgets to the Tk interface to input data, but there's no simple way
> to click on an object in the OpenGL window to select it (and move it
> or do whatever you want).

Any idea where the origin of the problem lies? Is it with Tk, or is it
just something you have not yet implemented?

> However the construction of models is still pretty interactive through
> the TCL interpreter. Having the hability to parameterize your models and
> then interactively change the parametrs with a visual feedback helps a
> lot. 

This interaction is through a "command line interface"?

Do you plan to add some "symbolic representation" of all 3D objects?
(As the scene graph in Coin3D or so.)

> You can also place frames at specific points of interest in your
> model in order to visually verify a given property, for instance that
> they a point is fixed while you change other kinematic parameter. 

What exactly are "points of interest"? Vertices and edges and planes
of 3D objects? Are frames "connected" in one way or another to these
object primitives? (I.e., the frames at the points of interest move
together with the object primitives.)

> We were able to verify that the reverse kinematic model of the
> manipulator mounted on hilare2 is correct by comparing the theoretical
> position given by the model with the position reached by the GDHE
> model for a set of calculated generalized coordinates. 

Ok! This seems something I can ask students to extend and generalize
in a project :-)

>  > - how difficult would it be to add an external "plug in" for, for
>  >   example, calculation of a robot's kinematics or motion planning?
> 
> GDHE is designed to be essentially a visualisation system. So this
> kind of plugins don't really match my conception of GDHE. However one
> of our collegues at LAAS  used it it this way : he plugged
> matlab+simulink and GDHE together and is able to extract the code to
> display his robots from his simulink models. 

Is this "plug in" facility in the current code? Is it on your roadmap?

[...]
> To external applications, I don't know what kind of events you're
> thinking of. 
Just events :-) The exact meaning and result of an event depend on the
external application.

[...]
> In distibuted multi-robots applications, if all robots send their
> position to GDHE, it becomes possible to detect some events
> (collisions,...) in GDHE and send them back to the robots because GDHE
> becomes the only centralisation point of the application. But you
> don't want to do that if you're working on a distributed
> architecture...
Why not? _Somewhere_ one has to have a component that has information
about all distributed component that need to be synchronized in one
way or another, isn't it?

>  > - is the integration of "plotting" functionality on your roadmap?
>  >   (I.e., visualizing the positions or velocities of a robot.)
> 
> You can do 2D graphics by switching to the parallel projection mode
> and placing the observer orthogonally to the plan where you put all
> data. However there are no axis, curves, or similar objects in the
> current code. This could be added. (and it could use exising plotting
> widgets instead too). 
Ok, it would be nice if you could post some pointers to which kind of
plotting widgets you are thinking about...

[...]
>  > - do you somewhere have a roadmap and corresponding TODO list for the
>  >   project?
> 
> I don't have a written one yet. As I said adding 3D user interaction
> is probably the major point on this list. This requires to revisit the
> way objects are defined, in order to be able to attach some structural
> data to the OpenGL facets that will be returned from a user
> selection, so it will not be a trivial change. 

Ok, I understand. Maybe something to start discussing about :-)
On the Orocos GUI workshop, the examples of Coin3D/OpenInventor/Java3D
were mentioned, which support this kind of interaction by allowing to
put callbacks in several places in the "graphics pipeline". Maybe the
Tcl/Tk environment has similar primitives... (I am not at all an
expert :-)

[...]
>  > I tried to build the package (Debian Linux, unstable 2.4.20), but got
>  > this failure in the ./configure step:
[...]
> You probably need  to specify --with-tcl= with the path to the
> directory containing the Tcl 8.4 tclConfig.sh file. 
That will probaly work! Before I found out about the CLI option, I
changed already the hard coded directories in the configure script :-)
Debian seems to install Tcl and Tk in /usr/lib and /usr/include.

I am now still ahving some problems with the fact that I haven't
mkdep on my system. But I will solve that :-)
(But the configure script doesn't check for this dependency.)

Thanks for the feedback! I hope we can get some support for GDHE going
:-) (But also for possible alternatives, such as the above-mentioned
Coin3D or Java3D.... Many things will have the same desings and
problems, I guess.)

Herman

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