Apollo CyberRT

Cyber RT provides two ways to build applications:

1. Binary based: The application is a standalone binary that creates its own Reader and Writer to communicate.
2. Component based: The application is compiled into a Shared Library (.so). The framework dynamically loads it using a DAG (Directed Acyclic Graph) configuration file.

Component Advantages:

• Flexible deployment via launch files.
• Change received channel names in the DAG file without recompiling.
• Supports multiple data types and fusion strategies.

Essential Interface:

• Init(): Performs algorithm initialization (similar to main).
• Proc(): A callback function triggered by the framework when a message arrives (similar to a Reader callback).

class MyComponent : public Component<MessageType, MessageType> {
 public:
  bool Init() override;
  bool Proc(const std::shared_ptr<MessageType>& msg) override;
};
CYBER_REGISTER_COMPONENT(MyComponent)

The common-msgs package is organized into subdirectories by functional domain. Each subdirectory contains the specific message definitions for that module. Key message groups include:

• Core/Basic: basic_msgs, transform_msgs
• Vehicle Control & Chassis: chassis_msgs, control_msgs, drivers_msgs
• Sensing & Perception: perception_msgs, prediction_msgs, sensor_msgs, localization_msgs
• Planning & Navigation: planning_msgs, routing_msgs, map_msgs
• System & Monitoring: config_msgs, monitor_msgs, task_manager_msgs
• External/Specialized: v2x_msgs, audio_msgs, simulation_msgs, dreamview_msgs

modules/common_msgs/
├── audio_msgs              // Message definitions of audio
├── basic_msgs              // Common message definitions
├── BUILD
├── chassis_msgs            // Message definitions of chassis 
├── config_msgs             // Message definitions of config in multiple modules
├── control_msgs            // Message definitions of control 
├── cyberfile.xml
├── dreamview_msgs          // Message definitions of dreamview
├── drivers_msgs            // Message definitions of drivers component
├── external_command_msgs   // Message definitions of external_command   
├── guardian_msgs           // Message definitions of guardian_msgs 
├── localization_msgs       // Message definitions of localization
├── map_msgs                // Message definitions of map
├── monitor_msgs            // Message definitions of monitor
├── perception_msgs         // Message definitions of perception
├── planning_msgs           // Message definitions of planning
├── prediction_msgs         // Message definitions of prediction
├── README.md
├── routing_msgs            // Message definitions of routing
├── sensor_msgs             // Message definitions of multiple sensors
├── simulation_msgs         // Message definitions for simulation
├── storytelling_msgs       // Message definitions of storytelling
├── task_manager_msgs       // Message definitions of task-manager
├── transform_msgs          // Message definitions of transform
└── v2x_msgs                // Message definitions of v2x

CyberRT uses a parameter system to allow nodes to share configuration.

ParameterService: Used by a node to host and manage parameters.

• SetParameter(const Parameter& parameter): Sets a parameter.
• GetParameter(const std::string& param_name, Parameter* parameter): Retrieves a parameter.
• ListParameters(std::vector<Parameter>* parameters): Lists all available parameters.

ParameterClient: Used by other nodes to access parameters hosted by a service node.

• SetParameter(const Parameter& parameter): Updates a parameter on the remote service.
• GetParameter(const std::string& param_name, Parameter* parameter): Fetches a parameter from the remote service.
• ListParameters(std::vector<Parameter>* parameters): Lists parameters from the remote service.

Parameter Object: Parameters can be initialized with various types including bool, int, int64_t, float, double, std::string, or even complex google::protobuf::Message objects.

Cyber RT supports multiple communication patterns for data transfer between nodes:

1. Data Streaming (Pub/Sub)

• Channel: The mechanism used to manage data communication. Users publish to or subscribe to a channel to achieve peer-to-peer (p2p) communication.
• Reader/Writer: The primary message transfer interfaces. These are typically created within a Node to read from or write to a Channel.

2. Request/Response (Service/Client)

• Service/Client: A pattern supporting two-way communication. A Client node makes a request to a Service node and receives a response.
• Parameter Service: A specialized service/client pattern that provides a global interface for accessing parameters across Cyber RT.

3. Service Discovery

Cyber RT uses a decentralized design. There is no central master node for registration; instead, nodes use Service Discovery (implemented via UDP) to find other service nodes.

CyberRT communication is based on the Talker-Listener pattern using three core abstractions:

1. Node: The fundamental unit of the framework (similar to a handle). All functional objects like writers and readers must be created from a node instance.
2. Writer: A facility used to send messages to a specific channel. Each writer is tied to a specific data type.
3. Reader: A facility used to receive messages from a channel. A reader must be bound to a callback function that is triggered whenever a new message arrives on that channel.

To use these, you must first initialize the framework using apollo::cyber::Init().

// 1. Initialize
apollo::cyber::Init(argv[0]);

// 2. Create Node
auto node = apollo::cyber::CreateNode("my_node");

// 3. Create Writer (Talker)
auto writer = node->CreateWriter<MessageType>("channel_name");

// 4. Create Reader (Listener)
auto reader = node->CreateReader<MessageType>("channel_name", [](const std::shared_ptr<MessageType>& msg) {
    // Handle message
});