Build Configurations & Variants

Build Configurations

Build Configurations (BCs) are templates that define the ideal robot design - the “as-designed” state.

What They Define

• Components: List of parts that should be installed
• Subassemblies: Grouped components that swap together as units
• Maintenance Rules: Scheduled maintenance triggers
• Version: Human-readable version like “v2.1”

Why They Matter

Build Configurations serve as the baseline for tracking changes. When you modify a robot, Botbit compares against its original BC to determine if the robot is still conformant or if a variant should be created.

Example Structure

Build Config: "AMR-v3.0"
Status: Active
Version: v3.0

Components:
├── Jetson Xavier NX (Main Computer)
├── Velodyne VLP-16 (LiDAR Sensor)
├── 200Ah Lithium Battery
├── RoboClaw 2x30A (Motor Controller)
└── Navigation Module (Subassembly)
    ├── IMU Sensor
    ├── GPS Module
    └── Wheel Encoders

Robots Using This Config: 12 robots
Variants Created: 3 variants

Configuration Variants

Variants are automatically created when robots deviate from their original Build Configuration. They capture the actual, real-world configuration after field changes.

When Variants Are Created

Botbit creates a new variant when you make a non-conformant change:

Change Type	Creates Variant?	Why
Add component not in original BC	✅ Yes	Changes robot structure
Remove component from original BC	✅ Yes	Changes robot structure
Swap to different component type	✅ Yes	Changes component specification
Swap same type, different serial	❌ No	Just maintenance - same design

Example Scenario

1. Activate Robot “Alpha” using BC “AMR-v3.0”
2. Robot operates for 3 months
3. Replace 200Ah battery with 300Ah battery (different model)
4. Botbit automatically:
   • Creates variant “AMR-v3.0-Var-1”
   • Increments robot version to 2.0
   • Links robot to the new variant
   • Logs change to history

Now:

• Original BC: AMR-v3.0 still defines the design standard
• Current Config: AMR-v3.0-Var-1 reflects actual installed components
• Robot shows: “Modified from AMR-v3.0 (87% conformant)“

Why Variants Are Valuable

Track Real Configurations: If 5 robots all get the same upgrade (300Ah battery), they’ll all use “AMR-v3.0-Var-1”. You can see which robots share actual configurations.

Activate New Robots with Proven Configs: Found that Var-1 works better in production? Activate new robots directly using the variant configuration.

Understand Design Evolution: See how your robot designs evolved over time based on field experience.

Monitor Standardization: Dashboard shows “8 robots on AMR-v3.0, 3 robots on Var-1, 1 robot on Var-2” - see fleet homogeneity at a glance.

Retroactive Editing

Retroactive Editing allows you to add or remove components from an Active Build Configuration and automatically propagate those changes to all robots using that configuration.

When to Use

Scenario	Use Retroactive Editing?
Add sensor to all robots of a model	✅ Yes
Remove deprecated component from fleet	✅ Yes
Fix design oversight in deployed robots	✅ Yes
Test new component on subset of robots	❌ No - modify individual robots
Major design revision	❌ No - create new BC version

How It Works

1. Navigate to the Active Build Config and click Edit
2. Add or remove components as needed
3. A confirmation modal shows the count of affected robots
4. Click Apply Changes to propagate

On Add:

• New component created on each robot (serial blank, marked conformant)
• History event logged: “Component added via BC update”

On Remove:

• Component deleted from all robots using the BC
• History event logged: “Component removed via BC update”

Key Behaviors

Behavior	Description
Atomicity	All-or-nothing. If any update fails, everything rolls back.
Conformance	Added components are conformant: true. Removed components are deleted entirely.
Subassemblies	Adding/removing a subassembly includes all nested components.
Zero robots	If no robots use the BC, edit proceeds immediately with no propagation.
Concurrent edits	Protected via optimistic locking - refresh required if BC was modified.

Example

Your 50 delivery robots need a new emergency stop button:

1. Go to Build Configs → “Delivery-Bot-v2.3” (Active)
2. Click Edit → Warning: “Changes will apply to 50 robots”
3. Add “Emergency Stop Button” from library
4. Modal: “This will add Emergency Stop Button to 50 robots”
5. Click Apply Changes

Result: All 50 robots now show the new component with serial “unassigned” and a history event logged.