Jido v2 plugin that gives an agent the ability to control a Beam Bots robot.

Provides:

• The standard robot-control actions: BB.Jido.Action.Command, BB.Jido.Action.Reactor, BB.Jido.Action.WaitForState, and BB.Jido.Action.GetJointState.
• Default signal routes for the canonical bb.* signal types, including routes that keep the plugin state current: bb.state.transition is routed to BB.Jido.Action.UpdateSafetyState and bb.safety.error to BB.Jido.Action.RecordSafetyError.
• Plugin-owned state under agent.state.robot: the configured :robot module, a cached :safety_state (updated by the routed UpdateSafetyState action whenever a safety transition arrives), the :last_safety_error (updated by RecordSafetyError when the [:safety, :error] topic is bridged), and :last_joint_state (updated whenever GetJointState runs).
• A supervised BB.Jido.PubSubBridge mounted under the agent process that forwards BB PubSub events to the agent as Jido signals.
• An optional fail-closed safety gate: actions listed in :gated_actions are refused before execution unless the robot's safety controller reports :armed.

Configuration

Plugin config (passed via {BB.Jido.Plugin.Robot, %{...}} when attaching to an agent) is validated against the plugin's config_schema when the agent is defined, so a missing, mistyped, or unrecognised option fails fast with a schema error rather than surfacing later at runtime:

• :robot — robot module (required).
• :topics — list of BB.PubSub paths to bridge (default [[:state_machine]]; replaces the default rather than adding to it).
• :message_types — payload modules to filter on at subscribe time (default [], meaning no filter).
• :throttle_ms — optional per-signal-type throttle in milliseconds.
• :gated_actions — list of action modules refused via prepare_action/3 unless BB.Safety.state/1 reports :armed (default []). See below.

Bridged topics beyond the defaults need matching signal routes on the agent (or plugin) — signals without a route are reported as routing errors through the agent's error policy.

Safety gating

With gated_actions: [BB.Jido.Action.Command, BB.Jido.Action.Reactor], any routed signal that resolves to one of those actions is refused with {:error, {:safety_not_armed, state}} before the action executes, using an authoritative BB.Safety.state/1 read (fast ETS). This is the plugin-level counterpart to the per-action BB.Jido.Action.SafetyAware mixin: the mixin travels with the action module wherever it's used, while the gate is enforced centrally for signal-routed execution on this agent. The gate fails closed and cannot be bypassed by the routed action's own params: a gated action whose params name a robot other than the configured one is rejected with {:error, {:robot_mismatch, details}} rather than authorised against the wrong robot's safety state.

The gate only sees signal-routed execution — direct run/2 calls (e.g. reactor steps) bypass it, so keep using SafetyAware for actions that must be guarded everywhere.

Example

defmodule MyRobot.Agent do
  use Jido.Agent,
    name: "my_robot",
    plugins: [
      {BB.Jido.Plugin.Robot,
       %{robot: MyRobot, gated_actions: [BB.Jido.Action.Command]}}
    ]
end

The plugin is a singleton: one robot per agent, and as: aliasing is rejected at agent definition. To control several robots, run one agent per robot.