| Newsgroups |
gmane.science.robotics.orocos.user |
| Organization |
FAW Ulm |
| Message-ID |
<[email protected]> |
Dear all,
With this mail we would like to
(a) announce features that have been added to OROCOS::SmartSoft (the
CORBA based implementation of the SmartSoft framework, see
http://www1.faw.uni-ulm.de/orocos/) recenlty, and
(b) contribute to the discussion about GUIs by a brief overview of the
2d
visualization facilities of OROCOS::SmartSoft
Added features:
~~~~~~~~~~~~~~~
Shared Memory.
There are cases where it may be infeasible to interchange data between
components by value (i.e. by copying), which is SmartSoft's default
approach. A common example for such a component is a video image server,
where using shared memory is a much more adequate approach.
A class which provides access to shared memory (hiding the allocation
and
deallocation details from the user) and fits into the SmartSoft
framework
(i.e. SmartSoft will transmit only shared memory ids, besides some
administrative stuff) is now included.
Video4Linux.
Besides components for standard devices like SICK scanners and Nomad
robots, OROCOS::SmartSoft now also contains a component for accessing
Video4Linux devices. Communication between this smartVideo4LinuxServer
and
its clients is based on shared memory. Images can be retrieved by Query
or
by PushNewest. PushNewest is disabled by default due to the CPU load
which
it produces. The server has been tested with a Hauppauge WinTV PCI card
and a Philips Vesta USB Webcam. A simple client is provided to give some
visual feedback on the operation of the server.
2d Visualization Facilities in OROCOS::SmartSoft
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Visualization of 2d data (as it occurs in mobile robotics) is addressed
by
a graphics device abstraction, different implementations of the
abstaction
(for viewing, transmission, and storage of graphical output), and some
components for online visualization of data.
Graphics Device Abstraction.
OROCOS::SmartSoft provides a "Painter" class which serves as an
interface
between code that generates graphical output and code that draws shapes
onto some sort of media.
The Painter defines a set of methods for drawing geometric primitives
such
as polygons, lines, circles, text etc. The client may adapt the
painter's
length unit and coordinate system to its needs. The set of geometric
objects which the Painter is able to render can be extended without
changing the Painter interface (by means of C++ template techniques).
Painter implementations.
The "FigPainter" class stores graphical output in files using the xfig
format. It can export to various other formats (eps, jpeg, etc.), too,
if
the "fig2dev" tool (included in many linux distributions) is installed.
The DrawingStoreReplayPainter class stores graphical output and is able
to
replay the drawing onto another painter. Instances of
DrawingStoreReplayPainter can be saved/loaded to/from streams and
strings
and are used for transmission of graphical data.
The third Painter implementation is connected to a drawing widget which
can be used with the Qt GUI toolkit. Users won't create their own
instances of this Painter, but register some objects with the
"DrawingWidget::redraw(Painter&)" Qt signal.
There are more signals from DrawingWidget, for example mouse events. The
"DrawingWidgetRegionZoom" class uses these mouse signals to implement a
rubberband zoom-in function. In general, you can zoom and pan within the
DrawingWidget using the ctrl-key and the left or right mouse button.
Visualization Components.
The "smartVisualizationServer" provides a drawing area for a set of
clients (a bit like an X Server does). After registering themselves at
the server, clients send "TransmittablePainter" instances (a subclass of
"DrawingStoreReplayPainter") to the server which will be rendered to the
widget. Successively sending data updates the drawing, unregistering
removes the client's drawing.
The "smartVisualizationMultiClient" component subscribes to PushTimed or
PushNewest services and sends drawings of the received data to a
"smartVisualizationServer" target. The client currently supports mobile
robot configuration, sonar data, laser scans, and laser tracking data.
Discussion/Ideas.
- Can we implement a (generic) method for user interaction with the
visualization server? For example, we might want to send commands to a
robot when the user is dragging a graphical objects which corresponds
to
that robot. I.e. we would need a (generic) feedback channel.
- Which parts of these visualization facilities can be reused/extended
to
3d? Probably not the Painter abstractions, but the concept of a
visualization server which interacts with the user (presents the
model,
accepts/dispatches interaction events) might be worth to think about.
Visualization clients then might send a detailed description (tree of
related objects) of their "topic" only once and subsequently mainly
updates (joint angles, relative positions).
--
Boris Kluge
Research Institute for Applied Knowledge Processing
Helmholtzstr. 16, D-89081 Ulm, Germany
[email protected], phone: +49 731 501-674, fax: +49 731 501-999
Christian Schlegel
Research Institute for Applied Knowledge Processing
Helmholtzstr. 16, D-89081 Ulm, Germany
[email protected], phone: +49 731 501-8949, fax: +49 731 501-999