[Playerstage-users] Re: NEW: Player Viewer 3D 0.2 released

[smog z. <sm...@gm...>]

Hi Everybody.

I will try to respond to Jordi, Mirko Bordignon and Toby Collett.

Jordi: The modifications to the new api are mostly on the support for
multiple player clients. It is better explained in the iros 2006 article or
even better by trying it out yourself, but here is a sample of how it works=
.
Suppose we have a stage simulation / world with 3 robots + lasers and we
want to view the lasers in a OpenGL window. The xml configuration file woul=
d
go like this:
<!-- the handlers section is something like a "for each", i.e. for each
client it finds with the following sensors the following plugin will be
launched for that sensor.-->
<handlers>
 <connect>
  <playerClient host=3D"localhost" port=3D"6665">
  <playerClient host=3D"localhost" port=3D"6666">
  <playerClient host=3D"localhost" port=3D"6667">
 </connect>
<!-- here we proceed to filter the interfaces we want by name, indexNumber
and/or driverName-->
<playerDeviceMask interfaceName=3D"laser">
 <!-- the plugin(s) that are going to be launched if the interface is found
-->
 <xi:include href=3D"laser.pv3d.xml">
</playerDeviceMask>
</handlers>

it is just this simple.

Mirko: First of all thanks for your comments on Player Viewer 3D. The
provided software is nice as seen in the article, but it really starts to
shine by the ease to fast prototype new stuff.
I coded it from the requirements i got when doing my final project and
decided to go all the way with the viewer, i.e. providing a complete
framework to interact with the world and visualize sensors.
How it copes with Toby Collett Ardev will be discussed next.

Toby:
Indeed we didn't share ideais about visualizing the robot data, but that is
because i needed to get the libs working in the first place.
Visualizing data from sensors would indeed benefit from a common API(at
least for the sensor display code) so that users only have to familiarize
with one.
The only thing that would set this back is serialization of the
visualizations. Like saving a camera position, the positions of opengl
lights, should the laser show dots/lines, etc. So to get around this maybe
we could create this in a c based api where the classes are not forced.
As for the rendering of 3ds that you do i prefer the OBJ format because it
is text based.

It would be nice to have a "xml rpc" like module for player to register
extra information about the drivers, their parent physical node, and any
quick hacks that users may need to transmit information about the player
server that is not available as command configuration request. And then jus=
t
send it to the other xml client on the other end.

> The other aspect of describing the configuration would be to change all
the geometry requests in player to report a standard pose, even for planar
sensors like a laser the height is important, and so on...

A general pose request xyz + rpy+ bounding box[mesh points] would be nice,
even if some fields go with a special value like max(double) in the case of
only 2d information is provided.

--
Jo=E3o Xavier
@ smogzer_at_gmail.com
W3 http://miarn.cjb.net
Institute for Systems and Robotics
University of Coimbra