first of all, thanks to Toby and Joao for sharing and explaining their ideas with us (ah, and thanks to Jordi too)
unfortunately I'm in a rush to meet some important university deadlines in the (very near) future, so I'm sad I can't go through your projects as deeply as I'd like; however I'll surely dig into them in the (unluckily not so near) future; what I think is way much important is to keep sharing ideas and exchanging comments as much as possible, in order not to duplicate efforts (as Jordi says) ... ehm, I know I'm not revealing any kind of unheard exceptional thing (believe me I didn't want to have any prophetic/arrogant tone at all, be sure), but since just a simple question spawned an interesting discussion/ideas exchange I think it's worth to go on that way
maybe this is not the most appropriate place, since it's a ML meant for p/s users... is there any related wiki we could move into? Jordi's one, maybe?
Mirko Bordignon - University of Padova, Italy
Il giorno 22/apr/06, alle ore 21:45, smog zer ha scritto:
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.
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.-->
<playerClient host="localhost" port="6665">
<playerClient host="localhost" port="6666">
<playerClient host="localhost" port="6667">
<!-- here we proceed to filter the interfaces we want by name, indexNumber and/or driverName-->
<!-- the plugin(s) that are going to be launched if the interface is found -->
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.
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.
Institute for Systems and Robotics
University of Coimbra