LTTng

Discussion

Question: How does the fact that Boost Statechart is a header only library affect our instrumentation strategy?

SMACC is effectively a ROS Wrapper for Boost Statechart, and the State Machines you write with SMACC (found in SMACC Reference Library) are the source/cpp files.

So does this mean that we don’t need to instrument BSC, and that the tracepoints will either primarily be installed inside SMACC (for common use cases) or in individual State Machines for custom cases?

What do we want to trace?

We want to trace events broadly categorized as…

  • Events Lifecycle: Queue, Transitions, Event creation?..
  • State Lifecycle: States, Client Behaviors…
  • State Machine Lifecycle: Orthogonals, Clients…
  • I/O: Actions, Services, Messages…

Events Lifecycle

To instrument the Event Queue, we need (see below) : a tracepoint for when a message is added to the queue, when it’s dropped from the queue, and when it leaves the queue

  • post_event – Added
  • process_event – Processed
  • forward_event – Processed
  • discard_event
  • transitions
  • threads

Key Files

  • Scheduler
  • Fifo Worker

State Lifecycle

Largely recurring in nature. Crucial for performance.

Items Scoped to the State…

  • State Construction
  • State Destruction
  • runtimeConfigure()
  • onEntry()
  • update()
  • onExit()
  • Creation & Destruction of State Reactor

Items Scoped to the Client Behavior…

  • runtimeConfigure()
  • onEntry()
  • update()
  • onExit()

Key Files


State Machine Lifecycle

Much takes place on start up…

  • Creation of Orthogonals
  • Creation of Clients
  • Creation of Components

I/O

We’ll assume, that users who want to trace smacc, will already have ros trace tools (& TraceCompass) installed, so we only care about when “we/SMACC” read the message (in the signal handler) and when “we/SMACC” publish the message.

Key files…

  • https://github.com/reelrbtx/SMACC/blob/master/smacc/src/smacc/signal_detector.cpp

How do we trace it?

https://christophebedard.com/ros-tracing-message-flow/ *Excellent


Existing ROS Packages


LTTng docs


Shell Scripts

After we’ve essentially created our own tracetools package, and followed the LTTng installation instructions, we then either need to use shell scripts…


Tracetool.h Headers & Functions


Tracepoint Events

Tracepoint Provider/TRACEPOINT_EVENT() MACRO Examples


Tracing Event Queues

From https://christophebedard.com/ros-tracing-message-flow/

We also need to build a model of the publisher and subscriber queues. To achieve this, we can leverage the relevant tracepoints. These include a tracepoint for when a message is added to the queue, when it’s dropped from the queue, and when it leaves the queue (either sent over the network to the subscriber, or handed over to a callback). We can therefore visualize the state of a queue over time!

How do we view it?

http://archive.eclipse.org/tracecompass.incubator/doc/org.eclipse.tracecompass.incubator.ros.doc.user/User-Guide.html

https://github.com/christophebedard/tracecompass_ros_testcases

User Space Analysis – https://archive.eclipse.org/tracecompass/doc/stable/org.eclipse.tracecompass.doc.user/LTTng-UST-Analyses.html

Kernal Space Analysis – https://archive.eclipse.org/tracecompass/doc/stable/org.eclipse.tracecompass.doc.user/LTTng-Kernel-Analysis.html

What else should we trace to make SMACC faster?

Andreas Huber Doenni’s discussion of the performance bottlenecks in Boost Statechart is outstanding…

https://www.boost.org/doc/libs/1_70_0/libs/statechart/doc/performance.html

Here’s a little description of state_cast<>…


ROS2