[Documentation] [TitleIndex] [WordIndex] 

2011-09-27 ROS Core

Agenda

  1. 'ros' debian in upstream
    • Contents:
      • rospkg
      • rospack/rosstack (requires rewrite)
      • rosdep
      • 'rosbuild lite' (some CMake infrastructure): try to be as 'normal' as possible. Overlaps with ideas of rosbuild2, and could be rosbuild2 if we convince ourselves it can survive in LTS.
      • what else?
    • Dates:
      • End of February is feature freeze for Ubuntu P, Debian import freeze is end of December, Feature Definition freeze is end of November.
      • Gerkey: would be nice to get rosbuild2 into the release
    • Deprecations
      • roslib.packages
      • roslib.stacks
      • roslib.rosenv
      • roslib.os_detect
    • Priority: HIGH
  2. rosbuild2
    • Resolve remaining integration issues, and get to the point of recommending that people use it.
    • See above
    • Priority: HIGH
  3. ros_msgs library (make message-generation code standalone-ish, possible to use ROS datastructures w/o having to be a ROS package)
    • will enable integration with standalone PCL (pull out sensor_msgs into common dependency)
    • will enable standalone rosbag library
    • Contents:
      • Python library to convert msg/srv files to parse tree
      • Msg generators that create the message files
      • std_msgs?
      • Need to separately release common_msgs for PCL
      • Want to minimize dependencies when just using generated messages
    • Need to pull out ROS_DEPRECATED, and separate serialization stuff
    • Priority: HIGH
  4. roscpp client library improvements
    • REP 106: Polled Topics. Changes client API to be able to pull messages instead of being pushed messages.
    • Gerkey: can do for TCPROS and UDPROS
    • Robert: as General Dynamics, been using something like this for awhile. Polling by default. Can work with real-time systems. RCS.
    • Dirk: can also optimize on publisher side
      • Ken: not as important; main use case is to help link/subscriber
    • Robert: Is poll N important?
      • Dirk: useful for cases where you need consecutive messages and don't care about latency as much
      • Tully: e.g. calibration can use consecutive messages.
    • Other SIGs?
    • Dirk will work on implementing this. Can put into current roscpp codebase.
    • Priority: MEDIUM
  5. rospy client library improvements
    • Possible rewrite (longer term, won't land in Fuerte)
    • Explore cython, psyco, pypy, other speed improvements
    • Fuerte will be experimental phase for rospy
  6. roslaunch rewrite (less ROS-specific, cleaner code, support rxlaunch)
    • Priority: LOW
  7. common:
    • end-of-life? (break into final unary stacks)
    • delete yaml-cpp, tinxyml backwards-compat packages
    • actionlib and bfl unary stacks
    • Tully: electric split most of common into unary stacks. tinyxml and yaml-cpp moved to external system dependencies, left in backwards compat packages. Can delete in Fuerte. Can migrate rest of packages to be unary stacks as well. Would like to ask Orocos community to take over BFL.
    • Decision: end-of-life
  8. geometry:
    • normalize bullet
    • angles unary stack?
    • eigen_conversions: not widely used, move elsewhere (unary?)
    • Tully: bullet is difficult. Didn't take all patches and are considering dropping Euler angle support, which is where are patches are (b/c they are fed up with patching Euler).
      • bullet: wim, tully, ken discussed potential plan. Take Bullet linear math library, copy it somewhere, give it a new name, and write a sed script that will migrate bt* datatypes to new name. Next cycle after we could switch to standard bullet.
      • Ken: like Eigen, can we cycle this out faster b/c we don't have control of the underlying library
      • Gerkey: fork, pull everyone over to fork, and remove bullet ROS package immediately
      • Tully: almost every method in Bullet is on the object itself
    • Tully will go through code with Troy to finalize proposal. Will attempt to get to normal bullet system dependency this cycle.
    • Tully: angles as unary stack
      • Ken: bonus points if its just a plain ole' library
      • Tully: more bonus points to push upstream
    • Tully: possible deprecate out all of geometry.
      • Ken: still would be nice to move out eigen_conversions
  9. rxconsole/rosout possible improvements:
    • would be nice to have a command-line and scriptable version of rxconsole
    • be able to query log messages after the fact (e.g., after everything has crashed)
    • Bhaskara: need simpler use of rxconsole, look back through log files
    • Ken: would be nice to get rid of log4cxx
      • Troy: can investigate, the config files makes it heavy. other use cases for compiling out log4cxx.

      • Original reasons for choosing log4cxx: http://wiki/rosconsole/Package_proposal

      • Ken: file configuration format not as essential as long as their are code APIs for manipulating it (e.g. Parameter Server (Tully)).
    • Priority: LOW/MEDIUM
  10. Node ttls, better monitoring of what's alive, etc (does this belong with 5?)
    • Not enough time this cycle
  11. Store more configuration in /etc/, e.g.:
    • General:
      • machine names (for both roslaunch and IP/hostname issues)
      • other networking config
      • roscore.xml (for adding more bootstrap services)
      On robot:
      • standard locations for robot model?
  12. Bag migration rules
    • Ken: I would like to get rid of boxturtle bmrs, requires deprecated types stick around.
    • +1 from Tully, Gerkey

Integration plan

ros ros_msgs common EOL roslib deprecations

ros debian package rospack/rosstack rewrite

October:

November:

December:

January:

2024-12-07 14:47