robotics-software-principles

Applies SOLID design principles to robotics software architecture and code review.

Updated Aug 16, 2026
One-click install
npx skills add https://github.com/three1324/yeonjinautomotive --skill robotics-software-principles-three1324
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: robotics-software-principles
Source: https://github.com/three1324/yeonjinautomotive/tree/main/.claude/skills/robotics-software-principles
Command: npx skills add https://github.com/three1324/yeonjinautomotive --skill robotics-software-principles-three1324

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Robotics code fails in ways ordinary software does not: physical damage, missed real-time deadlines, sensor noise, and sim-to-real gaps. This Skill provides twelve concrete design principles with code examples so robot software modules stay decoupled, safe, testable, and reusable across hardware platforms. ## Core Features & Use Cases - SOLID for Robotics: Adapts Single Responsibility, Dependency Inversion, Open-Closed, Interface Segregation, and Liskov Substitution to hardware interfaces like arms, grippers, and cameras, with Python ABC examples. - Robotics-Specific Principles: Covers separation of rates (control loops vs. perception threads), fail-safe defaults, idempotent commands, configuration over code, structured telemetry, composable skills, and graceful degradation. - Code Review Checklist: A 12-item quick-reference table for reviewing robotics modules, e.g. checking whether perception blocks the control loop or whether commands are safe to retry. - Use Case: When refactoring a perception-planning-control pipeline or designing a hardware abstraction layer so the same task code runs on a real UR5 and a MuJoCo simulation, apply these principles to structure interfaces and dependency injection. ## Quick Start Ask the AI to review your robot control module against the robotics software design principles and suggest refactoring toward hardware-independent interfaces.

Frequently Asked Questions about robotics-software-principles

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I apply SOLID principles to robotics software?

Apply SOLID by defining abstract interfaces for hardware (arms, cameras, grippers) with Python ABCs, keeping each module to one responsibility, and injecting implementations at startup. High-level task code depends only on abstractions, never on concrete drivers.

How do I design robot code that runs in both simulation and real hardware?

Use dependency inversion: high-level logic depends on abstract interfaces like ArmInterface, with separate implementations for the real robot (e.g., UR5 via RTDE) and the simulator (e.g., MuJoCo). Caller code stays identical because both honor the same contract.

Why does perception block my robot control loop?

Blocking happens when slow perception (e.g., a 200ms detector call) runs inside a 100Hz control loop. Fix it by running perception in its own thread and passing results through a lock-protected shared buffer, so the control loop always uses the latest available detections.

What are fail-safe defaults in robot software?

Fail-safe defaults mean modules start in the safest state: low velocity limits, collision checking enabled, explicit enable required, and stop on communication timeout or sensor loss. Dangerous behavior must be explicitly opted into rather than being the default.

When should robot parameters go in configuration files instead of code?

Put anything that varies between deployments in configuration: robot IP addresses, joint limits, sensor parameters, safety thresholds, and workspace boundaries. Keep algorithms, control logic, data structures, and interface definitions in code.