CYN-X Robot — Functional Requirements Specification
Version: 0.1 — Initial Robot Architecture Status: Living / Development Specification Target: 2–3 ft humanoid robotic skeleton Primary computer: Variscite DART-MX93 / NXP i.MX93 Architecture: Distributed actuator + sensor system
1. System Purpose
CYN-X shall be a small humanoid robotic platform designed to provide a physical embodiment for the CYN-X software/AI system.
The robot shall prioritize:
Modularity
Accessible development
Replaceable components
Distributed real-time control
High-level AI autonomy
Safe actuator control
Open software interfaces
Incremental development
The first-generation robot is not required to be a fully autonomous walking humanoid.
It shall instead provide a scalable physical platform in which increasingly sophisticated capabilities can be developed.
2. Overall Architecture
CYN-X shall use a layered architecture:
CYN-X ROBOT
│
┌────────────┴────────────┐
│ │
High-Level Computer Real-Time Hardware
DART-MX93 │
│ │
Linux / CYN-X OS │
│ │
AI / Planning │
Vision │
Robotics API │
│ │
└──────────┬──────────────┘
│
Robot Bus
│
┌──────────┼──────────┐
▼ ▼ ▼
Actuator Actuator Actuator
Controller Controller Controller
│ │ │
Motor Motor Motor
│ │ │
Joint Joint Joint
FR-ARCH-001
The robot shall separate high-level computation from real-time actuator control.
FR-ARCH-002
The DART-MX93 shall not be required to directly generate motor PWM for every actuator.
FR-ARCH-003
Motor controllers shall perform low-level motor-control functions where supported.
FR-ARCH-004
The CYN-X software shall communicate with actuators through a standardized hardware abstraction layer.
3. Main Computer
FR-CMP-001
The robot shall use the DART-MX93 as the primary high-level computer.
FR-CMP-002
The primary computer shall run a Linux-based operating system.
FR-CMP-003
The computer shall provide the runtime environment for CYN-X software.
FR-CMP-004
The computer shall provide interfaces for:
robot control
sensor processing
communications
networking
AI inference
diagnostics
logging
configuration
FR-CMP-005
The architecture shall permit replacement of the main computer without requiring replacement of every actuator controller.
4. CYN-X Robot Software
CYN-X shall not directly expose hardware-specific implementation details to higher-level behaviors.
Instead:
CYN
│
▼
Robot API
│
▼
Hardware Abstraction Layer
│
├── REV actuator
├── Other actuator
├── Servo
├── Sensor
└── Custom CYN-X hardware
FR-SW-001
The robot shall provide a unified software API for actuators.
FR-SW-002
The API shall support commands including:
enable
disable
stop
velocity
position
current/torque limit where supported
acceleration limits where supported
FR-SW-003
The API shall provide actuator telemetry including, where available:
position
velocity
current
voltage
temperature
controller state
fault state
encoder state
FR-SW-004
Hardware-specific APIs shall be isolated behind adapters.
This means CYN-X can eventually change from a REV controller to a custom CYN-X controller without rewriting the entire robotics stack.
5. Actuator System
The robot shall use electronically controlled motors for major joints.
Potential joint classes include:
shoulder
elbow
wrist
hip
knee
ankle
neck
The initial prototype does not need all of these.
FR-ACT-001
Each powered joint shall have an electronically controllable actuator.
FR-ACT-002
Each actuator shall have a defined control interface.
FR-ACT-003
The actuator system shall support closed-loop control where the selected controller provides it.
FR-ACT-004
The robot shall obtain joint feedback through integrated or external encoders.
FR-ACT-005
The system shall detect actuator faults where supported.
FR-ACT-006
A failed actuator shall not prevent the rest of the system from reporting the failure.
6. REV / FTC Ecosystem Compatibility
CYN-X shall leverage existing robotics infrastructure rather than recreate it unnecessarily.
REV already provides motor-controller hardware with CAN, USB and PWM interfaces, and SPARK MAX/Flex have documented software/API resources.
FR-REV-001
The CYN-X architecture shall permit the use of REV motor controllers.
FR-REV-002
The CYN-X software shall isolate REV-specific communication behind a driver/adapter.
FR-REV-003
The robot shall not require the REV Hardware Client to remain running during normal robot operation.
FR-REV-004
The REV Hardware Client may be used for initial configuration, firmware management, diagnostics, and development, but shall not constitute the CYN-X runtime.
REV documents CAN operation for SPARK MAX/Flex and provides API resources; this makes that class of controller particularly suitable for a direct CYN-X actuator layer.
FR-REV-005
The system shall not make the CYN-X architecture dependent upon the FTC competition Robot Controller application.
This distinction matters because FTC's official control system normally uses a Control Hub or Android device + Expansion Hub as its robot controller.
7. Robot Communications Bus
The robot shall use a deterministic device communications bus for distributed hardware.
FR-CAN-001
The actuator network shall support CAN-compatible communication.
FR-CAN-002
Each networked actuator shall have a unique device identifier.
FR-CAN-003
The system shall support bidirectional communication.
FR-CAN-004
The robot computer shall be able to:
send commands
receive telemetry
receive faults
discover/configure devices where supported
FR-CAN-005
The communications layer shall be abstracted from the robot API.
CYN-X API
↓
Actuator HAL
↓
CAN Driver
↓
Controller
FR-CAN-006
The protocol architecture shall permit future migration to CAN-FD or another higher-bandwidth bus without requiring redesign of the high-level robot API.
8. Joint Model
CYN-X shall represent the physical robot as a collection of joints.
Example:
CYN-X
├── head
│ └── neck_yaw
│
├── left_arm
│ ├── shoulder
│ ├── elbow
│ └── wrist
│
├── right_arm
│ ├── shoulder
│ ├── elbow
│ └── wrist
│
├── left_leg
│ ├── hip
│ ├── knee
│ └── ankle
│
└── right_leg
├── hip
├── knee
└── ankle
FR-JNT-001
Every controllable joint shall have a unique software identifier.
FR-JNT-002
Each joint shall expose its capabilities to the CYN-X software.
FR-JNT-003
The system shall support joint limits.
FR-JNT-004
The system shall support configurable direction/inversion.
FR-JNT-005
The system shall support calibration procedures.
FR-JNT-006
The system shall maintain a logical relationship between joint position and physical position.
9. Sensors
The robot shall support distributed sensors.
Initial sensor categories:
joint encoders
IMU
cameras
motor telemetry
temperature
battery voltage/current
FR-SEN-001
The robot shall provide an IMU interface.
FR-SEN-002
The robot shall provide joint-position feedback.
FR-SEN-003
The robot shall support at least one camera interface.
FR-SEN-004
Sensor drivers shall be modular.
FR-SEN-005
Sensor data shall be available to CYN-X's perception and control systems.
10. Power System
FR-PWR-001
The robot shall use a centralized battery/power architecture appropriate for the selected motors and controllers.
FR-PWR-002
The system shall monitor battery voltage.
FR-PWR-003
The system shall monitor power faults where hardware supports such monitoring.
FR-PWR-004
The system shall provide a physical means of disabling actuator power.
FR-PWR-005
The main computer shall not be the sole mechanism for emergency actuator shutdown.
That's important for a physical robot: software can fail.
11. Safety
This gets a big section because CYN-X will eventually have moving limbs.
FR-SAF-001
The robot shall have a physical emergency-stop mechanism.
FR-SAF-002
Emergency stop shall remove or inhibit actuator power independently of normal high-level software.
FR-SAF-003
The robot shall have configurable joint limits.
FR-SAF-004
The robot shall support configurable velocity limits.
FR-SAF-005
The robot shall support configurable current/torque limits where supported.
FR-SAF-006
The robot shall detect loss of communication with actuator controllers.
FR-SAF-007
Loss of high-level computer communication shall cause actuators to enter a defined safe state.
FR-SAF-008
The robot shall prevent unintended motion during startup.
12. Diagnostics
FR-DIA-001
CYN-X shall provide a system health state.
Example:
CYN-X HEALTH
─────────────
Computer OK
CAN OK
Battery 87%
IMU OK
Left shoulder OK
Right shoulder OK
Left knee WARNING
Camera OK
FR-DIA-002
The robot shall log actuator faults.
FR-DIA-003
The robot shall log communications faults.
FR-DIA-004
The robot shall log sensor failures.
FR-DIA-005
The robot shall provide diagnostic information without requiring the REV Hardware Client during normal operation.
13. Development Architecture
CYN-X shall be designed so that development can happen incrementally.
FR-DEV-001
The first prototype shall be operable with a single actuator.
FR-DEV-002
The software shall support simulated actuators.
FR-DEV-003
A simulated robot shall be usable without physical motors.
FR-DEV-004
Individual joints shall be testable independently.
FR-DEV-005
Hardware drivers shall be replaceable without modifying high-level behavior code.
14. Incremental Prototype Requirements
I really like this part for CYN-X.
Prototype 0 — Software
DART-MX93
│
CYN-X software
│
simulated joints
Goal: prove the software architecture.
Prototype 1 — One actuator
DART
│
controller
│
motor
Goal: prove the complete command → controller → motor → telemetry loop.
Prototype 2 — Arm
shoulder
│
elbow
│
wrist
Goal: prove coordinated joints.
Prototype 3 — Torso + arms
Goal: prove multi-joint coordination.
Prototype 4 — Legs
Goal: develop balance and locomotion systems.
Prototype 5 — Full 2–3 ft CYN-X
Goal: integrated robot.
15. High-Level CYN-X Interface
Ultimately, the AI shouldn't need to know anything about CAN frames.
It should be able to reason at this level:
cyn.robot.left_arm.shoulder.move_to(45)
cyn.robot.right_arm.elbow.set_velocity(0.5)
cyn.robot.head.look_at(target)
cyn.robot.stop()
The stack underneath handles:
AI intent
↓
Robot behavior
↓
Motion planning
↓
Joint controller
↓
Actuator abstraction
↓
REV/CAN driver
↓
Motor controller
↓
Motor
That is the core CYN-X idea I'd preserve.
16. Future Requirements
The architecture shall not prevent future additions including:
autonomous walking
computer vision
speech
manipulation
balance control
force sensing
tactile sensing
mapping
navigation
local AI inference
remote teleoperation
simulation
additional CAN devices
custom CYN-X motor controllers
custom sensor boards