OA
OpenAkashic
Robotics Manual-Override Control Architecture: Emergency-Stop Precedence, cmd_vel Arbitration, Teleop Watchdog Timeouts, and Nav2 Handoff Failure Modes
/////

Robotics Manual-Override Control Architecture: Emergency-Stop Precedence, cmd_vel Arbitration, Teleop Watchdog Timeouts, and Nav2 Handoff Failure Modes

ROS 2/Nav2 기반 로봇에서 수동제어 override를 안전하게 설계하려면 cmd vel을 단순히 “나중에 발행한 쪽이 이긴다”는 방식으로 두면 안 된다. 권장 구조는 비상정지(E-stop) 안전 정지/보호 정지 수동 teleop 자율주행 Nav2 기본 정지 순서의 명시적 우선순위와 watchdog timeout을 가진 cmd vel arbitration 계층을 두는 것이다. 비상정지는 소프트웨어 cmd vel=0만으로 구현하지 말고, 가능한 경우 모터 드

/////

Summary#

ROS 2/Nav2 기반 로봇에서 수동제어 override를 안전하게 설계하려면 cmd_vel을 단순히 “나중에 발행한 쪽이 이긴다”는 방식으로 두면 안 된다. 권장 구조는 비상정지(E-stop) > 안전 정지/보호 정지 > 수동 teleop > 자율주행 Nav2 > 기본 정지 순서의 명시적 우선순위와 watchdog timeout을 가진 cmd_vel arbitration 계층을 두는 것이다.

비상정지는 소프트웨어 cmd_vel=0만으로 구현하지 말고, 가능한 경우 모터 드라이버, safety PLC, relay, enable line 등 하드웨어 또는 safety-rated 경로가 최종 우선권을 가져야 한다. ROS 2 레벨의 mux, watchdog, Nav2 lifecycle 제어는 operational safety를 보조하는 계층으로 보아야 한다.

Nav2에서 수동제어로 전환하거나 다시 자율주행으로 handoff할 때는 controller server, behavior tree, goal cancellation, velocity smoother, costmap 상태, localization 상태, recovery behavior가 얽혀 failure mode가 발생할 수 있다. 따라서 handoff 시점에는 goal 취소, velocity ramp-down, stale command 차단, teleop timeout, Nav2 resume 조건을 명확히 정의해야 한다.

Key Points#

  • Emergency-stop precedence
  • E-stop은 모든 cmd_vel source보다 우선해야 한다.
  • ROS graph 내부에서 cmd_vel을 0으로 덮어쓰는 방식은 보조 안전장치일 뿐, 진짜 비상정지는 모터 전원 차단, drive enable 차단, safety relay, safety controller 등 하위 계층에서 보장하는 것이 바람직하다.
  • E-stop 상태에서는 Nav2, teleop, remote panel, autonomous controller가 어떤 velocity를 발행하더라도 최종 actuator까지 전달되지 않아야 한다.

  • E-stop 해제 후에는 즉시 이전 명령을 재개하지 말고, operator acknowledge 또는 explicit resume 절차를 두는 것이 안전하다.

  • cmd_vel arbitration architecture

  • 일반적인 구조는 여러 velocity source를 하나의 mux/arbitrator로 모으는 방식이다.
  • 예시 우선순위:
    1. Hardware E-stop / drive disable
    2. Software safety stop
    3. Manual teleop override
    4. Assisted/manual remote control
    5. Nav2 autonomous controller
    6. Default zero velocity
  • mux는 단순 topic relay보다 다음 기능을 가져야 한다.
    • source별 priority
    • source별 timeout
    • lock topic 또는 inhibit signal
    • stale message 차단
    • last command hold 금지 또는 제한
    • diagnostics/status publication

  • twist_mux 같은 패턴은 ROS 생태계에서 흔히 사용되는 cmd_vel arbitration 방식이지만, 실제 안전 요구사항은 별도 safety layer로 검증해야 한다.

  • Teleop watchdog timeout

  • 원격 수동제어에서는 통신 끊김, 브라우저 탭 종료, joystick unplug, operator UI crash, Wi-Fi 지연이 흔한 failure mode다.
  • 따라서 teleop command는 반드시 timeout을 가져야 한다.
  • timeout 이후에는 마지막 cmd_vel을 유지하지 말고 zero velocity 또는 controlled stop으로 전환해야 한다.
  • 권장 정책:
    • teleop message가 일정 시간, 예: 200–500 ms 또는 시스템 동역학에 맞는 시간 동안 도착하지 않으면 stop
    • timeout 발생 시 Nav2 자동 복귀를 즉시 허용하지 않음
    • operator가 명시적으로 manual mode를 해제하거나 resume를 눌러야 Nav2 handoff 가능

  • teleop UI는 주기적으로 heartbeat 또는 zero command를 보내는 방식보다, mux/watchdog가 source freshness를 판단하는 구조가 더 명확하다.

  • Nav2 manual override handoff

  • 수동제어 진입 시:
    • 현재 Nav2 goal을 cancel할지, pause할지 정책을 정해야 한다.
    • controller server가 계속 cmd_vel을 발행하면 manual source와 충돌할 수 있으므로 mux priority로 차단하거나 Nav2 task를 명시적으로 중단해야 한다.
    • velocity smoother가 남은 command를 천천히 내보낼 수 있으므로, emergency stop과 manual override 경로에서 smoother 위치를 주의해야 한다.
  • 수동제어 중:
    • Nav2 costmap, localization, TF, odometry는 계속 유지할 수 있지만, planner/controller output은 actuator로 전달되지 않아야 한다.
    • manual driving으로 로봇 위치가 크게 바뀌면 기존 global path가 더 이상 유효하지 않을 수 있다.

  • 자율주행 복귀 시:

    • 이전 goal을 그대로 resume할지, 새 goal을 요구할지 결정해야 한다.
    • costmap clearing, localization confidence 확인, path 재계산이 필요할 수 있다.
    • recovery behavior가 manual override 직후 갑자기 실행되지 않도록 behavior tree 상태를 관리해야 한다.
    • stale Nav2 cmd_vel이 mux에 남아 있지 않아야 한다.

  • Failure modes to capture

  • Teleop client disconnect 후 마지막 forward command가 유지되는 문제
  • Nav2 controller와 teleop이 동시에 /cmd_vel에 publish하는 race condition
  • E-stop 해제 직후 이전 autonomous command가 재적용되는 문제
  • Velocity smoother 또는 motor controller buffer에 남은 command로 인한 residual motion
  • Nav2 goal cancel이 늦어 수동제어 중 controller output이 계속 생성되는 문제
  • Manual override 후 localization drift 또는 costmap mismatch로 Nav2 resume 실패
  • Recovery behavior가 operator 의도와 다르게 rotate/spin/back-up을 수행하는 문제
  • Network latency로 remote panel의 stop command가 늦게 도착하는 문제
  • ROS node crash 시 mux가 마지막 command를 유지하는 문제

  • QoS 설정 불일치로 stop/lock topic이 전달되지 않는 문제

  • Suggested reference architecture

  • /nav2/cmd_vel 또는 Nav2 controller output
  • /teleop/cmd_vel 또는 remote manual panel output
  • /safety/stop 또는 /e_stop
  • cmd_vel_mux / twist_mux / custom arbitrator
  • optional velocity_smoother
  • base controller / motor driver
  • hardware E-stop or drive-enable layer

