Alpha 5 release (2016-04-01)

[tfoote]

• Add support for C data structures in Fast and Connext Dynamic rmw implementations @jacquelinekay
  • Connext Dynamic in review: Select between introspection_c and introspection_cpp rmw_connext#133
  • Consider ticketing eProsima to do the FastRTPS implementation.
• Support services in C Services rcl#27 (1.5 weeks) @jacquelinekay
• Figure out timer / clock sources in rcl (Disable non-steady clock sources in rclcpp for now and continue using timers as they are in rcl)
• Add arm (32 and 64) to CI

stretch / bumped goals

• Support nested messages in Python @mikaelarguedas
• Refactor rclcpp to use rcl (2 weeks) Refactor to use rcl rclcpp#204 @jacquelinekay
• Support parameters in C Parameters rcl#28 (2 weeks) @jacquelinekay
• Support Services in Python @wjwwood
• Fix all test failures
• FreeRTPS improvements: RMW support @codebot and @jacquelinekay
  • rmw_take()
  • Tie back into rmw (1 weeks)
  • Testing/CI for linux case (1 weeks)
    • Add testing and test reporting to the existing CI job
• Get first version of rostopic-like functionality, including some graph API, identifying rclpy improvements along the way. @vmayoral
• Add doc job at ci.ros2.org (call doxygen, sphinx, whatever)
• Refactor type support to have less duplication and easier reuse
• Refactor rmw to be more like rcl (3 weeks)
• rosconsole-like replacement for printf (not necessarily wire transport version or other outputs) @dirk-thomas (not yet started, after ROS 1, Qt 5)
• Add rostime sources @tfoote
• Component life-cycle in C++ as defined in the design article (with ROS-agnostic API) (2 weeks)
  • Introspection and orchestration APIs as ROS topics / services (2 weeks)
    • Use the orchestration API in launch to make tests deterministic (1 week)
  • Use C++ program to demonstrate life-cycle and orchestration in a tutorial/demo (1 week)
  • Use class_loader / pluginlib (1.5 weeks)

[dirk-thomas]

While the choice to use Python for most of the command line tools I think we should reconsider this decision. Based on experience with ROS 1 I think certain commands needs to be C++ since the startup time of a Python script might already incur a too high latency when the result is e.g. being used for auto completion. E.g. rospack providing package names and files within packages is written in C++ for exactly that reason.

[wjwwood]

I agree, but I think it would be useful to start in Python (capability should be there anyways) and actually take time to profile CLI tools afterwards. For slow tools there are lots of things you can do to speed up Python (avoiding unnecessary imports for example), and if that is not enough you can rewrite in C++. We should be wary of premature optimization.

[dirk-thomas]

I was less referring to the actual performance of the implementation but the inherent startup time of Python which has been shown to be a significant problem for auto completion (even if the tool itself would run in no time). Therefore I don't think this classifies as premature optimization but considering for which cases we already foresee that a Python based implementation will not meet the requirements of the intended use cases.

[wjwwood]

Depending on the use of the tool for tab completion the startup time of Python shouldn't be a real issue (on the order of 40 ms and on my machine rospack's is around 20ms). So, I think it's possible to use Python in tab completion if you're careful.

For example, listing directories from an environment variable (a likely task for tab completion) is only 37ms:

% time python3 -c "import os; print(['{0}: {1} items'.format(x, len(os.listdir(x))) for x in os.environ['PATH'].split(':') if x])"
['/Users/william/indigo/devel/bin: 52 items', '/usr/local/opt/ccache/libexec: 44 items', '/usr/local/sbin: 8 items', '/usr/local/bin: 638 items', '/Users/william/.bin: 1 items', '/usr/bin: 1060 items', '/bin: 37 items', '/usr/sbin: 241 items', '/sbin: 57 items', '/usr/local/bin: 638 items']
python3 -c   0.03s user 0.01s system 91% cpu 0.037 total

If I use -S to avoid unnecessary elements in the PYTHONPATH it goes down even further:

% time python3 -S -c "import os; print(['{0}: {1} items'.format(x, len(os.listdir(x))) for x in os.environ['PATH'].split(':') if x])"
['/Users/william/indigo/devel/bin: 52 items', '/usr/local/opt/ccache/libexec: 44 items', '/usr/local/sbin: 8 items', '/usr/local/bin: 638 items', '/Users/william/.bin: 1 items', '/usr/bin: 1060 items', '/bin: 37 items', '/usr/sbin: 241 items', '/sbin: 57 items', '/usr/local/bin: 638 items']
python3 -S -c   0.01s user 0.01s system 86% cpu 0.023 total

23ms is almost as fast as rospack (obviously it's doing less work, but hopefully moving away from RPP will address that).

BTW, Python2 is a good deal faster, maybe Python3's performance will improve:

% time python -S -c "import os; print(['{0}: {1} items'.format(x, len(os.listdir(x))) for x in os.environ['PATH'].split(':') if x])"
['/Users/william/indigo/devel/bin: 52 items', '/usr/local/opt/ccache/libexec: 44 items', '/usr/local/sbin: 8 items', '/usr/local/bin: 638 items', '/Users/william/.bin: 1 items', '/usr/bin: 1060 items', '/bin: 37 items', '/usr/sbin: 241 items', '/sbin: 57 items', '/usr/local/bin: 638 items']
python -S -c   0.01s user 0.01s system 83% cpu 0.016 total

So, it's not clear cut to me that starting in C++ for any tools make sense, especially when weighed against the difficulty of implementing a nice to use command line tool without argparse. I do agree both should be possible to implement based on the available functionality in Python and C++.