Part I: 먼저 확실하게 움직인다 — 고전적 플래닝과 제어

Chapter 1: 로봇 정책은 어디에서 실행되는가 — Planner에서 Motor Loop까지

집필일: 2026-07-15 최종수정일: 2026-07-15

개요

로봇 정책(policy)은 로봇 전체가 아니라 계층형 실행 스택 안에서 제한된 제안을 만드는 한 구성요소입니다. “카메라를 보고 다음 행동을 정한다”와 “모터가 그 행동을 제시간에 안정적으로 실행한다” 사이에는 task/skill 선택, motion generation, 저수준 제어, 실시간 인터페이스, 그리고 독립된 안전 권한이 있습니다. 이 장은 그 층들을 하나의 지도 위에 놓고, 각 loop의 소유자·주기·시간 기준·deadline·실패 행동을 기록하는 방법을 만듭니다.

이 장의 목표는 특정 프레임워크를 고르는 것이 아닙니다. 독자는 Chapter 2의 고전적 baseline, Chapter 5–7의 학습 정책, Chapter 8의 hybrid stack을 모두 꽂아 넣을 수 있는 실행 계약(execution contract)을 먼저 완성합니다.

학습 목표와 실험 질문

학습 목표: 이 장을 마치면 실행 계층과 권한 경계를 그리고, 각 loop의 시간·실패 계약을 검증 가능한 artifact로 남길 수 있어야 합니다.

이 장을 마치면 다음을 할 수 있어야 합니다.

  1. task intent에서 actuator까지 command가 내려가고 state·failure가 올라오는 경로를 그립니다.
  2. planner, policy, controller, hardware interface, safety supervisor의 권한을 구분합니다.
  3. 각 loop마다 owner, nominal rate, clock, deadline, watchdog, failure action을 기록합니다.
  4. 고전적 방법과 학습 방법을 “대체 관계”가 아니라 서로 다른 insertion point로 비교합니다.
  5. 하나의 tabletop assembly 명령을 proposal에서 bounded hardware command까지 추적합니다.
실험 질문: “물체를 집어 운반한 뒤 구멍에 제한적으로 삽입하라”는 명령이 들어왔을 때, 어느 프로세스가 무엇을 결정하고, 어느 시각을 기준으로 유효성을 판단하며, 어떤 조건에서 hold·replan·abort로 전환하는가?

1.1 먼저 권한 지도를 그린다

1.1.1 여섯 층과 옆에서 감시하는 한 층

이 책에서 사용할 실행 스택은 다음과 같습니다.


작업 의도 계층
  FSM · behavior tree · task planner · 향후 VLA/world-model/agent 계층
                         ↓ 범위가 제한된 skill 요청
skill·action policy 계층
  scripted primitive · BC/ACT · diffusion/flow · RL policy
                         ↓ 유효성 metadata가 붙은 action proposal
motion generation 계층
  IK · collision-aware planning · trajectory optimization · MPC
                         ↓ feasible path·trajectory·reference
저수준 제어 계층
  trajectory · position/velocity/torque · impedance/admittance/force control
                         ↓ 유효 시간이 정해진 setpoint
실시간 interface·robot controller
  ros2_control hardware interface · vendor real-time API/controller
                         ↓ actuator command
robot · gripper/hand · sensors

Independent safety supervisor
  limits · collision/force gate · watchdog · stop/fallback authority
  └──────── observes and restricts authority across every layer ────────┘
그림 1.1. Task에서 robot까지 command와 constraint가 내려가고 state와 failure가 올라오는 실행 권한 스택. 정책은 proposal만 만들며 독립 safety supervisor가 모든 층을 제한한다. — 저자 제작(OpenAI image generation 보조)

아래 방향 화살표는 단순한 명령 전달이 아닙니다. 매 단계에서 표현과 권한이 줄어듭니다. “삽입하라”는 task intent는 “접근 pose로 이동”, “접촉 탐색”, “축 방향 삽입” 같은 skill request로 나뉩니다. skill policy가 낸 Cartesian delta나 action chunk는 joint/workspace/collision/force 제약을 통과한 뒤 trajectory 또는 controller reference가 됩니다. 위 방향으로는 joint state, camera/force observation, tracking error, timeout, protective stop 같은 상태와 실패가 올라옵니다.

