로봇센서 드라이버 구현
📌 개요
- 드라이버 = 센서 하드웨어 세부(레지스터·프레임·전기 신호)를 감추고 상위 소프트웨어에 "read() 하면 물리량이 나오는" 표준 창구를 제공하는 계층
- 출제 포인트: 드라이버 처리 흐름 5단계, 데이터 획득 3방식(폴링·인터럽트·DMA)의 구분, 링 버퍼, 고장 감지(무응답·고정값)
📖 핵심 개념
드라이버의 자리와 역할
드라이버는 계층 구조의 아래층이다: 센서 HW → (인터페이스) → 드라이버 → 미들웨어(토픽) → 알고리즘·응용.
- 하드웨어 추상화: 상위는 센서 기종을 몰라도 됨 — 기종 교체 시 드라이버만 수정 (→ DIP·추상화, HAL)
- 상위가 쓰는 표준 인터페이스: 초기화 / 설정 / 읽기(콜백) / 상태 조회 / 종료
드라이버 처리 흐름 5단계 (시험 단골)
- 초기화(Init): 통신 포트 열기, 센서 설정(측정 모드·주기·범위 — 설정 레지스터/명령), 자기진단 확인
- 데이터 획득(Acquire): 폴링·인터럽트·DMA로 바이트 수신 (아래)
- 파싱·검증(Parse): 프레임 경계 동기화 → 체크섬 검증 → 필드 추출 — 수신 상태 기계의 구현. 검증 실패 프레임은 폐기하고 오류 계수
- 변환(Convert): 원시값 → 물리량 — 스케일링 역적용, 단위 변환, 캘리브레이션 적용
- 발행(Publish): 측정 시각 타임스탬프를 찍어 표준 메시지로 미들웨어에 발행 (→ 토픽)
데이터 획득 3방식 — 폴링 vs 인터럽트 vs DMA (시험 최다 빈출)
| 방식 | 원리 | 장점 | 단점 |
|---|---|---|---|
| 폴링(Polling) | CPU가 반복해서 "왔니?" 확인 | 구현 단순, 타이밍 예측 쉬움 | CPU 낭비(대부분 헛확인), 늦게 확인하면 놓침 |
| 인터럽트(Interrupt) | 데이터 도착 시 HW가 CPU 호출 | 도착 즉시 처리, 대기 낭비 없음 | ISR 설계 필요 — ISR은 짧게(수신만 하고 처리는 태스크로) (→ 임베디드 프로그래밍 특성) |
| DMA | 전용 HW가 CPU 개입 없이 메모리로 블록 전송 | 대량·고속 데이터에 CPU 부하 최소 | 설정 복잡 — 카메라·LiDAR급에 필수 |
감각: 저속 소량 = 폴링도 무방, 이벤트성 = 인터럽트, 고속 대량 = DMA.
링 버퍼 (Circular Buffer) — 생산자와 소비자의 완충지
수신(ISR/DMA — 생산자)과 처리(태스크 — 소비자)의 속도 차를 흡수하는 고정 크기 순환 큐.
- 쓰기 포인터와 읽기 포인터가 배열 끝에서 처음으로 되돌아 돎 — 동적 할당 없이 동작(실시간 친화)
- 오버플로 정책을 정해야 한다: 가장 오래된 데이터 덮어쓰기(최신 우선) vs 새 데이터 버리기 — 어느 쪽이든 오버플로 발생을 계수·보고
오류 처리와 고장 감지 (시험 포인트)
드라이버는 "값이 안 온다/이상하다"를 가장 먼저 아는 곳이다.
- 프레임 오류: 체크섬 실패 → 해당 프레임 폐기, 오류율 집계 (오류율 급증 = 배선·노이즈 의심)
- 타임아웃: 일정 시간 무수신 → 재시도·포트 재연결 → 지속 시 고장 판정 (→ 하트비트)
- 고정값(Stuck) 감지: 값이 비정상적으로 오래 변하지 않음 — "살아 있는 척하는 고장"
- 상태 보고: 드라이버는 데이터만이 아니라 상태(정상/열화/고장)와 진단 정보도 발행 — 상위가 축퇴 운전·안전 정지를 판단할 근거 (→ 축퇴 운전)
타임스탬프의 원칙
- 수신 시각이 아니라 측정 시각 기준 — 통신·버퍼 지연이 섞이면 융합이 어긋난다 (→ 시간 동기화)
- 센서가 자체 시각을 주면 호스트 시계와의 오프셋을 추정·보정, 없으면 수신 시각에서 알려진 지연을 빼서 근사
드라이버의 시험
📊 다이어그램 · 수식
드라이버 처리 흐름
flowchart LR
HW["센서 HW"] --> AQ["② 획득
폴링/인터럽트/DMA"] --> RB["링 버퍼
(속도 차 완충)"] --> PS["③ 파싱·검증
프레임·체크섬"] --> CV["④ 변환
물리량·캘리브레이션"] --> PB["⑤ 발행
타임스탬프+토픽"]
IN["① 초기화
포트·설정·자기진단"] -.선행.-> AQ
PS -- 검증 실패 --> ER["폐기·오류 계수"]획득 3방식의 CPU 개입
flowchart TD
P["폴링: CPU가 계속 확인
(단순·낭비)"]
I["인터럽트: 도착 시 CPU 호출
(즉시·ISR 짧게)"]
D["DMA: 전용 HW가 메모리 직송
(대량·CPU 무개입)"]
P --- I --- D🎯 핵심 요약 · 암기 포인트
✏️ 예상문제
1. 센서 드라이버의 처리 흐름을 순서대로 옳게 나열한 것은?
① 파싱 → 초기화 → 획득 → 발행 → 변환 ② 초기화 → 획득 → 파싱·검증 → 변환 → 발행 ③ 획득 → 발행 → 파싱 → 변환 → 초기화 ④ 변환 → 파싱 → 획득 → 초기화 → 발행
정답 및 해설
정답: ② 포트·설정을 준비하고(초기화), 바이트를 받아(획득), 프레임을 검증·추출하고(파싱), 물리량으로 바꿔(변환), 타임스탬프와 함께 내보낸다(발행). 검증 실패 프레임은 폐기하고 오류를 계수한다.
2. 카메라·LiDAR처럼 대량의 데이터를 CPU 개입 없이 메모리로 옮기는 데 적합한 획득 방식은?
① 폴링 ② 소프트웨어 지연 루프 ③ DMA ④ 수동 레지스터 읽기
정답 및 해설
정답: ③ DMA는 전용 하드웨어가 블록 전송을 대행해 CPU 부하를 최소화한다. 폴링은 CPU 낭비, 인터럽트도 바이트마다 ISR이 뛰면 고속 대량에서는 부하가 커진다 — "저속=폴링, 이벤트=인터럽트, 대량=DMA"로 기억하자.
3. 링 버퍼(circular buffer)에 대한 설명으로 옳지 않은 것은?
① 수신부(생산자)와 처리부(소비자)의 속도 차를 흡수한다 ② 고정 크기라 동적 메모리 할당 없이 동작해 실시간에 유리하다 ③ 가득 차면 오버플로 정책(덮어쓰기/버리기)이 필요하다 ④ 버퍼가 가득 차는 일은 발생할 수 없으므로 감시가 불필요하다
정답 및 해설
정답: ④ 소비자가 밀리면 언제든 가득 찰 수 있다. 덮어쓰기든 버리기든 데이터 손실이므로, 오버플로 발생을 계수·보고해 처리 지연(설계 문제)을 드러내야 한다.
4. 센서가 주기적으로 값을 보내고는 있지만 값이 비정상적으로 오랫동안 전혀 변하지 않는 고장을 감지하는 방법은?
① 타임아웃 감지 ② 고정값(stuck) 감지 ③ 체크섬 검증 ④ 레벨 시프터
정답 및 해설
정답: ② 통신은 살아 있으므로 타임아웃(①)에 안 걸리고, 프레임도 유효하므로 체크섬(③)도 통과한다 — "살아 있는 척하는 고장"은 값의 변화 자체를 감시하는 고정값 감지로만 잡힌다.
5. 드라이버가 발행하는 데이터의 타임스탬프에 대한 설명으로 가장 적절한 것은?
① 발행 함수를 호출한 시각을 쓰면 충분하다 ② 통신·버퍼 지연이 섞이지 않도록 측정 시각 기준으로 찍는 것이 원칙이다 ③ 타임스탬프는 융합과 무관하다 ④ 시각은 수신 순서로 대체할 수 있다
정답 및 해설
정답: ② 수신·발행 시각에는 통신 지연과 버퍼 대기가 섞여 있어, 이 값으로 융합하면 "그때 그 자리"가 어긋난다. 센서 자체 시각의 오프셋 보정 또는 알려진 지연의 차감으로 측정 시각을 복원한다.
🔗 관련 노트
- 로봇센싱 알고리즘 설계 — 드라이버 위에서 도는 보정·필터·융합
- 통신 프로토콜 설계 — 파서가 구현하는 프레임 규격
- 로봇센서 인터페이스 — 획득이 일어나는 물리 계층
- 임베디드 프로그래밍 특성 — ISR 설계·실시간 규칙
- 로봇 미들웨어 구조 설계 — 발행되는 토픽의 세계
- _MOC 지능소프트웨어