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 would 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="localhost" port="6665">
  <playerClient host="localhost" port="6666">
  <playerClient host="localhost" port="6667">
 </connect>
<!-- here we proceed to filter the interfaces we want by name, indexNumber and/or driverName-->
<playerDeviceMask interfaceName="laser">
 <!-- the plugin(s) that are going to be launched if the interface is found -->
 <xi:include href="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 just 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ćo Xavier
@ smogzer_at_gmail.com
W3 http://miarn.cjb.net
Institute for Systems and Robotics
University of Coimbra