이 구분에는 오래된 고전 로보틱스의 핵심이 남아 있습니다. differential kinematics는 task-space motion을 joint motion으로 바꾸는 층을 분명하게 했고[1], operational-space formulation은 motion/force objective와 robot dynamics 사이의 제어 책임을 드러냈습니다[2]. 하지만 이 장은 특정 수식이나 controller가 모든 로봇에 그대로 적용된다고 주장하지 않습니다. singularity, saturation, delay, sampling, collision, hardware mode는 Chapter 2–3에서 별도로 검증해야 합니다.

1.1.2 “정책”이라는 단어를 좁게 쓴다

정책은 observation을 받아 action proposal을 내는 규칙입니다. 이 정의에는 scripted primitive, behavior cloning, ACT, diffusion/flow policy, RL policy가 모두 들어갑니다. 반면 다음 항목은 정책과 같지 않습니다.

  • Task layer는 어떤 skill을 언제 호출할지 결정합니다.
  • Motion generation은 제안된 목표를 기구학·충돌·시간 제약에 맞는 실행 경로로 바꿉니다.
  • Low-level controller는 reference와 측정 상태의 오차를 빠른 loop에서 줄이거나 접촉 동역학을 조절합니다.
  • Real-time interface는 command/state를 robot controller와 주고받고 deadline 위반을 처리합니다.
  • Safety supervisor는 상위 제안이 잘못되어도 motion authority를 제한하고 정지·fallback을 발동할 수 있어야 합니다.

이렇게 좁혀야 “모델이 action을 출력한다”는 문장이 실제 배포 권한을 과장하지 않습니다. policy output은 실행 명령이 아니라 timestamp와 유효 범위가 붙은 제안입니다.

1.2 각 층의 입력, 출력, 완료 조건

층 대표 입력 대표 출력 완료의 증거 직접 소유하지 않는 것
Task / intent 목표, scene state, FSM state versioned skill request 전이 로그, pre/postcondition motor deadline, torque authority
Skill / policy synchronized observation, task ID, policy version action proposal/chunk, confidence·age inference log, schema validation collision-free 보장, 안전 정지
Motion generation pose/action proposal, robot model, scene geometry path, timed trajectory, feasible reference planning result, constraint report 실제 tracking 안정성
Low-level control reference, measured state, gain/mode bounded setpoint/effort request tracking·contact log task 의미, scene interpretation
Real-time interface/controller timestamped setpoint, hardware state actuator-facing command and status deadline/overrun diagnostics 상위 task 성공 판정
Robot/sensors actuator command, physical interaction motion, joint/camera/force state device/fault log policy 선택
Safety supervisor state, limits, collision/force/watchdog signals permit, clamp, hold, stop, fallback independent event log and reset record task 성능 최적화

이 표의 핵심은 “누가 계산하는가”보다 “누가 권한과 실패 처리를 소유하는가”입니다. 한 프로세스가 여러 계산을 수행할 수 있지만, task success와 motor deadline을 같은 Boolean으로 뭉치면 원인 분석이 어려워집니다. OROCOS와 ros_control 계열의 공통적인 공학적 가치는 프레임워크 이름 자체보다 component/interface와 controller/hardware 경계를 명시하는 데 있습니다[3,4]. 현재 구현에서는 그 경계를 실제 driver와 controller configuration으로 다시 확인해야 합니다.

1.3 ROS 2는 연결망이지 모든 motor loop의 주인이 아니다

ROS 2는 planning, state, policy, lifecycle component를 연결할 수 있지만 motor-level loop의 owner와 timing은 platform과 driver에 따라 달라집니다[10,14,15]. 이 결론은 ros2_control, libfranka, UR ROS 2 driver를 조사한 범위에 한정되며, 모든 로봇이 같은 architecture를 가진다는 뜻은 아닙니다. 선택한 arm의 firmware, vendor controller, driver, OS와 command mode를 한 묶음으로 검증해야 합니다.

