How to bridge additional PubSub topics

By default BB.Jido.Plugin.Robot only subscribes its PubSubBridge to [:state_machine]. This guide shows how to forward additional BB topics into your agent.

When to do this

Add a topic when an action or plugin in the agent needs to react to something other than state-machine transitions — for example a sensor reading, a safety error, or a parameter change.

Pass :topics when attaching the plugin

defmodule MyRobot.Agent do
  use Jido.Agent,
    name: "my_robot",
    plugins: [
      {BB.Jido.Plugin.Robot,
       %{
         robot: MyRobot,
         topics: [
           [:state_machine],
           [:safety, :error],
           [:sensor, :force_torque]
         ]
       }}
    ]
end

Each entry is a list of atoms — the same format that BB.PubSub.subscribe/3 accepts. The list is appended on top of the BB defaults, not merged, so include [:state_machine] explicitly if you still want it.

Restrict by payload type

Subscribing to a path delivers every payload published on that path or its descendants. Restrict at the PubSub layer with :message_types:

{BB.Jido.Plugin.Robot,
 %{
   robot: MyRobot,
   topics: [[:sensor]],
   message_types: [BB.Sensor.JointState, BB.Sensor.ForceTorque]
 }}

The filter is per-bridge (one bridge per agent), so it applies to every subscribed topic.

Check the resulting signal types

Each forwarded message becomes a Jido.Signal with a stable type string:

So a sensor publishing on [:sensor, :force_torque] becomes bb.pubsub.sensor.force_torque. Subscribe an action to it via:

signal_routes: [
  {"bb.pubsub.sensor.force_torque", MyRobot.Actions.HandleFT}
]

The signal carries the original %BB.Message{} in signal.data.message.

See also

• Reacting to PubSub — end-to-end walkthrough.
• Throttle high-volume signals — keep 100Hz topics from drowning the agent.
• Signal types reference — full type table.