Re: Announcement: GDHE 3.2

You wrote (in your message from Thursday 26)
 > 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?

I've not yet implemented it. As I wrote it later, it will need some
work on the models to be implemented in a meaningful way, 

 > 
 > > 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"?

Yes. 

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

It will be needed in order to be able to implement a 3D user
interaction. But I'd like to be able to hide this representation for
users that don't need it. 

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

The frame I mentionned here is a visual representation (ie 3 arrows of
a given length drawed at a given position + orientation. You use the
OpenGL transforms to place it at a relative position with respect to a
given object. 
 
 > >  > - 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?

My collegue's code is not in the current code as distributed. But he's
planning to clean it up and add it to a future public version. 

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

A visualisation system only generates images. The fact that GDHE
computes some interesting data to generate those images, or that it
can also accept user input is marginal imho. 

 > [...]
 > > 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?

Not necessarly. One reason for building distributed architectures is
that you can't always have this centralized view, for instance because
of communication loss between nodes. 
But when you're debugging such a system, you often prefer to simulate
the communication problems. And then GDHE still has the full picture
of the state of each elements, even though the elements themselve are
not supposed to be able to communicate. 

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

The simplest widgets for probably those of BLT
(<http://incrtcl.sourceforge.net/blt/>). 
There is also Plplot which has a Tcl/Tk interface
(<http://plplot.sourceforge.net/>) and there are probably others that
I haven't heard of. 

 > 
 > [...]
 > >  > - 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 :-)

It seems to me that the scripting language approach offers more
flexibility here, but I haven't spent enough time on OpenInventor to
make an objective comparaison. 

-- 
					Matthieu