ros2_control은 controller manager가 hardware component의 read → update → write 경계를 조정하는 architecture를 제공합니다[10]. 그러나 설정된 update rate가 곧 모든 경로의 hard real-time guarantee라는 뜻은 아닙니다. OS scheduling, hardware plugin, controller execution time, transport와 vendor-side loop가 결과를 좌우합니다. Franka의 direct SDK와 UR driver는 host real-time configuration과 version compatibility에 서로 다른 조건을 둡니다[14,15]. 이 차이를 “ROS 2 주파수” 하나로 지우면 안 됩니다.

MoveIt 2의 move_group은 robot state와 planning scene을 소비하고, trajectory execution 과정에서 controller action interface로 trajectory를 보냅니다. move_group 자체가 joint state publisher나 hardware action server인 것은 아닙니다[5]. 따라서 planning success, controller acceptance, tracking success는 서로 다른 gate입니다.

예를 들어 collision-free path가 계산되어도 다음 단계에서 실패할 수 있습니다.

  • time parameterization이 빠졌거나 controller가 허용하지 않는 timing입니다.
  • joint trajectory controller가 요구하는 interface/state 조합과 hardware export가 다릅니다[12].
  • vendor safety scaling 때문에 wall-clock progress와 trajectory time이 달라집니다[13].
  • planning scene의 state나 geometry가 늦어 이미 낡았습니다[5].
  • Servo의 collision/singularity scaling은 motion을 줄일 수 있지만 certified safety function을 대신하지 않습니다[6].

그러므로 “plan succeeded”를 “robot safely completed”로 기록하지 않습니다. planned, accepted, executing, tracked, task_succeeded, stopped를 별도 상태로 둡니다.

1.4 주파수 하나 대신 timing contract를 쓴다

Command path는 generic frequency 하나가 아니라 loop owner, update-rate의 출처, event time과 arrival time, deadline, failure action을 기록해야 합니다[8,11,16]. 이 공식 문서들은 configured rate와 diagnostics를 제공하지만, cross-platform hard-real-time guarantee를 제공하는 것은 아닙니다. 실제 worst-case latency와 jitter는 선택한 hardware와 부하에서 측정해야 합니다.

1.4.1 최소 timing matrix

아래 값은 숫자 기본값이 아니라 채워야 할 필드입니다. TBD를 hardware motion 전에 없애는 것이 목표입니다.

Path / loop Owner Rate source Event clock Arrival clock Deadline / max age Watchdog and failure action
camera → observation sensor driver device/config sensor timestamp host steady clock TBD by motion speed mark stale; do not infer new action
observation → policy policy client/server model config synchronized sample time inference host clock TBD by horizon discard stale proposal; keep safe hold/fallback
skill → planner task executive event-driven task-state version planner clock state-version bound cancel/replan on scene mismatch
planner → trajectory controller MoveIt/executor action contract trajectory start time controller clock acceptance timeout reject/hold; expose action result
streaming reference → controller servo/reference process controller config reference time control host clock per-controller TBD stop stream; switch to tested hold
controller read-update-write controller manager or vendor process configured/measured steady/robot clock same-domain preferred measured overrun bound deactivate/fallback only if pretested
safety monitor → stop path independent safety owner risk assessment/manual device/safety clock hardware path cell-specific protective stop/E-stop; controlled reset

ROS 2 topic statistics는 transport observation에 유용하지만 motor deadline의 증명은 아닙니다[8]. Simulator에서도 publish rate는 rendering/GPU load와 simulation clock 설정에 영향을 받을 수 있으므로, topic이 보인다는 사실만으로 timestamp correctness나 deterministic delivery를 추론하지 않습니다[16]. lifecycle state 또한 startup/shutdown 순서를 조직하지만 안전한 상태 전이를 인증하지는 않습니다[9].