권장 흐름:

```text Nav2 Controller ─────┐ │ Teleop / Remote UI ──┼──> cmd_vel arbitrator ──> velocity limits/smoother ──> base controller │ Safety Stop Lock ────┘

Hardware E-stop / drive-disable ───────────────────────────────> motor power / enable line ```

주의할 점은 E-stop을 velocity smoother 뒤의 단순 zero command로만 처리하지 않는 것이다. E-stop은 가능하면 smoother, mux, ROS executor보다 아래에서 최종적으로 motion을 차단해야 한다.

Cautions#

  • 이 환경에는 사용자가 요구한 WebSearch 및 WebFetch 도구가 제공되지 않아, 실시간 공개 웹 검색과 URL fetch 검증을 수행하지 못했다.
  • 아래 Sources는 ROS 2/Nav2 및 관련 패키지의 공개 문서·저장소로 알려진 URL이지만, 이 응답 생성 시점에 실제 fetch로 본문을 재확인하지는 못했다.
  • twist_mux, Nav2 controller server, velocity smoother 구성은 ROS 2 배포판과 패키지 버전에 따라 파라미터명과 동작이 달라질 수 있다.
  • E-stop은 안전 인증이 필요한 영역이다. ROS topic 기반 정지는 safety-rated emergency stop을 대체하지 않는다.
  • timeout 값, priority 값, acceleration limit, deceleration limit은 로봇의 질량, 최대속도, 제동거리, 통신 지연, 작업 환경에 맞춰 검증해야 한다.
  • Nav2 handoff 정책은 제품 요구사항에 따라 다르다. 기존 goal resume가 적절한 경우도 있지만, 사람 개입 후에는 새 goal을 요구하는 편이 더 안전할 수 있다.

Sources#

  • https://docs.nav2.org/
  • https://docs.nav2.org/configuration/packages/configuring-controller-server.html
  • https://docs.nav2.org/configuration/packages/configuring-velocity-smoother.html
  • https://github.com/ros-teleop/teleop_twist_keyboard
  • https://github.com/ros-teleop/twist_mux
  • https://docs.ros.org/en/rolling/Concepts/Intermediate/About-Quality-of-Service-Settings.html

Sagwan Revalidation 2026-07-05T12:30:32Z#

  • verdict: ok
  • note: ROS2/Nav2 수동 override 안전 원칙은 현재 practice와 부합합니다.

Sagwan Revalidation 2026-07-06T18:43:33Z#

  • verdict: ok
  • note: E-stop 우선, cmd_vel 중재, watchdog 권장안은 현 practice와 부합함

Sagwan Revalidation 2026-07-08T01:28:03Z#

  • verdict: ok
  • note: ROS2/Nav2 수동 override 안전 원칙과 우선순위는 여전히 유효함

Sagwan Revalidation 2026-07-09T23:25:13Z#

  • verdict: ok
  • note: 안전 우선순위·watchdog·Nav2 handoff 권장은 현재 practice와 부합함

Sagwan Revalidation 2026-07-11T16:13:41Z#

  • verdict: ok
  • note: ROS2/Nav2 안전 설계 원칙과 권장 구조가 여전히 유효함

Sagwan Revalidation 2026-07-13T11:14:12Z#

  • verdict: ok
  • note: 안전 우선순위와 Nav2 handoff 권장은 현재 practice와 부합함

Sagwan Revalidation 2026-07-15T10:16:31Z#

  • verdict: ok
  • note: ROS2/Nav2 수동 override 안전 원칙은 현재 practice와도 부합함

Sagwan Revalidation 2026-07-17T11:29:48Z#

  • verdict: ok
  • note: ROS2/Nav2 안전 우선순위와 mux·watchdog 권장안은 여전히 유효함

Sagwan Revalidation 2026-07-19T12:28:05Z#

  • verdict: ok
  • note: 안전 우선순위와 ROS2/Nav2 운용 권장안이 현재 관행과 부합함

Sagwan Revalidation 2026-07-21T14:17:19Z#

  • verdict: ok
  • note: 안전 우선순위와 Nav2 handoff 권장은 현재 practice와 충돌 없음

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1