On Tue, 27 May 2003 [email protected] wrote:
[...]
> - ordinary visualization server for distributed components
> where everything from an arbitrary number of clients is
> simply displayed
"simply" :-) I think one of the things that make this desirable server
not so simple is the need for widget independence: how can we decouple
as much as possible the visualization functionality from the
visualization implementation.
Another aspect of 3D visualization: how can we use as much OpenGL as
needed/possible without committing to a widget set.
> - symbolic ("an instance of class GREEN-BOTTLE is at
> position p") vs. subsymbolic information (laser scan,
> force/torque, 3d vision depth map etc.).
I think we have a reasonably interesting approach for this, which we
call the Object-Port-Connector pattern. We will certainly talk more
about this in the near future.
> => updates of the graphic model by updating the kinematic
> chain of the graphics model
Important "framework" decision to make: what is the "callback"
implementation and design to use to do this updating.
> => several clients contribute to the same model, but the
> client coordination should be completely separated
> from the visualization server
Any concrete suggestions in this context?
> - feedback from the visualization server to client components
> - integration of classical GUI controls like sliders and
> buttons etc. where a client specifies the value range
> and the user adjusts the parameters.
Indeed: the "callback" functionality in the "opposite" direction.
> => Compare it with the X window system where the user
> interacts with the graphical representations of
> distributed clients. The X server displays the
> client's data and dispatches user events (mouse,
> keyboard)
I think X11 is a good example to start with, if only to decide which
features _not_ to implement :-)
> - point to pose where mobile platform shall move to and
> look at the visualization how progress is made towards
> the goal
...and superimpose the planned and the executed motions, if the user
desires so.
> - Combination of Open Inventor with Collision Checker
> - forward the triangles generated by Open Inventor
> to Swift / PQP collision checkers
> - worked as hack, but nothing stable ...
My impression is that Open Inventor is too much focused on being a
"viewer" and not so much an "input" interface.
> - Visualization of LOOM knowledge base
LOOM? <http://web.media.mit.edu/~kkarahal/loom/>?
> - if object is placed in midair, object is moved downwards
> till it hits a supporting object.
What performs the collision detection? How is a "stable" support
defined and calculated?
> - Game Engines are highly efficient but normally provide
> only very basic collision checkers based on enclosing
> cylinders e.g.
and they do not care about exact geometry, only about visual
appearance.
> - Interaction with physical simulation, physical realism
We have been doing some work in this direction... Needs much more
implementation helping hands though...
> - Interaction with kinematic models
Idem.
> - one should also be able to display high volume
> sensor data like laser range scans etc.
and in addition also high-bandwidth data such as e.g. control errors
from the real-time servo.
> - one should strictly separate the visualization from
> the service providing components, which means if
> several components have to know about the collision
> of their displayed objects that has to be communicated
> between the clients and a collision checker and not
> by the visualization component which is only responsible
> for visualization. The visualization component is not
> the common world model ...
All these "collision detection clients" register their "callbacks"
with the collsion detector component. I think this basically solves
this decoupling problem, doesn't it?
> - therefore no activity nodes as available in "open
> inventor" where one can move objects along a trajectory
> etc.
???
Desired features I would like to add:
- interface to make robot models interactively, with correct kinematics
(classified in different families, or with a default numerical
algorithm.)
- "Labview"-like interfaces and interface builders, to interface with
"control-like" components.
- full dynamic humanoid simulation.
- Automatic GUI configuration based on the (CORBA) interfaces of
components in the robot system that wants to e visualized.
- ...
Herman
--
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.