Re: Announcement: GDHE 3.2

You wrote (in your message from Thursday 26)
 > On Thu, 26 Jun 2003, Matthieu Herrb wrote:
 > 
 > > GDHE 3.2 released
 > [...]
 > > I'm pleased to announce that GDHE version 3.2  is now available.  
 > 
 > Great!
 > 
 > Some questions about future developments, mostly stimulated by the
 > discussions of last week's Orocos GUI meeting...
 > 
 > - 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).

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. 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. 

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. 

 > - 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. 

 > - can GDHE work with "events" to and from external applications, such
 >   as a robot controller that wants to visualise some things through
 >   GDHE?

From external application, Yes. The gdhe client library allows to send
any kind of "events" to GDHE. It's meant to be asynchrounous so that
the communication with GDHE has as little impact as possible on the
controlled process. 

To external applications, I don't know what kind of events you're
thinking of. Since Genom modules can be controlled by Tcl
scripts we are able to send requests to Genom modules from a GDHE
application. This is for instance how the LAMA user interface is
built. 

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...


 > - 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). 

 > - is TCL intervening in all drawing operations? I mean, once one has
 >   set up the kinematic structure of a robot, is the motion of that
 >   robot then only programmable through interpreted TCL scripts, or can
 >   it be attached to a compiled program?

Basically Tcl in intervening in all operations. The repaint procedure
of the OpenGL canvas calls a Tcl script that parses Tcl data
structures that describes the scene. You can access and modify these
structures from C, since the Tcl/C interface is quite easy to
understand, but they will be parsed by an interpreted script. 

 >   Have you ever noticed a performance problem with the fact that the
 >   driving commands of the simulation come from a scripting language and
 >   not a compiled language?

No, I haven't noticed any performance problem even with quite complex
scenes (several dozen of robots). The initial version of GDHE was not
using Tcl (all models were coded in C) and it was not faster on the
graphics hardware available at these time (around 1997). Tcl with it's
byte compiler is quite efficient as a scripting langage for this kind
of applications.

 > - does GDHE allow bidirectional interaction? That is, indicating
 >   a position on the simulation which is then send to a connected
 >   external application.

As I said above, currently not directly. But this is a feature that
many people requested, so it's pretty high on my TODO list. 

 > - 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. 

Other more easy things I intend to do are: a port to Mac OS X, make it
possible to add transparent/transluscent parts in the models, provide
some hooks to be able to specify material properties in the models. 

 > I tried to build the package (Debian Linux, unstable 2.4.20), but got
 > this failure in the ./configure step:
 >   [...]
 >   checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
 >   checking for gethostbyname... (cached) yes
 >   checking for connect... yes
 >   checking for remove... yes
 >   checking for shmat... yes
 >   checking for IceConnectionNumber in -lICE... yes
 >   checking if libXmu needs libXt... no
 >   ./configure: line 4544: /tclConfig.sh: Unknown file or directory
 > 
 > Any idea about what went wrong? I have the following Debian Tcl packages
 > installed:
 > ii  itcl3.1        3.1.0-7        [incr Tcl] OOP extension for Tcl - run-time
 > ii  tcl8.3         8.3.5-3        Tcl (the Tool Command Language) v8.3 - run-t
 > ii  tcl8.4         8.4.3-2        Tcl (the Tool Command Language) v8.4 - run-t
 > ii  tcl8.4-dev     8.4.3-2        Tcl (the Tool Command Language) v8.4 - devel

You probably need  to specify --with-tcl= with the path to the
directory containing the Tcl 8.4 tclConfig.sh file. I don't have a
Debian system here to check where it gets installed. 

And it there's a real bug in the configure script that makes it unable
to stop with a more sensitive error message when it can't find the Tcl
config file. 

-- 
					Matthieu