Roadmap

From The Player Project

(Difference between revisions)
Jump to: navigation, search
 
Line 9: Line 9:
* Player: Alternative transport methods. Make Player able to be used as client/server, or as a distributed architecture (see [http://www.is.aist.go.jp/rt/OpenRTM-aist/html-en/ OpenRTM]).   
* Player: Alternative transport methods. Make Player able to be used as client/server, or as a distributed architecture (see [http://www.is.aist.go.jp/rt/OpenRTM-aist/html-en/ OpenRTM]).   
-
 
+
* Player: Clean up documentation. Make sure all config file options are documented, and all configuration requests are listed.
-
* 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.  
+
* Player: Verify all drivers use lengths and angles from config files internally.
-
 
+
* Player: Compile all drivers a plugin drivers, install to common subdirectory in libdir. Write parsing code that finds all driver names. Leave shell drivers in libplayerdrivers
-
* 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 =
= Player Development Roadmap =

Latest revision as of 02:30, 1 January 2012

Contents

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!

  • Player: Alternative transport methods. Make Player able to be used as client/server, or as a distributed architecture (see OpenRTM).
  • Player: Clean up documentation. Make sure all config file options are documented, and all configuration requests are listed.
  • Player: Verify all drivers use lengths and angles from config files internally.
  • Player: Compile all drivers a plugin drivers, install to common subdirectory in libdir. Write parsing code that finds all driver names. Leave shell drivers in libplayerdrivers

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.
  • Review if the documentation is up to date
  • Write upgrade guide / user visible changes Changelog

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
  • Move to subversion
  • Add a light weight passthrough?
  • 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>.

Release 2.1.1

  • Fix build on OSX

Release 2.1.2

  • Bugfix release

Release 3.0

  • Documentation
    • architecture, bumped to later release
    • tutorials
    • See all releases documentation points.
  • Build system rework
    • Switch to cmake
    • 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.
  • Interfaces
    • Review units used in the GPS interface Reviewed, will not change.
    • Review/revise ranger interface
    • Deprecate the laser, sonar and ir interfaces (recommend use of the ranger interface for client writers (via lasertoranger, etc) and new drivers, but don't remove the old interfaces yet).
    • Look at what other interfaces can be deprecated (is any of the old audio stuff hanging around, for example?)
    • Delete deprecated mcom interface?
    • Review pluggable interface support
    • Review the several @todo in the player interface, it is 3.00 material?
    • Normalize subtype names (PLAYER_PTZ_REQ_GEOM vs PLAYER_POSITION2D_REQ_GET_GEOM) Not worth the effort
  • 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) - bumped to 4.0
  • Clean up libplayerc swig interactions or write new Python bindings using an alternative system such as SIP or boost.python.
  • Make sure Player is capable of being built without debug (mainly involves changing asserts to proper error checks in drivers).

Release 3.0.1

  • Bugfix/maintenance release

Release 3.1

  • Add capability requests to drivers
  • Add properties to drivers
  • Build servers.
  • Documentation
    • architecture
    • tutorials

Release 3.2

  • Unit tests etc (integrate with CTest?)
  • Provide alternate transport layer with build (ICE, RMI, UDS ... ?).
  • Merge blackboard and property behaviours
  • Add support for multiple server subscriptions to client libs
  • Add multilanguage driver support (probably a C API with a fops type structure for callbacks, then wrapped in standard c++ driver)
  • Clean up duplication in transport layer code.
  • Fix server-side time in message headers.

Release 4.0

  • Zeroconf
  • deprecate Client libs
    • Add functionality to write all client code easily as a driver
    • Provide 'filter' classes that act in a similar way to the client proxies but for drivers
  • Hide RequestConfigure and Geom in the client libs, call them automatically when needed.
  • Multi language drivers
  • robot data aware middleware
    • 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)
  • Remove 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.


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.
Personal tools