From The Player Project
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.
- 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
- 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
- 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
- Bump soname and version in CVS so that CVS builds are distinct from current release
- 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>.
Fix build on OSX
architecture, bumped to later release
- 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.
Review units used in the GPS interfaceReviewed, 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).
- Add capability requests to drivers
- Add properties to drivers
- 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.
- 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.
- 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
- 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.