1.4.2 clock을 세 종류로 분리한다

  1. Event time: sensor exposure나 robot state가 실제로 측정된 시각입니다.
  2. Arrival time: message가 consumer에 도착한 시각입니다.
  3. Decision/execution time: policy가 observation을 사용한 시각과 command가 유효한 실행 구간입니다.

arrival - event는 age의 일부이고, inference·queue·network·controller buffering이 추가됩니다. wall clock이 조정될 수 있다면 latency 측정에는 monotonic/steady clock을 사용하고, sensor 또는 robot clock과 host clock 사이의 offset·drift·uncertainty를 함께 저장합니다. clock domain을 바꿀 때는 변환 ID와 calibration epoch를 남깁니다.

그림 1.2. Event·arrival·execution time과 deadline·max age를 분리하고, 오래된 packet 폐기와 watchdog의 hold·fallback·abort를 별도 경로로 기록하는 timing contract. — 저자 제작(OpenAI image generation 보조)

1.5 고전적 모델과 학습 모델은 어느 층에 들어가는가

Capuano et al.의 explicit-model 대 implicit/learning-based motion-generation 구분은 robot learning을 처음 배치하는 데 유용한 지도입니다[18]. 그러나 이 taxonomy는 저자들의 tutorial organization에 대한 primary evidence일 뿐이고, 이 장의 hierarchy는 별도의 S12 synthesis입니다. explicit/implicit 구분이 task selection, motion generation, low-level control, safety authority의 차이를 없애지는 않습니다. operational-space control 같은 고전적 기초[2]와 language-conditioned 상위 program proposal 같은 접근[19]도 실제 실행에서는 서로 다른 interface를 필요로 합니다.

문제 조건 첫 insertion point 왜 여기서 시작하는가 계속 남는 아래층
fixture와 pose가 알려진 반복 transport classical planner + timed trajectory geometry와 제약을 직접 검증 가능 trajectory controller, limits, watchdog
object/scene variation이 skill 선택을 어렵게 함 perception-conditioned skill/BC/ACT 규칙 유지가 data coverage보다 비싸지는 구간 planner/IK 또는 constraint projection, controller
demonstration이 여러 타당한 motion mode를 가짐 diffusion/flow action proposal 평균 action이 부적절할 수 있는 구간 receding-horizon gate, age check, fallback
reward로 residual 개선을 측정할 수 있음 bounded residual/RL branch 검증된 nominal behavior를 보존 가능 nominal controller, projection, stop authority
open-vocabulary instruction과 장기 reasoning #S13의 VLA/world-model/agent layer 상위 task/skill interface 문제 S12의 motion/control/safety stack 전체

고전적 기반을 먼저 둔다는 것은 학습을 배제한다는 뜻이 아닙니다. 실패를 localization할 수 있는 baseline을 만든다는 뜻입니다. planner가 실패했는지, policy proposal이 stale했는지, controller가 trajectory를 거부했는지, contact gate가 멈췄는지 구분할 수 있어야 새 모델의 실제 이득도 측정할 수 있습니다.

1.6 독립된 safety/fallback authority

이 책은 safety supervisor, hardware limits, collision/force gate, watchdog authority를 learned policy proposal과 분리하는 것을 설계 규칙으로 둡니다. 이는 아직 모든 cell에 그대로 적용할 수 있는 인증 주장이 아닙니다. 현재 claim packet에는 보편적 hardware prose를 확정할 applicable standard와 selected-platform manual evidence가 충분하지 않으므로, 실제 장비에서는 risk assessment, 적용 표준, vendor safety manual, validated stop path로 다시 확정해야 합니다[11,17,18].

software limit clamp, planning collision check, model confidence는 각각 유용하지만 certified safety function과 동의어가 아닙니다. controller manager의 fallback도 available interface와 사전 검증에 의존합니다[11]. 따라서 supervisor의 최소 계약은 다음처럼 성능 경로와 분리합니다.

  • policy가 없어도 hold/stop path가 동작합니다.
  • policy process를 kill하거나 network를 끊어 watchdog을 시험합니다.
  • stale, NaN, out-of-range, wrong-frame, wrong-version action을 거부합니다.
  • collision/force/workspace event와 reset 권한을 별도 log에 남깁니다.
  • fallback 전환과 recovery는 simulation 또는 mock만이 아니라 해당 hardware mode에서 제한적으로 검증합니다.
  • E-stop과 protective stop의 해제·재가동 절차는 사람 소유이며 학습 모델이 자동 승인하지 않습니다.

