【로봇-AMR 실무】 산업용 로봇 소비전력, 회생저항, 온도는 어떻게 시험할까? | Power Analyzer 실무
【Safety 기능안전】 EDM이란? Safety Contactor 피드백 접점을 확인하는 이유AMR이나 산업용 로봇의 Safety 회로를 설계하다 보면 EDM이라는 용어를 자주 접하게 된다.특히 Safety Relay나 Safety PLC의 Output으로
terrypack.tistory.com
【통신 실무】 RS-485에 120Ω 종단저항을 사용하는 이유 | 종단저항 위치와 측정 방법
RS-485 PHYSICAL LAYER왜 RS-485 양 끝에 120Ω을 넣는가?CAN과 비슷해 보이지만 Bias와 Transceiver 특성까지 같이 봐야 한다.RS-485 통신이 불안정할 때 가장 먼저 듣는 말 중 하나가 “양 끝에 120Ω을 넣었나요?
terrypack.tistory.com
ROS는 로봇을 움직이는 운영체제라기보다 센서와 알고리즘을 연결하는 Software Framework에 가깝다.
Node, Topic, Service, Action부터 ROS1과 ROS2의 차이, 그리고 실제 AMR에서 ROS와 PLC, MCU, Motor Driver가 어떻게 역할을 나누는지 쉽게 설명한다.
ROS라는 이름 때문에 Windows나 Linux 같은 Operating System으로 생각하기 쉽다. 하지만 실제로는 Linux 위에서 실행되는 Robot Software Framework와 Middleware 생태계에 더 가깝다.
ROS의 가장 큰 장점은 LiDAR Driver, Camera, SLAM, Navigation, Visualization 같은 기능을 모두 한 프로그램에 몰아넣지 않고 여러 Node로 나눈 뒤 표준 Message로 연결할 수 있다는 점이다.
ROS는 Motor Driver 자체가 아니라 Robot의 Sensor Data와 Algorithm, Navigation, Command를 서로 연결하고 재사용하기 쉽게 만드는 Software Framework다.
1. 왜 로봇에 이런 Framework가 필요할까?
AMR 한 대만 봐도 Software 기능이 많다. LiDAR Driver, Camera Driver, IMU, Encoder Odometry, SLAM, Localization, Path Planning, Obstacle Avoidance, UI와 Fleet Interface가 모두 필요할 수 있다.
이 기능을 하나의 거대한 Program으로 만들면 수정과 재사용이 어렵다. ROS는 기능을 Node로 나누고 Message Interface를 통해 연결한다.
2. Node는 무엇인가?
Node는 C언어에서 함수를 실행하듯, 로봇의 기능을 하나씩 나눠 실행하는 프로그램 단위라고 보면 된다.
예를 들어 LiDAR 읽기, Odometry 계산, SLAM, Motor Command 처리를 각각 별도의 Node로 구성할 수 있고, 이 Node들은 Topic이나 Service 같은 ROS Interface를 통해 필요한 데이터를 주고받는다.
3. Topic은 계속 흘러가는 Data Stream에 적합하다
Topic은 Publisher가 Message를 계속 발행하고 Subscriber가 필요한 Data를 받는 Publish/Subscribe 방식이다.
Laser Scan, Camera Image, IMU, Odometry처럼 계속 갱신되는 Data에 잘 맞는다.
4. Service는 요청하고 결과를 받을 때 사용한다
Service는 Request와 Response가 있는 통신이다. "지금 Map을 저장해줘", "현재 Parameter 값을 알려줘"처럼 한 번 요청하고 응답을 기다리는 작업에 적합하다.
| 구분 | Topic | Service |
|---|---|---|
| 통신형태 | Publish / Subscribe | Request / Response |
| 적합한 Data | 연속 Sensor Stream | 단발성 요청 |
| 예 | LiDAR, IMU, Odometry | Reset, Save Map, Query |
5. Action은 시간이 오래 걸리는 작업에 적합하다
ROS2에서 Action은 Goal을 보내고 작업 중 Feedback을 받으며 최종 Result를 받는 구조다. 중간 Cancel도 고려할 수 있다.
예를 들어 "A 지점까지 이동해라"는 요청은 즉시 끝나지 않는다. Robot이 수초에서 수분 동안 이동하면서 진행상태를 보내야 하므로 Navigation Goal 같은 작업에 Action이 잘 맞는다.
6. Topic, Service, Action을 이렇게 구분하면 쉽다
| 상황 | 추천 Interface | 예 |
|---|---|---|
| 계속 Data가 들어옴 | Topic | LiDAR, Camera, IMU |
| 요청 후 빠른 응답 | Service | Reset, Parameter Query |
| 시간이 걸리고 진행상태 필요 | Action | Navigation, Docking Task |
7. ROS1에서는 Master가 중요한 역할을 했다
Publisher와 Subscriber가 ROS Master에 Topic 정보를 등록하고 상대 Node 정보를 받은 뒤 통신하는 구조이다. ROS1에서 roscore와 ROS Master가 익숙한 이유가 여기에 있다.
8. ROS2는 중앙 Master 구조에서 벗어났다
ROS2는 ROS1의 중앙집중형 Master 방식과 다르게 Middleware의 Discovery를 이용하는 분산형 구조를 사용한다.
ROS2는 RMW라는 추상화 계층 아래 여러 Middleware를 지원한다. 공식 Kilted 문서 기준으로 DDS/RTPS 계열 Fast DDS, Cyclone DDS, Connext 등이 있고 Zenoh RMW도 지원된다.
단순히 명령어가 rosrun에서 ros2 run으로 바뀐 것이 아니다. Communication Architecture와 QoS, Real-time 및 Production 환경을 고려한 구조가 크게 강화됐다.
9. QoS는 왜 필요한가?
Camera Image와 상태 Event는 같은 방식으로 보내야 할 이유가 없다. 어떤 Data는 최신값이 중요하고 어떤 Data는 유실 없이 전달되는 것이 중요하다.
ROS2는 Reliability, Durability, History 같은 QoS Policy를 통해 통신 특성을 조정할 수 있다. 그래서 Publisher와 Subscriber의 QoS가 맞지 않으면 Topic 이름과 Message Type이 맞아도 통신이 되지 않는 상황이 발생할 수 있다.
10. ROS1과 ROS2 차이를 실무적으로 보면
| 항목 | ROS1 | ROS2 |
|---|---|---|
| Discovery | Master 중심 | Middleware 기반 분산 Discovery |
| Middleware | TCPROS, UDPROS 중심 | RMW 아래 DDS/RTPS, Zenoh 등 |
| QoS | 제한적 | 다양한 QoS Policy |
| Lifecycle | 기본기능 아님 | Managed Node 활용 가능 |
| 지원상태 | Noetic이 2025-05-31 EOL | 현재 신규 개발의 중심 |
11. 지금 시작하는 사람은 ROS1을 공부해야 할까?
신규 Project라면 일반적으로 ROS2부터 시작하는 것이 맞다. ROS1의 마지막 공식 Distribution인 Noetic은 2025년 5월 31일에 End of Life가 됐다.
Node, Topic, Service, TF, Odometry, Navigation 같은 핵심 개념을 이해하는 데에는 ROS1도 여전히 도움이 된다.
ROS1 내용은 개념 자료로 활용하고 설치방법과 Package Version은 최신 ROS2 공식문서를 기준으로 확인하는 방식이 좋다.
12. ROS가 Motor를 직접 안전하게 제어하는 것은 아니다
이 부분은 산업용 Robot에서 특히 중요하다. ROS Node가 cmd_vel을 보낸다고 해서 ROS가 Motor PWM이나 Safety Stop까지 모두 직접 책임지는 구조라는 뜻은 아니다.
실제 AMR에서는 역할을 나누는 경우가 많다.
Navigation Software와 Functional Safety를 같은 Layer에 모두 맡기지 않고 각각 요구사항에 맞는 System으로 분리해서 설계하는 것이 중요하다.
13. ROS에서 SLAM과 Navigation은 어떻게 연결될까?
LiDAR Node가 Scan을 발행하고 Odometry Node가 Robot Motion을 제공하면 SLAM이 Map과 Global Pose를 계산할 수 있다.
Nav2는 Map과 Pose를 사용해 Global Path와 Local Command를 만들고 최종 Velocity Command를 Base Controller에 전달한다.
ROS1에서도 Laser와 Odometry를 이용해 Map을 만들고 Navigation Stack에서 Localization과 Path Planning으로 이어지는 구조를 다룬다. Package와 Architecture는 현재 ROS2 문서를 기준으로 보는 것이 좋다.
14. ROS를 공부할 때 추천 순서
15. ROS 입문에서 자주 하는 실수
- 과거 ROS1 설치명령을 최신 Ubuntu에 그대로 실행하지 않는다.
- Topic 이름만 맞추지 말고 Message Type과 QoS까지 확인한다.
- TF Frame 이름과 Sensor 좌표계를 초기에 정리한다.
- Robot Hardware Interface와 ROS Algorithm을 분리한다.
- Simulation에서 된다고 실제 Sensor Timing과 Network가 동일하다고 가정하지 않는다.
- Safety Function을 일반 ROS Node 하나에 맡기지 않는다.
16. ROS를 한 문장으로 정리하면
Sensor Driver, State Estimation, SLAM, Navigation, Visualization과 Robot Application을 Node 단위로 나누고 Message Interface로 연결해 재사용성과 확장성을 높이는 Framework라고 이해하면 가장 쉽다.
마무리
ROS를 처음 공부할 때 설치명령보다 Node, Topic, Service, Action이 왜 필요한지 먼저 이해하는 것이 좋다. 이 네 개념을 이해하면 LiDAR, SLAM, Navigation이 어떤 방식으로 연결되는지 훨씬 쉽게 보인다.
ROS1 검색 자료는 대부분 기본 개념을 익히는 데 여전히 가치가 있지만, 신규 개발은 ROS2의 현재 지원 Distribution과 공식문서를 기준으로 시작하는 것이 적절하다.
같이 보면 좋은 TerryPack 글
'【로봇-AMR 실무】' 카테고리의 다른 글
| 【모터 제어 실무】 BLDC, PMSM, Servo Motor 차이 | 구조, 제어방식과 선정 기준 (0) | 2026.10.12 |
|---|---|
| 【로봇-AMR 실무】 AMR과 AGV 차이 | 기존 설명과 다른, 실제 실무 중심의 차이점 (5) | 2026.10.09 |
| 【로봇-AMR 실무】 SLAM이란? | LiDAR, Camera, IMU, Encoder는 어떻게 함께 쓰일까 (0) | 2026.10.08 |
| 【로봇 제어 실무】 엔코더 A상 B상 Z상이란? | PPR, CPR, 4체배, 회전방향과 RPM 계산 (0) | 2026.10.07 |
| 【로봇 설계 실무】 델타로봇 역기구학이란? | Workspace와 링크 길이 설계 방법 (0) | 2026.10.04 |
