From Player

Contents 1 Google Summer of Code ideas 2 Player Development Roadmap 2.1 All Releases 2.2 Release Process 2.2.1 Post Release 2.3 Release 2.1 2.4 Release 2.1.1 2.5 Release 2.2 2.6 Future Releases 3 Stage Development Roadmap 3.1 Future Releases

Google Summer of Code ideas

A list of ideas for GSoC projects. Items from this list will be discussed and refined into a final list that will be made publicly available to Google and student applicants.

Deadline for ideas posted here: 9 March 2008

Some guidance on the ideas list can be found here.

Please contribute!

• P/S: Enable a native build on Windows. Includes major modifications to the build systems, plus potentially some changes to code (thread, signals, sockets, etc.), although selection of appropriate compatibility libs may mitigate the need to modify the code. [Comment from Geoff: I already have half a working CMake build system for Player that I've been working on as recently as yesterday, which would be a reasonable portion of the non-server-code-modifications portion of this project.]

• Player: Alternative transport methods. Make Player able to be used as client/server, or as a distributed architecture (see OpenRTM).

• Gazebo: Collada format support (Visual and Physics) in Gazebo. This includes being able to load entire scenes and individual modles from collada. It also implies changing the current loading and saving XML methods to be a general import/export from some kind of format manager. As a cool extension, Gazebo can connect with the models of Google Earth, as a library available to the user for instance, because they are saved in Collada format.

• Gazebo: The basic infrastructure is there but a GUI is needed for building worlds. A GUI and some features as better navigation in the world, 3d picking and moving objects are needed to make a build worlds GUI. The GUI can be used to change the properties of the objects in the simulation, add new models, add controllers to the models, etc. This work is independent but can benefit from the Collada support idea above.

Player Development Roadmap

Community discussion of features to be added to upcoming releases of player

All Releases

• Check patch tracker for any patches that should be applied.
• Fix as many bugs from bug tracker as possible.
  • Check for/fix memory leaks/errors.

Release Process

• Make sure sonames and are correct.
• Make sure version is correct
• Check Changelog
• Confirm update guide exists if needed
• If it is a N.X release branch CVS. If it is a N.N.X release tag CVS,
• Produce dist tar.gz and upload to sourceforge
• Update news on source forge
• Update wiki
• Announce release on mailing list
• Request package update on debian/ubuntu/elsewhere

Post Release

• Bump soname and version in CVS so that CVS builds are distinct from current release

Release 2.1

• Write upgrade guide, see Player 2.1 Upgrade
• Interface clean ups
  • Simplify interfaces that have driver specific elements -> change to properties
  • New vector map interface and clean out vector stuff from map interface
  • Polish generic ranger interface
• Decide solution for leaky queues
• Bring C++ client library up to date with respect to the C client library.
• Update remaining 1.6 drivers or remove them, remaining drivers can be updated when someone needs them
• Change license of libraries to LGPL (with the exception of libplayerdrivers and utils)
• Move pose structures to use doubles instead of floats. See bug 1708634 for justification.
• Change all pose information to be 3d. Do we need to formalise where a pose is measured from and record it somewhere?
• Change static arrays to dynamically allocated arrays

Release 2.1.1

• Add support for multiple server subscriptions to client libs
  • Does this remove the need for passthrough? Add a light weight passthrough?
• Zeroconf
• Clean up libplayerc swig interactions
• Move to subversion
• Fix server-side time in message headers.

Release 2.2

• Make Player capable of being built without debug (mainly involves changing asserts to proper error checks).
• Native win32 build.
• Clean up build output. We don't need to see the commands being executed, etc, unless verbose is turned on. The ideal would be seeing what file is being compiled/library is being built only. Then warnings will be easier to spot.
• Provide alternate transport layer with build (ICE, RMI ... ?).
• Clean up duplication in transport layer code
• Facilitate new interface specification. The user should be able to easily define a new interface, generate XDR bindings, and provide those bindings to other applications, all without modifying <player.h>.
• Add capability requests to drivers
• Add properties to drivers
• Merge blackboard and property behaviours
• Review new interfaces
• Review pluggable interface support
• Automatic transformation of data into robot coordinates
  • Normalise geometry requests to be the same and exist for ever driver (with a default of 0,0,0,0,0,0 for drivers that dont need it
• Hide RequestConfigure and Geom in the client libs, call them automatically when needed.
• Provide 'filter' classes that act in a similar way to the client proxies but for drivers
• Deprecate the laser, sonar and ir interfaces in favour of the ranger interface. Change all drivers to use the ranger interface, and provide rangertolaser, rangertosonar and rangertoir drivers for backwards compatibility of clients.
• Look at what other interfaces can be deprecated (is any of the old audio stuff hanging around, for example?)

Future Releases

• Improve and fully integrate resource discovery. We already have publish/subscribe semantics; we're just missing support for location-independent addressing.
• Facilitate standalone application development, so that people will write more drivers and fewer clients.
• i18n and unicode support

Stage Development Roadmap

Future Releases

• Enforce consistent updates by first updating the poses of world objects, then sensors. This assures that sensor readings correspond to the current world state rather than the world state in the previous time instant.
• Fix handling of geometry in world files and code:
  • unify polylines/polygons
  • allow specification of color per-polygon/polyline
  • subject them to the same transformations (now, polygons are scaled to "size" while polylines are not - ugh)
  • add "text"-type annotations.
• Add messages to the "simulation" driver to instantiate/destroy world objects at run time. This would enable some very interesting uses.
• Fix memory leaks/errors.