§11 · domain · 02 / 06

Robotics.

Robotics is the work of making physical systems move, sense, and act with control. It brings together mechanisms, kinematics, actuation, geometry, collision, constraints, timing, and validation — the place where software representations meet bodies, motors, instruments, and space.

Here, robotics is the bridge between geometric reasoning, complex software systems, NaadLabs, and the physical instrument work behind the Harmonic Sitar.

Robotics mark A simple kinematic chain: four joints connected by links, traced from a fixed base on the lower left to a free end-effector at upper right. BASE END
FIG · kinematic chain
KindTechnical domain
Physical focusMotion / mechanisms
SubstrateGeometric reasoning
ContextNaadLabs / Harmonic Sitar

§11.1 · definition

What "robotics" means here.
Robotics /domain/
noun · physical systems · motion

Robotics is the technical domain of physical systems that move, sense, and act. On this site it includes mechanisms, kinematics, actuation, geometry, collision checking, constraints, control, timing, and validation. The central question is how a system should be represented so a physical action can be planned, checked, controlled, and trusted.

Robotics is closely related to geometric reasoning, but the two are not identical. Geometric reasoning is the mathematical and spatial substrate; robotics is where those representations meet motors, mechanisms, instruments, constraints, and real physical consequences.

On this site
Domain
Robotics
Primary substrate
Geometric Reasoning
Lab context
NaadLabs
Music-tech example
Harmonic Sitar
Related domain
Music Technology

§11.2 · why it matters

Physical systems turn representation errors into real-world failures.

A wrong representation can move the wrong body.

Robots act in physical space. If the representation is wrong, a software error can become a collision, missed motion, unstable control loop, or unsafe physical state.

Different questions need different maps.

Reachability, collision, smoothness, timing, safety, control, and validation are not the same question. Each needs a representation that exposes the right structure.

AI alone is not a robotics architecture.

Learning systems can help at the boundary, but physical reasoning still needs structured representations for geometry, constraints, control, and validation.

§11.3 · approach

Treat robotics as representation design for physical questions.

Yoav Fekete's robotics stance starts with the question being asked. A robot is many maps at once: joint states, coordinate frames, geometry, collision volumes, trajectories, constraints, control signals, timing assumptions, and validation artifacts. Each map answers a different physical question.

The work is to choose the right representation for the task: frames for position and orientation, geometry for shape, collision volumes for contact risk, configuration spaces for reachability, constraints for allowed motion, trajectories for timing, and control signals for actuation. Geometric reasoning is the nearby mathematical substrate that makes many of these questions checkable.

For complex robotics software, Clause becomes relevant as artifact discipline: a way to keep requirements, design notes, manifests, code, tests, and validation records connected while the system changes. Robotics makes that need concrete, because software decisions eventually meet physical motion.

NaadLabs and the Harmonic Sitar give this robotics work a musical body: robotics applied to instrument R&D, performer-centered augmentation, resonance, and playable physical systems.

Stance
  • The right map depends on the question.
  • Physical reasoning needs structured representations.
  • Geometry, control, and validation stay connected.
  • Music-tech examples do not exhaust the domain.

§11.5 · working vocabulary

Configuration space Collision checking Kinematics Motion planning Geometric constraints Formal-core / statistical-boundary robotics Validation at trust boundaries

§11.6 · questions this domain opens

A robot is many maps at once

How should the same physical system be represented differently for reachability, collision, timing, control, and validation?

Geometric reasoning for robotics

Which geometric representations make frames, configuration spaces, collision volumes, and constraints checkable enough for physical systems?

Where AI belongs in robotics

How should learned systems and formal representations divide responsibility between messy inputs, planning, safety, and validation?

Robotics for musical instruments

How can robotics expand what an instrument can do while keeping the performer at the center of the system?