ROS 2 실시간 제어는 모든 노드를 빠르게 만드는 작업이 아닙니다. 모터 상태를 읽고 제어식을 계산해 명령을 쓰는 경로만 정해진 주기 안에 끝나도록 보장하고, 카메라 처리·경로 계획·네트워크·로그처럼 실행 시간이 흔들리는 작업은 그 경로 밖으로 분리하는 설계입니다. 핵심 지표는 평균 실행 시간이 아니라 주기 위반 횟수, 최악 지연, 지터와 페이지 폴트입니다.
실시간 제어는 빠른 계산보다 마감시간을 지키는 문제다
실시간 시스템에서 옳은 결과는 계산값과 완료 시각을 함께 만족해야 합니다. 1kHz 루프라면 1ms마다 작업을 시작하는 것만으로 부족하고, 상태 읽기·제어 계산·명령 쓰기가 다음 마감시간 전에 끝나야 합니다. 시작 시각의 흔들림은 지터, 예정 시각보다 늦게 끝난 시간은 지연으로 구분해 기록합니다.
로봇의 모든 기능이 같은 등급의 실시간성을 필요로 하지는 않습니다. 자세 안정화와 전류·토크 제어는 마감시간 위반이 바로 진동이나 낙상으로 이어질 수 있지만, 지도 갱신이나 상태 화면은 한 프레임 늦어져도 제어가 무너지지 않습니다. 이 차이를 시스템 경계로 만드는 것이 실시간 설계의 출발점입니다.
센서 읽기부터 모터 명령까지 한 주기가 도는 순서
상태 읽기에서는 엔코더·전류·IMU 값을 하드웨어 인터페이스에서 고정된 시각에 가져옵니다. 시간 정렬에서는 각 상태가 어느 제어 주기에 속하는지 타임스탬프와 시퀀스로 확인합니다. 제어 계산에서는 위치·속도·토크 오차와 제한값을 이용해 이번 주기의 명령을 계산합니다.
안전 제한에서는 포화·속도·토크·통신 타임아웃 조건을 적용해 위험한 명령을 차단합니다. 명령 쓰기에서는 버스와 드라이버로 값을 전송하고 완료 시각과 오류 상태를 기록합니다.
온보드 컴퓨터에서 실시간 영역을 따로 두는 이유
온보드 컴퓨터에는 카메라 드라이버, DDS 통신, 추론, 저장장치 쓰기와 제어기가 함께 돌아가는 경우가 많습니다. 카메라 프레임 복사나 로그 파일 회전이 메모리 할당과 디스크 접근을 일으키면 관절 루프가 잠깐 밀릴 수 있습니다. 그래서 실시간 스레드는 CPU 코어·우선순위·메모리 경로를 따로 관리하고 다른 노드와는 고정 크기 버퍼로 데이터를 교환합니다.
실시간 영역을 별도 MCU나 모터 드라이버에 두는 구조도 흔합니다. 이 경우 ROS 2 컴퓨터는 목표 위치나 궤적을 낮은 빈도로 보내고, 하위 제어기는 엔코더와 전류를 훨씬 높은 주기로 닫습니다. 통신이 잠깐 끊겨도 마지막 명령을 무한히 유지하지 않도록 워치독과 정지 상태를 함께 정의해야 합니다.
제어 루프 안에서 피해야 할 비결정적 작업
동적 메모리 금지에서는 실행 중 할당·해제가 페이지 폴트와 잠금 경합을 만들 수 있어 초기화 단계에서 버퍼를 확보합니다. 블로킹 호출 금지에서는 파일·네트워크·콘솔 출력처럼 완료 시간을 제한하기 어려운 호출을 제어 스레드 밖으로 옮깁니다.
우선순위 역전 방지에서는 낮은 우선순위 스레드가 가진 잠금을 제어 스레드가 기다리지 않도록 공유 상태를 최소화합니다. 유한한 오류 처리에서는 오류가 나도 무한 재시도하지 않고 정해진 횟수 안에 안전 상태로 전환합니다.
소프트·펌·하드 실시간은 실패를 허용하는 정도가 다르다
실시간 등급은 운영체제 이름이 아니라 마감시간 위반을 어떻게 다루는지로 구분합니다. 같은 ROS 2 구성도 제어 대상과 안전 요구에 따라 필요한 등급이 달라집니다.
대부분의 고성능 로봇은 계층을 섞어 씁니다. 전류 루프는 드라이버나 MCU에서 더 엄격하게, 관절 토크·임피던스 루프는 실시간 Linux에서, 경로 계획과 UI는 일반 프로세스에서 처리합니다.
| 구분 | 마감시간 위반 | 적합한 작업 | 설계 초점 |
|---|---|---|---|
| 비실시간 | 상한을 보장하지 않음 | 시각화·기록·오프라인 계산 | 처리량과 편의성 |
| 소프트 실시간 | 가끔 허용하되 품질 저하 | 영상·지도·상위 계획 | 백분위 지연 |
| 펌 실시간 | 늦은 결과를 폐기 | 센서 프레임·명령 갱신 | 타임아웃과 최신값 |
| 하드 실시간 | 위반 자체가 시스템 실패 | 전류·토크·안전 정지 | 최악 실행 시간 |
주기와 지터를 같은 단위로 측정해야 한다
제어 주파수만 기록하면 원인을 찾기 어렵습니다. 예정 시각, 실제 시작 시각, 실행 시간, 완료 시각을 같은 단조 증가 시계로 남겨야 지터와 연산 초과를 분리할 수 있습니다.
평균과 표준편차 외에 최대값과 높은 백분위를 반드시 봐야 합니다. 정상 상태뿐 아니라 카메라 시작, 네트워크 폭주, 로그 저장, 열 스로틀링처럼 실제 운용 중 나타나는 부하를 넣어야 합니다.
| 지표 | 계산 기준 | 확인할 현상 | 판정 예 |
|---|---|---|---|
| 주기 | 연속 시작 시각의 차이 | 루프 속도 유지 | 목표 1ms 주변 분포 |
| 시작 지터 | 실제 시작-예정 시작 | 스케줄러 간섭 | 최대값이 예산 이내 |
| 실행 시간 | 완료-실제 시작 | 제어 계산 과부하 | 주기의 일부만 사용 |
| 마감 위반 | 완료가 다음 예정 시각 초과 | 제어 불연속 | 시험 동안 0회 등 |
ROS 2 제어 경계를 설계하는 실제 순서
루프 예산 배분에서는 상태 읽기·계산·명령 쓰기·여유 시간을 마이크로초 단위로 나눕니다. 실시간 경로 표시에서는 콜백과 함수 중 메모리·잠금·I/O를 쓰는 부분을 호출 그래프로 표시합니다. 스레드와 코어 분리에서는 제어 스레드 우선순위와 CPU affinity를 정하고 IRQ 간섭도 함께 확인합니다.
버퍼 경계 구현에서는 비실시간 노드와는 고정 크기 최신값 버퍼나 실시간 안전 핸들로 교환합니다. 최악 부하 시험에서는 카메라·추론·저장·통신을 동시에 켠 상태에서 장시간 지연 분포를 수집합니다.
평균 지연이 짧아도 현장에서 진동하는 이유
평균값만 보고 통과에서는 평균 100µs여도 드물게 2ms가 나오면 1kHz 관절 루프는 실패합니다. 제어 콜백에서 로깅에서는 콘솔과 파일 출력이 잠금과 I/O를 일으켜 간헐 지터를 만듭니다. 새 메시지마다 할당에서는 큰 메시지 복사와 동적 할당이 페이지 폴트와 캐시 교란을 만듭니다.
상위 명령을 무기한 유지에서는 통신이 끊겼을 때 마지막 속도 명령이 계속 적용될 수 있습니다. 커널 변경만 시행에서는 드라이버 IRQ·CPU 주파수·응용 코드가 그대로면 최악 지연은 남습니다.
부하를 건 상태에서 최악 지연을 검증하는 방법
유휴 기준선에서는 다른 노드를 끈 상태에서 루프 자체의 지터와 실행 시간을 먼저 측정합니다. CPU·메모리 부하에서는 연산과 메모리 대역폭을 점유한 상태에서 마감 위반이 생기는지 봅니다. I/O 동시 실행에서는 카메라, 네트워크, 디스크 기록을 동시에 실행해 공유 자원 간섭을 확인합니다.
열 안정 상태에서는 충분히 가열해 CPU·GPU 클록이 바뀐 뒤에도 같은 분포가 유지되는지 봅니다. 통신 단절에서는 목표 명령이 끊겼을 때 제한 시간 안에 감속·정지하고 복구 절차를 지키는지 봅니다.
ros2_control과 하드웨어 인터페이스를 연결하는 구조
ros2_control에서는 Controller Manager가 하드웨어 인터페이스의 read, update, write 순서를 반복합니다. 이 루프 밖의 ROS 2 콜백이 목표값을 갱신하더라도 제어 스레드가 안전하게 읽을 수 있는 교환 구조가 필요합니다. 실제 모터 버스 주기와 Controller Manager 주기가 다르면 최신 상태와 명령이 어느 시점의 값인지도 명시해야 합니다.
도식은 인지·계획 노드, 실시간 안전 버퍼, 관절 제어기, 하드웨어 인터페이스, 모터 드라이버를 분리해 보여줍니다. 이 경계가 명확하면 지연이 발생했을 때 네트워크 문제인지 제어 연산 문제인지 추적할 수 있고, 상위 노드를 재시작해도 하위 안전 정지는 유지할 수 있습니다.
실시간 커널만 설치하면 끝나는 것은 아니다
PREEMPT_RT 커널과 높은 스레드 우선순위는 필요한 수단일 수 있지만 그 자체가 보증은 아닙니다. 하드웨어 드라이버, BIOS 전원 관리, IRQ 배치, 메모리 할당과 응용 코드까지 같은 시험 조건에서 확인해야 합니다.
안전 기능을 일반 ROS 2 노드 하나에만 맡겨서는 안 됩니다. 위험도 분석에 따라 독립 안전 회로, 안전 PLC, 드라이브의 STO 같은 별도 수단이 필요할 수 있으며, 본문의 실시간 구조는 인증된 안전 설계를 대신하지 않습니다.
제어·통신·관절 시험 글과 함께 읽을 자료
이 주제를 더 넓게 이해하려면 EtherCAT와 CAN-FD 차이, 로봇 관절 게인 튜닝, 로봇 모터 드라이버 구조를 함께 읽는 편이 좋습니다. 각 글은 부품, 제어, 데이터 계층을 서로 다른 질문으로 나누어 설명합니다.
본문의 기술 범위는 다음 1차 자료를 기준으로 확인했습니다. ROS 2 실시간 프로그래밍 문서은 마감시간·페이지 폴트·동적 메모리 회피 원칙을 설명합니다. ros2_control Controller Manager 문서은 제어 루프와 하드웨어 인터페이스의 실행 구조를 제공합니다. ROS 2 tracing 튜토리얼은 콜백과 실행 지연을 추적하는 공식 절차를 제공합니다. 수치와 적용 범위는 각 자료의 시험 조건을 벗어나 일반화하지 않았습니다.
ROS 2 실시간 제어에서 자주 묻는 질문
ROS 2는 기본적으로 실시간 운영체제인가요?
아닙니다. ROS 2는 실시간 설계를 지원하는 통신과 실행 구조를 제공하지만, 커널·스케줄링·메모리·드라이버·응용 코드를 함께 구성하고 측정해야 합니다.
DDS를 쓰면 관절 제어도 바로 실시간이 되나요?
DDS의 QoS는 전달 방식을 조정하지만 최악 지연을 자동 보장하지 않습니다. 고주기 내부 루프는 프로세스 내 버퍼나 하위 제어기로 닫는 경우가 많습니다.
제어 주파수는 높을수록 좋은가요?
연산과 통신이 마감시간을 안정적으로 지킬 때만 유효합니다. 무리하게 주파수를 높여 위반이 늘면 낮고 안정적인 주기보다 결과가 나빠질 수 있습니다.
Python 노드로 실시간 제어를 해도 되나요?
상위 목표 생성과 시험에는 쓸 수 있지만, 가비지 컬렉션과 런타임 지연을 엄격히 제한하기 어렵습니다. 위험한 고주기 루프는 보통 C/C++ 또는 전용 제어기로 분리합니다.
무엇을 먼저 측정해야 하나요?
예정 시작, 실제 시작, 완료 시각을 단조 증가 시계로 기록하고 최대 지터·최대 실행 시간·마감 위반 수를 유휴와 최악 부하에서 비교하는 것이 출발점입니다.
마지막 확인: 2026년 7월 25일. 본문은 공개된 기술 문서와 논문을 기준으로 작성했으며, 제품별 수치와 안전 등급은 제조사 자료와 실제 시험 조건을 함께 확인해야 합니다.