Interfaces
Core interfaces
Abstract interfaces for openbricks components.
MicroPython doesn’t ship full typing.Protocol support, so these are plain
base classes. Drivers should subclass the appropriate interface and fill in
every method. The higher-level modules (robotics, config) only depend
on these interfaces, never on concrete drivers — that’s what makes the system
plug-and-play.
If you add a new category of component (e.g. a distance sensor), add its interface here.
- class openbricks.interfaces.Motor[source]
Bases:
objectA bidirectional motor.
Implementations range from an open-loop H-bridge driver (L298N) to a closed-loop geared motor with quadrature encoder (JGB37-520).
Units
poweris -100..100 (percent duty cycle, sign = direction).speedis degrees per second at the output shaft (closed-loop only).angleis degrees at the output shaft (closed-loop only).
- hold()[source]
Stop and actively hold the current shaft angle via closed-loop control. Only motors with position-mode hardware (e.g. ST-3215) or a software position loop implement this; open-loop drivers raise
NotImplementedError— pickbrakeorcoastinstead.
- class openbricks.interfaces.Servo[source]
Bases:
objectA position-controlled servo (angle-addressable).
Distance sensors
Distance-sensor interface, kept separate from interfaces.py.
Why split: openbricks/__init__.py eagerly imports the four core
interfaces (Motor / Servo / IMU / ColorSensor) so that every
import openbricks pays them. The observer’s variance test runs
close to the MicroPython heap ceiling, so adding even a small class
to interfaces.py tips it over. Distance-sensor users explicitly
import this module.