From a03fb5b6b20ccb497e3567d103c0d81f2451eedf Mon Sep 17 00:00:00 2001 From: Christophe Bedard Date: Tue, 14 May 2019 17:00:08 +0200 Subject: [PATCH] Add initial design draft --- design.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 design.md diff --git a/design.md b/design.md new file mode 100644 index 0000000..190cd3f --- /dev/null +++ b/design.md @@ -0,0 +1,36 @@ +# Design + +Plan for ROS 2 tracing & analysis effort. + +## Steps + +This general effort will be split into a few distinct steps. + +### Instrumentation + +The first goal is to statically instrument ROS 2, aiming for it to be in the ROS 2 E-turtle release (Nov 2019). + +This includes transposing the existing ROS 1 instrumentation to ROS 2, wherever applicable. This step may not include instrumenting DDS implementations, and thus may be limited to the layer right before `rmw`. + +The plan is to use LTTng with a ROS wrapper package like `tracetools` for ROS 1. + +### Analysis + +After the initial instrumentation, some general statistics analyses can be built. The goal is to make those general enough to be useful for different use-cases, e.g.: + +* Callback duration (mean, stdev, etc.) +* +* + +Generic tracepoints should also be provided for ROS 2 user code, which could then be applied to a user-provided model for higher-level behaviour statistics. + + +### Tools/accessibility + +To make tracing ROS 2 more accessible and easier to adopt, we can put effort into integrating LTTng session setup & recording into the ROS 2 launch system. + +This might include converting existing `tracetools` scripts to more flexible Python scripts, and then plugging that into the launch system. + +### ROS 1/2 compatibility + +Finally, we could look into making the instrumentation work on both ROS 1 and ROS 2, through a common interface (or other abstraction).