The Pub / Sub Paradigm - Overview

Introduction to the Topic / Sub paradigm used by Sunset.

In other systems such as WPILib command-based programming the implementor usually creates individual subsystem classes to represent their robot. One might have a drivetrain subsystem, an elevator mechanism, vision, etc. This works well for smaller, more controlled environments where design goals and constraints are very well known. This model unfortunately begins to fall apart once you need to perform lots of communication between subsystems or integrate new APIs quickly.

The Topic / Subscriber (or pub / sub) system works a little differently. The Pub/Sub paradigm defines Topics (similar to smaller, less complete subsystems) that can do nothing but send and receive messages each time their periodic method is called. In Sunset these messages will take the form of python dictionaries.

message = {
    "x"    : 22377, 
    "y"    : 19376, 
    "theta": np.radians(8300)
}

To take full advantage of the sunset logging capability, make sure all of your message types are serializable to JSON.

These messages will be sent to all of the subscribers of the sending topic once generated by the periodic method. A copy of this message will then be stored in the messages dictionary of the subscriber for it to use in its own processing.

Topics themselves inherit the subscriber class. This means that topics can receive data from other topics, this is very important and will be emphasized later. As an end user you do not need to worry about execution order of Topic trees due to Sunset's DFS algorithm that orders execution leaves first, ensuring data is not stale.