Architecture Overview
OrcBot is software-first but makes an excellent brain for hardware systems. The recommended pattern keeps real-world control in a dedicated hardware bridge while OrcBot handles planning, reasoning, and high-level decisions.Why Use a Hardware Bridge?
- Safety
- Separation
- Flexibility
Bridge enforces safety regardless of AI decisions:
- Speed limits (max PWM duty cycle)
- Duration limits (max time per command)
- Obstacle detection (auto-stop)
- Emergency stop (overrides everything)
- Watchdog timer (auto-stop if no commands)
Reference Architecture
Based on the robotics blog example:Component Layers
- OrcBot Core - Planning, memory, autonomy, decision pipeline
- Hardware Bridge Service - Translates intents into robot-specific commands
- Message Bus - ROS2 topics, MQTT, REST, or serial gateway
- Safety Layer - Rate limits, e-stop, command validation
- Physical Hardware - Motors, sensors, actuators
Integration Patterns
Pattern 1: REST API Bridge
Best for: Simple robots, prototyping, web-based controlPattern 2: ROS2 Integration
Best for: Complex robots, SLAM, navigation, multi-sensor fusionPattern 3: MQTT for Multi-Robot Fleets
Best for: Multiple robots, distributed systems, cloud coordinationSafety Patterns
Layer 1: Hardware Bridge Safety
Built into bridge service:Layer 2: OrcBot Guard Rails
Built-in safety features:Layer 3: Physical Safety
Highly recommended:-
Physical E-Stop Button
-
Battery Inline Fuse
- 5A fuse between battery and motor driver
- Prevents fires from shorts
-
Bumper Switches
- Microswitch on front of robot
- Triggers software stop on physical contact
- Backup to ultrasonic sensor
Layer 4: Testing Discipline
Follow this order - no exceptions:Hardware Examples
Raspberry Pi Robot
See the complete guide in robotics blog including:- Bill of materials ($120-160)
- Wiring diagrams
- Complete Python bridge code
- OrcBot plugin implementation
- Safety systems
- Testing procedures
Arduino Integration
ESP32 WiFi Robot
IoT Device Integration
Smart Home Devices
Industrial Equipment
Best Practices
Safety First
- Always implement hardware e-stop
- Test in simulation before real hardware
- Start with low speeds and short durations
- Monitor all operations initially
- Implement watchdog timers
Separation of Concerns
- Keep OrcBot for high-level planning
- Keep bridge for hardware specifics
- Use message bus for decoupling
- Test components independently
Error Handling
- Bridge should validate all commands
- Return detailed error messages
- Log all hardware operations
- Implement graceful degradation
Monitoring
- Track command success/failure rates
- Monitor sensor readings
- Log all movements
- Alert on anomalies