참고자료
ROS2가 프로덕션에서 실패하는 구조적 이유는 다음과 같습니다.
•
DDS 기반 Pub/Sub 구조는 고대역 센서 스트림에서 병목이 발생함
•
QoS 튜닝은 근본 해결책이 아니며 시스템 복잡도만 증가시킴
•
Executor / Callback 모델은 실행 순서와 타이밍이 비결정적임
•
멀티코어 시스템에서도 실제로는 단일 코어만 포화되는 경우가 잦음
•
메모리 할당/해제가 프레임 단위로 발생하여 실시간성 보장 불가
•
장애 발생 시 call stack, ownership, lifetime 추적이 사실상 불가능
데모용 프레임워크와 양산용 프레임워크의 차이는????
•
데모는 평균 성능, 양산은 최악 성능(Worst-case)을 기준으로 판단해야 함
•
“잘 돌아간다”는 지표는 프로덕션 품질과 무관
•
메모리 누수, race condition, frame drop은 데모에서는 감지되지 않음
•
런타임 동적 설정과 자동 magic은 양산에서 디버깅 불가능성을 초래
•
시스템 동작이 코드가 아닌 프레임워크 내부 로직에 의존하게 됨
•
장애 원인을 추적할 수 없는 구조는 양산 전환 불가
ROS2 제거 후 순수 C++ 프레임워크로 전환해야 하는 필요성
•
Thread Pipeline을 명시적으로 설계하여 코어 사용률을 통제 가능
•
메모리 풀 기반 설계로 allocation latency 제거
•
데이터 흐름이 명시적인 파이프라인 구조로 드러남
•
실행 순서, 스레드 소속, 데이터 ownership이 코드 레벨에서 추적 가능
•
성능 문제 발생 시 프로파일링과 재현이 가능해짐
•
“프레임워크를 믿는 개발”에서 “시스템을 이해하는 개발”로 전환
신규 프로덕션 프레임워크가 반드시 갖춰야 할 조건
•
고정 스레드 모델 기반의 명시적 실행 파이프라인
•
Zero-copy 또는 bounded-copy 데이터 전달 구조
•
메모리 풀, 오브젝트 라이프사이클 명확화
•
Error handling을 return code가 아닌 시스템 레벨로 통합
•
빌드/설정/런타임 동작이 모두 정적으로 정의됨
•
CI에서 성능, 메모리, 스레드 규칙을 자동 검증 가능해야 함
ROS2 → 신규 프레임워크 전환 전략
•
전체 시스템을 한 번에 버리지 말고 가장 병목인 파트부터 분리
•
ROS2는 외부 인터페이스/도구용으로만 제한적으로 유지
•
핵심 인지/제어 파이프라인은 순수 C++로 재구성
•
프레임 단위 처리 흐름을 코드로 설명할 수 있어야 함
•
“확장성”보다 “예측 가능성”을 우선 설계 기준으로 삼음
260127_1811 기준, 2부 글을 작성했습니다.
•
이렇게 ros를 깠지만 ㅋㅋ 아직도 필요할때에는 사용하고 있는 유저 입장으로써 약간의 옹호 글? 작성했습니다.
안녕하세요
•
관련 기술 문의와 R&D 공동 연구 사업 관련 문의는 “glory@keti.re.kr”로 연락 부탁드립니다.
Hello
•
For technical and business inquiries, please contact me at “glory@keti.re.kr”