1.7 Worked interface example: tabletop insertion 한 번 추적하기

다음은 수치 성능 예제가 아니라 interface audit 예제입니다. 대상은 6/7-DoF arm, parallel gripper, wrist/scene camera를 쓰는 tabletop assembly입니다.

Step 1 — Task request

FSM이 insert(part=A, fixture=B, task_state=v37)을 발행합니다. precondition은 object pose freshness, gripper state, workspace clear, controller active입니다. 여기에는 motor command가 없습니다.

Step 2 — Skill proposal

고전적 primitive 또는 learned policy가 approach → grasp → transport → contact_search → insert의 skill sequence와 각 skill의 action schema version을 냅니다. learned chunk라면 observation event time, policy/checkpoint ID, inference completion time, horizon과 valid-until을 함께 보냅니다.

Step 3 — Motion generation

free-space 구간은 collision-aware planner가 geometric path를 만들고 trajectory processing이 timing을 붙입니다. 공식 MoveIt 문서가 설명하듯 jerk bound나 vendor acceptance는 별도 확인 대상입니다[7]. contact 구간에서는 Chapter 3에서 검증할 constrained reference와 impedance/force mode로 전환합니다.

Step 4 — Controller acceptance

trajectory action은 acceptance/result/tolerance를 제공하는 interface로 제출합니다[12]. controller가 reject하면 policy가 직접 더 강한 command를 보내지 않습니다. mode, interface, start state, timing을 진단하고 task executive가 replan 또는 abort를 선택합니다.

Step 5 — Execution and monitoring

controller owner는 tracking loop를 유지하고, safety owner는 limit·collision/force·watchdog event를 감시합니다. task layer는 progress를 관찰하지만 motor loop를 대신하지 않습니다. contact force threshold나 stop category의 실제 값은 이 장에서 만들어내지 않고 cell의 검증된 configuration을 참조합니다.

Step 6 — Completion or failure

성공은 단일 done=true가 아닙니다. trajectory_result, final pose tolerance, insertion/contact criterion, gripper/object state, safety event 없음, observation freshness가 함께 기록됩니다. 실패 시 raw/mapped/sent action과 controller/safety state를 보존해 Chapter 4의 dataset schema와 Chapter 9의 promotion evidence로 넘깁니다.

1.8 최소 재현 workflow와 validation gate

Gate 0 — S11 인수 확인

앞 권 Chapter 8의 packet/loop contract와 Chapter 9의 asset–calibration–controller tuple을 복사하지 말고 현재 cell에서 재확인합니다. joint limits, collision model, E-stop/watchdog, frame/time synchronization, command mode의 owner가 문서화되지 않았다면 여기서 멈춥니다. #S11은 아직 release-ready가 아니므로 공개 링크가 아니라 continuity input으로만 취급합니다.

Gate 1 — Read-only graph

robot을 움직이지 않고 node/process, topic/action/service, controller, hardware interface, clock domain을 도식화합니다. 각 edge에 schema/version과 owner를 붙입니다. 장치가 연결되지 않아도 configuration lint와 mock interface로 구조를 확인할 수 있습니다.

Gate 2 — Recorded-state replay

기록된 observation을 policy/planner에 replay하되 actuator command는 차단합니다. stale timestamp, frame mismatch, dropped message, duplicated/reordered action을 주입합니다. 기대 결과는 unsafe proposal의 거부와 이유가 있는 log입니다.

Gate 3 — Simulation/shadow

같은 task/action/controller contract로 simulation regression을 수행합니다. 이어 실제 sensor/state를 읽되 command를 보내지 않는 shadow mode에서 age, jitter, compute time, constraint-rejection rate를 측정합니다. simulator topic rate를 실제 hardware deadline으로 대신 사용하지 않습니다[16].

