Class Diagrams

The library is structured around two main classes: SoarRunner and SoarAgent. SoarRunner owns the sml::Kernel, the run thread and the ROS2 service interfaces. SoarAgent wraps a single sml::Agent and owns all ROS2 I/O objects (publishers, subscribers, services, clients) for that agent.

class SoarRunner : public rclcpp::Node

Inheritance diagram for soar_ros::SoarRunner:

Collaboration diagram for soar_ros::SoarRunner:

ROS2 node that manages a Soar kernel and its agents.

Responsibilities:

• Own the sml::Kernel and the spin thread.

• Create sml::Agent instances on request and wrap them in SoarAgent.

• Expose ROS2 service interfaces to start/stop the kernel and launch the Soar Java debugger.

I/O wiring is done on each SoarAgent returned from addAgent(), not here.

class SoarAgent

Per-agent wrapper that owns all ROS I/O wiring for one Soar agent.

Returned by SoarRunner::addAgent() as a shared_ptr<SoarAgent>. User code registers interfaces directly on the agent:

auto agent = node->addAgent("MyAgent", path);
agent->addPublisher(std::make_shared<MyPub>(agent->getSmlAgent(), node, "cmd"));
agent->addSubscriber(std::make_shared<MySub>(agent->getSmlAgent(), node, "topic"));

SoarRunner calls updateWorld() on every SoarAgent each decision cycle via the smlEVENT_AFTER_ALL_OUTPUT_PHASES callback.

The following class diagram of the soar_ros::Service class (inheritance diagram) provides a basic overview of the ROS2 interface wrappers.

All ROS wrapper classes adjusted for usage with Soar are based on the input or output base classes as well as the shared interface.

template<typename T, typename pRequestType = typename T::Request::SharedPtr, typename pResponseType = typename T::Response::SharedPtr>
class Service : public virtual soar_ros::Input<typename T::Request::SharedPtr>, public virtual soar_ros::Output<typename T::Response::SharedPtr>, public soar_ros::Interface

Inheritance diagram for soar_ros::Service:

Collaboration diagram for soar_ros::Service:

The difference between service and client from the libraries perspective is only the reversal of output and input calls.

template<typename T, typename pRequestType = typename T::Request::SharedPtr, typename pResponseType = typename T::Response::SharedPtr>
class Client : public virtual soar_ros::Output<typename T::Request::SharedPtr>, public virtual soar_ros::Input<typename T::Response::SharedPtr>, public soar_ros::Interface

Inheritance diagram for soar_ros::Client:

Collaboration diagram for soar_ros::Client:

Publisher and subscriber only have either the input or the output functionality:

template<typename T>
class Publisher : public soar_ros::Output<T>, public soar_ros::Interface

Inheritance diagram for soar_ros::Publisher:

Collaboration diagram for soar_ros::Publisher:

template<typename T>
class Subscriber : public soar_ros::Input<T>, public soar_ros::Interface

Inheritance diagram for soar_ros::Subscriber:

Collaboration diagram for soar_ros::Subscriber: