레이저 거리 · 로터리 엔코더 · IMU 각도 3종 데이터 로거 사전 기획서 — 현장 운영자 / 데이터 분석 담당자 / 설치·보수 담당자 3개 흐름 · 2026.08 · 우리팀
장비 앞에서 프로그램을 켜는 사람이 겪는 5단계. 화면은 단순하지만 그 뒤의 수집 구조는 데이터를 한 건도 흘리지 않습니다.
설치 파일로 배포된 SensorLogger 실행. .NET 미설치 PC에서도 바로 구동됩니다.
레이저는 COM 포트, IMU는 MIP 포트, 엔코더는 카운터 경로로 각각 연결하고 수신값을 확인합니다.
저장 위치와 세션 이름을 확정하고 시작. 이후 화면 조작과 무관하게 수집이 계속됩니다.
거리·회전각·기울기를 큰 숫자로 보면서 수신 = 저장 카운터와 드롭 0을 함께 확인합니다.
수집을 끝내면 채널별 수신/저장/폐기 건수가 요약되고 바로 CSV로 내보낼 수 있습니다.
제안서 역제안 ①(착수 3일 결선 설계서)이 실제 화면으로 구현된 모습입니다. 세 채널의 접속 경로를 한 줄씩 나열하되, 엔코더만 COM 포트가 아니라 '카운터 경로'로 표시됩니다. 연결 테스트 수신값을 각 행 우측에 띄워, 배선이 맞았는지 프로그램을 종료하지 않고 확인합니다.
엔코더 행은 카운터 경로(산업용 카운터 모듈 / USB DAQ 쿼드러처 / 레벨시프터+MCU)를 드롭다운으로 교체할 수 있게 설계했습니다. 하단 경고 배너는 품번 해석 근거를 그대로 노출해, 운영자가 바뀌어도 같은 실수가 반복되지 않게 합니다.
| t_mono (s) | 채널 | 값 | 상태 |
|---|---|---|---|
| 6137.482913 | CH3 · IMU | roll 2.141 pitch -0.873 | 저장됨 |
| 6137.482804 | CH1 · LASER | 187.42 mm | 저장됨 |
| 6137.481902 | CH3 · IMU | roll 2.139 pitch -0.871 | 저장됨 |
| 6137.480118 | CH2 · ENCODER | 3182 count / 286.38 deg | 저장됨 |
| 6137.479903 | CH3 · IMU | roll 2.136 pitch -0.870 | 저장됨 |
제안서 역제안 ②(무손실 3-레이어 파이프라인)를 증명하는 핵심 화면입니다. 공고에서 요구한 '텍스트 수치 표시'를 대형 숫자로 만들고, 그 아래에 수신 카운트 = 저장 카운트 = 드롭 0을 상시 노출합니다. 데모 Step 3에서 이 화면이 그대로 작동합니다.
센서별 수집 스레드는 크기 제한 링버퍼에만 밀어 넣고 끝냅니다. 저장 스레드가 500건 단위로 묶어 커밋하고, 화면은 33ms 주기로 최신값만 읽어 갱신합니다. 화면이 느려져도 수집·저장은 영향을 받지 않는 구조입니다.
| 채널 | 수신 | 저장 | 체크섬 실패 | 재연결 |
|---|---|---|---|---|
| CH1 · LASER | 2,234,092 | 2,234,092 | 3 | 0 |
| CH2 · ENCODER | 223,410 | 223,410 | — | 0 |
| CH3 · IMU | 19,883,416 | 19,883,416 | 11 | 1 |
수집을 끝냈을 때 운영자가 가장 알고 싶은 것은 '이번 데이터 믿어도 되나'입니다. 채널별 수신·저장·체크섬 실패·재연결 횟수를 표로 제시하고, 좌측에 드롭 0을 크게 배치했습니다. 데모 Step 4의 비교 수치가 여기서 나옵니다.
체크섬 실패 패킷은 DB에 넣지 않고 카운트만 남깁니다. 즉 '저장 행 수'는 검증을 통과한 데이터만의 수치이며, 수신 카운트와 일치한다는 것은 유효 데이터가 전부 남았다는 뜻입니다. 이 요약은 검증 리포트 파일로도 저장됩니다.
공고의 "추후 확인할 수 있도록"이라는 문장이 실제로 무엇을 뜻하는지. 사후 분석이 이 로거의 최종 사용처입니다.
sensor_log.db 파일 하나만 있으면 됩니다. 다른 PC로 복사해 열어도 그대로 동작합니다.
기간과 채널로 걸러 분석할 수집 세션을 고릅니다. 수집 중에도 조회가 가능합니다.
속도가 다른 세 채널을 하나의 시간축에 맞춰 정렬한 결과를 미리 봅니다.
IMU 기준인지 레이저 기준인지, 몇 ms 간격으로 뽑을지 분석 목적에 맞게 고릅니다.
엑셀에서 바로 열리는 형태로 저장. 원본 테이블은 조금도 건드리지 않습니다.
로컬 DB에 쌓인 세션을 기간·채널로 찾는 진입 화면입니다. 각 세션 카드에 수집 시간, 저장 행 수, 드롭 건수를 함께 표기해 '어느 세션이 온전한 데이터인지'를 목록 단계에서 판단할 수 있게 했습니다.
SQLite를 WAL 모드로 열어 읽기 트랜잭션이 쓰기를 막지 않습니다. 그래서 현장에서 수집이 돌아가는 중에도 사무실에서 같은 파일을 조회할 수 있습니다. 세션 메타는 별도 테이블로 관리해 대용량 샘플 테이블을 스캔하지 않습니다.
| t_utc | t_mono (s) | distance_mm | enc_deg | roll_deg | pitch_deg | yaw_deg |
|---|---|---|---|---|---|---|
| 09:32:14.120 | 6137.480 | 187.42 | 286.38 | 2.141 | -0.873 | 118.421 |
| 09:32:14.130 | 6137.490 | 187.44 | 286.41 | 2.139 | -0.871 | 118.424 |
| 09:32:14.140 | 6137.500 | 187.41 | 286.45 | 2.136 | -0.870 | 118.428 |
| 09:32:14.150 | 6137.510 | 187.38 | 286.49 | 2.132 | -0.868 | 118.431 |
| 09:32:14.160 | 6137.520 | 187.35 | 286.52 | 2.128 | -0.866 | 118.435 |
| 09:32:14.170 | 6137.530 | 187.33 | 286.56 | 2.124 | -0.864 | 118.439 |
속도가 제각각인 세 채널(레이저 100Hz, IMU 1000Hz, 엔코더 이벤트)을 하나의 시간축에 정렬한 결과입니다. 이 화면이 없으면 '그때 그 거리에서 각도가 몇 도였나'를 답할 수 없습니다. 시간 정렬 설계가 곧 이 프로젝트의 데이터 품질입니다.
채널별 원본 테이블은 절대 변형하지 않고, 읽기 전용 뷰에서 기준 축 샘플마다 가장 가까운 이웃 값을 붙입니다. 채널 간 최대 시차를 함께 표기해 정렬 결과의 신뢰 범위를 숨기지 않습니다.
공고에서 "(필요 시)"로 표기된 CSV 다운로드를, 실제 분석에 쓸 수 있는 수준으로 설계했습니다. 구간·기준 축·리샘플 간격 3가지만 고르면 되고, 오른쪽에 실제 출력될 헤더와 첫 다섯 줄을 미리 보여줍니다.
예상 행 수와 파일 크기를 내보내기 전에 계산해 표시하므로, 수백 MB짜리 파일을 만들어 놓고 후회하는 일이 없습니다. 내보내기는 스트리밍 방식으로 처리해 메모리에 전체를 올리지 않습니다.
현장에서 숫자가 튀면 배선 문제인지 파싱 문제인지부터 갈라야 합니다. 그 판단을 화면이 대신해 주도록 설계했습니다.
결선 설계서대로 A·B·Z와 전원이 연결됐는지 확인하고 프로그램을 진단 모드로 전환합니다.
엔코더 펄스 파형과 IMU 패킷 원문을 눈으로 보고 어느 계층에서 끊겼는지 확인합니다.
B상 단선, 체크섬 실패, 프레임 절단 등 원인이 화면에 그대로 이름으로 표시됩니다.
같은 상황을 시뮬레이터로 재현해 수정이 실제로 통했는지 장비 없이 검증합니다.
롤링 로그 파일 하나만 보내주시면 원격에서도 원인 분석이 가능합니다.
왼쪽은 엔코더의 A·B·Z 쿼드러처 신호, 오른쪽은 IMU의 MIP 패킷 헥사 원문입니다. 값이 이상할 때 '센서가 이상한지, 배선이 이상한지, 우리 파싱이 이상한지'를 이 한 화면에서 가릅니다. 제안서 역제안 ①의 사후 관리 버전입니다.
A·B 위상차가 90°에서 벗어나면 배선/노이즈, Z상이 없으면 원점 복귀 불가, 체크섬 실패가 늘면 케이블 길이나 접지 문제로 좁혀집니다. 판단 기준을 화면 안에 문장으로 적어 담당자가 바뀌어도 동일하게 진단됩니다.
제안서 역제안 ③(시뮬레이터 선행 개발)의 실체입니다. 센서 3종의 출력을 가상 COM 포트와 카운터 채널로 만들어 내고, USB 순단·체크섬 오류·B상 단선 같은 고장 상황을 버튼으로 재현합니다. 데모 Step 2가 이 화면의 동작을 체험시킵니다.
실물 도착 전에는 개발 환경, 도착 후에는 회귀 테스트 장비, 납품 후에는 현장 재현 도구로 역할이 바뀝니다. 24개 고장 케이스를 매 빌드마다 자동 실행해 '드롭 0'이 우연이 아님을 반복 검증합니다.
| 09:32:14.118 | INFO | SESSION | 세션 SES-20260901-0932 시작 · WAL 모드 · 배치 500 |
| 09:32:14.204 | INFO | CH2 | Z상 원점 감지 · 누적 카운트 0으로 리셋 |
| 11:07:41.882 | WARN | CH3 | MIP 체크섬 불일치 1건 · 패킷 폐기 (누적 7) |
| 12:18:03.117 | WARN | CH3 | USB 순단 감지 · 재연결 시도 |
| 12:18:05.221 | INFO | CH3 | 재연결 성공 (2.104초) · 버퍼 잔량 0 · 손실 없음 |
| 14:52:09.640 | WARN | WRITER | 디스크 응답 지연 380ms · 버퍼 점유 41%로 흡수 |
| 15:44:55.310 | INFO | SESSION | 세션 종료 · 수신 22,340,918 = 저장 22,340,918 |
장시간 무중단 운전에서 아무 일도 없는 경우는 없습니다. 중요한 것은 무슨 일이 있었고 그것이 데이터에 영향을 줬는지를 말해 주는 것입니다. 경고는 남기되 손실은 0이라는 사실을 상단 지표로 대비시켰습니다.
롤링 파일로 일자별 분할 저장되며, 세션 시작/종료·재연결·체크섬 실패·디스크 지연 흡수 등 데이터 신뢰도에 영향을 주는 이벤트만 선별해 기록합니다. 파일 하나로 원격 원인 분석이 가능하도록 포맷을 고정했습니다.