Gate 4 — Bounded hardware trial

검증된 저속·작은 workspace·supervised 조건과 cell-specific safety configuration에서만 진행합니다. network loss, policy timeout, controller reject, safety event에 대한 failure action이 먼저 테스트되어야 합니다. 이 gate는 success rate를 높이는 실험이 아니라 authority boundary가 지켜지는지 확인하는 실험입니다.

1.9 실패 증상과 진단 순서

증상 먼저 볼 층 진단 순서 금지할 성급한 수정
plan은 성공했는데 robot이 안 움직임 execution/controller action result → controller active/interface → timing/start state → vendor program/mode policy gain 또는 speed부터 올리기
가끔 오래된 방향으로 움직임 time/policy queue event/arrival/decision time → age gate → reorder/drop → chunk version 평균 latency만 보고 허용치 늘리기
simulation은 안정적, hardware는 jitter controller/interface clock domain → update overrun → CPU scheduling → transport → vendor loop simulator rate를 hardware rate로 가정하기
목표 근처에서 멈춤 motion/safety singularity/collision scaling → joint limit → force/workspace gate → controller tolerance safety gate를 disable하기
timeout 뒤 command가 재개됨 watchdog/recovery timeout owner → queue flush → lifecycle/reconnect → sequence ID 이전 chunk를 그대로 이어 실행하기
task success와 controller success가 충돌 task/evaluation postcondition sensor → trajectory result → object state → safety log 하나의 done flag로 덮기

진단의 원칙은 위층에서 새 action을 더 만들기 전에 아래층의 거부 이유를 읽는 것입니다. 특히 MoveIt Servo의 scaling이나 controller holding behavior는 안전 인증과 같지 않고 hardware implementation에 의존합니다[6,12].

그림 1.3. 한 번의 삽입 시도에서 정상 실행과 stale proposal 폐기, controller reject, safety hold·stop·reset 권한을 owner별로 분리한 sequence. — 저자 제작(Codex 보조)

1.10 Codex용 bounded implementation prompt

아래 프롬프트는 robot을 움직이는 코드가 아니라 실행 계약과 검증기를 만드는 작업으로 범위를 닫습니다.


Goal
- 이 저장소의 tabletop assembly command path에 대해 owner/rate/clock/deadline/
  watchdog/failure-action matrix와 read-only validator를 구현한다.

Context
- Robot: <model/firmware>, controller: <name/version>, ROS 2: <distro>,
  MoveIt/ros2_control/vendor driver: <pinned versions>.
- Inputs: current launch/config files, interface list, recorded rosbag, vendor manuals.
- No hardware motion is authorized in this task.

Constraints
- Task, policy, motion generation, low-level control, real-time interface,
  robot, independent safety owner를 분리한다.
- event/arrival/decision clock과 clock-domain conversion을 기록한다.
- rate를 추측하지 말고 config source와 measured diagnostic을 구분한다.
- stale/NaN/out-of-range/wrong-frame/wrong-version action을 reject한다.
- existing E-stop, protective-stop, limit, watchdog path를 수정하거나 우회하지 않는다.

Done when
- versioned YAML/JSON contract와 schema test가 있다.
- graph의 모든 command/state edge에 owner, schema, clock, deadline, failure action이 있다.
- recorded-state replay에서 stale, drop, reorder, timeout 주입 test가 모두 pass한다.
- report가 unknown/TBD 필드를 fail-closed로 표시한다.
- diff와 재현 명령, residual risks를 남긴다.

Safety
- actuator write path는 mock 또는 disabled adapter로 고정한다.
- hardware trial, controller switching, gain/limit 변경은 별도 승인 작업이다.
- LLM/policy는 torque, safety reset, E-stop 해제 권한을 갖지 않는다.

1.11 남겨야 할 artifact와 metric

필수 artifact

  • execution hierarchy diagram과 process/node inventory
  • command/state interface schema 및 version
  • owner/rate/clock/deadline/watchdog/failure matrix
  • controller mode와 hardware interface compatibility table
  • policy/checkpoint, robot model, calibration epoch, task-state version manifest
  • stale/drop/reorder/timeout fault-injection log
  • simulation, replay, shadow, bounded-hardware promotion record
  • safety event와 human reset을 분리한 audit log

최소 metric

  • sensor-to-decision age와 distribution
  • inference, planning, transport, controller acceptance latency를 분리한 값
  • loop overrun/missed-deadline count
  • stale/reordered/dropped proposal count
  • constraint projection/rejection과 fallback count
  • controller reject/abort와 tracking-error event
  • collision/force/watchdog/protective-stop event
  • task success, recovery, human intervention을 각각 기록한 값

평균 하나만 남기지 않습니다. 적어도 tail behavior, 실패 시각, task/scene/policy/controller version을 함께 보존해야 재현과 비교가 가능합니다.

1.12 다음 장과 다음 권의 경계

VLA(vision-language-action model), world model, agentic policy의 model-family·pretraining·grounding·cross-embodiment·benchmark 비교는 #S13의 범위입니다. 이 문장은 model performance claim이 아니라 편집 경계입니다. #S12에서는 이들이 상위 task/skill proposer로 들어올 때 지켜야 할 bounded skill/action interface만 정의합니다[18]. Open X-Embodiment나 Octo 같은 generalist-policy 연구는 #S13의 source map이지만, 이 장에서 결과 수치나 보편적 능력을 주장하지 않습니다.

Chapter 2는 이제 이 공통 지도에서 구조화된 free-space motion의 기본값인 FK/IK, collision-aware planning, path와 trajectory의 차이, time parameterization을 다룹니다. Chapter 3은 그 trajectory가 contact에 들어갈 때 필요한 impedance/admittance/force control을 맡습니다. 이후 학습 정책이 바뀌어도 이 장에서 만든 owner, time, deadline, watchdog, fallback 계약은 그대로 남습니다.

참고문헌

  1. Whitney, D. E. (1969). Resolved Motion Rate Control of Manipulators and Human Prostheses. IEEE Transactions on Man-Machine Systems. https://doi.org/10.1109/TMMS.1969.299896
  2. Khatib, O. (1987). A Unified Approach for Motion and Force Control of Robot Manipulators: The Operational Space Formulation. IEEE Journal on Robotics and Automation. https://doi.org/10.1109/JRA.1987.1087068
  3. Bruyninckx, H. (2001). Open Robot Control Software: The OROCOS Project. Proceedings of IEEE ICRA 2001. DOI: 10.1109/ROBOT.2001.933002.
  4. Chitta, S., Marder-Eppstein, E., Meeussen, W., Pradeep, V., Rodriguez Tsouroukdissian, A., Bohren, J., Coleman, D., Magyar, B., Raiola, G., Lüdtke, M., & Fernández Perdomo, E. (2017). ros_control: A generic and simple control framework for ROS. Journal of Open Source Software. https://doi.org/10.21105/joss.00456
  5. MoveIt / PickNik. (2025). MoveIt 2 move_group Architecture. https://moveit.picknik.ai/main/doc/concepts/move_group.html
  6. MoveIt / PickNik. (2025). MoveIt Servo Realtime Teleoperation Tutorial. https://moveit.picknik.ai/main/doc/examples/realtime_servo/realtime_servo_tutorial.html
  7. MoveIt / PickNik. (2025). MoveIt 2 Trajectory Processing. https://moveit.picknik.ai/main/doc/concepts/trajectory_processing.html
  8. Open Robotics. (2026). ROS 2 Jazzy Interfaces: Topics, Services, and Actions. https://docs.ros.org/en/jazzy/How-To-Guides/Topics-Services-Actions.html
  9. Open Robotics. (2026). ROS 2 Jazzy Managed Node Lifecycle. https://docs.ros.org/en/jazzy/p/lifecycle/index.html
  10. ros-controls. (2026). ros2_control Jazzy Architecture and Getting Started. https://control.ros.org/jazzy/doc/getting_started/getting_started.html
  11. ros-controls. (2026). ros2_control Controller Manager Monitoring and Limits. https://control.ros.org/master/doc/ros2_control/controller_manager/doc/userdoc.html
  12. ros-controls. (2026). ros2_control Joint Trajectory Controller Jazzy. https://control.ros.org/jazzy/doc/ros2_controllers/joint_trajectory_controller/doc/userdoc.html
  13. Universal Robots. (2026). UR ROS 2 Controllers and Speed Scaling. https://docs.universal-robots.com/Universal_Robots_ROS_Documentation/doc/ur_robot_driver/ur_controllers/doc/index.html
  14. Universal Robots. (2026). UR ROS 2 Driver Installation and Real-Time Guidance. https://docs.universal-robots.com/Universal_Robots_ROS2_Documentation/doc/ur_robot_driver/ur_robot_driver/doc/installation/installation.html
  15. Franka Robotics. (2026). libfranka Changelog and Packaging through 0.20.x. https://github.com/frankarobotics/libfranka/blob/main/CHANGELOG.md
  16. NVIDIA. (2026). Isaac Sim ROS 2 FAQ: Time and Topic Visibility. https://docs.isaacsim.omniverse.nvidia.com/latest/ros2_tutorials/ros2_faq.html
  17. Lasota, P. A., Fong, T., & Shah, J. A. (2017). A Survey of Methods for Safe Human-Robot Interaction. Foundations and Trends in Robotics. https://doi.org/10.1561/2300000052
  18. Capuano, F., Pascal, C., Zouitine, A., Wolf, T., & Aractingi, M. (2025). Robot Learning: A Tutorial. arXiv:2510.12403v1. https://doi.org/10.48550/arXiv.2510.12403
  19. Liang, J., Huang, W., Xia, F., Xu, P., Hausman, K., Ichter, B., Florence, P., & Zeng, A. (2023). Code as Policies: Language Model Programs for Embodied Control. IEEE ICRA. arXiv:2209.07753.
  20. Herman Bruyninckx (2001). The OROCOS project: Flexible toolchain for robot control. Annotated primary reading. DOI: 10.1109/robot.2001.932879. — 역할: 실행 계층·통신·시간 책임을 구분하는 1차 읽기. 한계: The assumptions and evaluation setup are source-specific; current implementation claims require maintained official evidence.
  21. Sami Haddadin et al. (2012). Human-Robot Collision Evaluation and Analysis. Annotated primary reading. DOI: 10.1007/978-3-642-40308-8. — 역할: 실행 계층·통신·시간 책임을 구분하는 1차 읽기. 한계: Biomechanical thresholds and apparatus do not substitute for applicable standards or application risk assessment.
  22. Yuya Maruyama et al. (2016). The Robot Operating System 2: Design, architecture, and uses in the wild. Annotated primary reading. DOI: 10.1109/SII.2016.7847304. — 역할: 실행 계층·통신·시간 책임을 구분하는 1차 읽기. 한계: Early ROS 2 prototype results predate current executors, RMW implementations, and distributions.
  23. Daniel Casini et al. (2019). Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling. Annotated primary reading. DOI: 10.4230/LIPIcs.ECRTS.2019.6. — 역할: 실행 계층·통신·시간 책임을 구분하는 1차 읽기. 한계: Assumptions about callback execution and scheduler reservations must hold on the deployed kernel and executor.
  24. Ruoxuan Feng et al. (2025). AnyTouch: Learning Unified Static-Dynamic Representation across Multiple Visuo-Tactile Sensors. Annotated primary reading. arXiv:2502.12191. — 역할: 실행 계층·통신·시간 책임을 구분하는 1차 읽기. 한계: Platform, task, dataset, and evaluation assumptions must be checked in the primary paper before transferring a result.
  25. NVIDIA et al. (2025). SPIDER: Scalable Physics-Informed Dexterous Retargeting. Annotated primary reading. arXiv:2511.09484. — 역할: 실행 계층·통신·시간 책임을 구분하는 1차 읽기. 한계: Dynamic feasibility in simulation does not ensure contact fidelity on hardware