하드웨어 아키텍처 재설계
ESP32 단독 구조에서 RPi5 + STM32로 전환, 센서 3개를 LiDAR 1개로 통합해 비용 절감과 ROS2 기반 개발 환경 확보
system
배경
- 제품: Wally (수평 슬라이딩 벽), Ceily (수직 천장 리프트)
- v1 구성: ESP32-S3 단독 (모터 제어 + WiFi/BLE + 센서)
- 센서 (v1): ToF 센서 2개 + 포토 센서 1개
- 요구사항: 이동 중 사람/물체 감지 후 안전 정지
핵심 문제
센서 한계
- 포토 센서로는 이동 중인 사람을 감지할 수 없습니다
- ToF는 ISO-SPI 통신을 사용해서 읽기 속도가 느립니다
- ToF 해상도 4mm
- 센서가 세 개나 필요해서 하드웨어 복잡도가 높습니다
컨트롤러 한계
- ESP32가 WiFi/BLE와 모터 제어를 동시에 돌리면 메모리를 거의 다 사용합니다
- 메모리 부족으로 WiFi 연결 끊김이 잦습니다
- ESP32로는 ML/AI 확장이 불가능합니다
- 저장 공간 부족으로 사고 로깅도 어렵습니다
핵심 아이디어
센서 통합과 아키텍처 분리를 동시에 해결했습니다:
- LiDAR 하나로 ToF 2개 + 포토 센서 기능을 모두 대체 (거리 + 사람 감지 + 구역 감지)
- RPi5 + STM32 분리로 실시간 성능은 유지하면서 메모리/로깅 문제 해결
접근 방식
1) 센서 통합: ToF + 포토 → LiDAR
| 이전 (v1) | 이후 (v2) |
|---|---|
| ToF 2개 + 포토 센서 | RP LiDAR C1 1개 |
| 106,000원 | 90,000원 |
| 센서 3개 | 센서 1개 |
- 거리 측정 정확도 향상
- 각도 측정은 비슷
- 구역 감지 추가: 360° 스캔으로 이동 경로 장애물 감지
- 하드웨어 단순화: 센서 3개에서 1개로
- 비용 16,000원 절감
2) 아키텍처 분리: ESP32 단독 → RPi5 + STM32
v1: ESP32-S3 (모터 제어 + WiFi/BLE + 센서)
v2: RPi5 (ROS2 + WiFi/BLE + ML) ←UART→ STM32F446 (모터/Modbus 실시간)역할 분리:
- RPi5: ROS2 로직, WiFi/BLE 통신, 향후 ML/AI
- STM32F446: 실시간 모터 제어, Modbus/RS485, GPIO
ESP32 + STM32 대신 RPi5를 선택한 이유:
- ROS2 네이티브 지원 (micro-ROS는 제한적)
- rosbag으로 사고 분석 가능 (제조물 책임 대응)
- Gazebo 시뮬레이션 환경 구축 가능
- 향후 ML/비전/음성 확장 대비
트레이드오프:
| 항목 | ESP32 단독 | RPi5 + STM32 |
|---|---|---|
| 비용 | ~$10 | ~$90+ |
| 전력 | ~0.5W | ~5.5W |
| 부팅 | 즉시 | ~30초 |
| ROS2 | 제한적 | 네이티브 |
| 로깅 | 수 MB | 무제한 |
3) STM32 펌웨어 재사용
- STM32 펌웨어는 v1 그대로 유지
- 로직만 상위 레이어(RPi)로 이동
- UART 프로토콜로 통신
- Linux는 실시간 성능이 약해서 모터 제어는 STM32에서 처리
결과
- 센서 비용 절감: 106,000 → 90,000원 (-16,000원)
- 하드웨어 단순화: 센서 3개에서 1개로
- WiFi 안정성 향상: 메모리 분리로 끊김 해결
- 사고 분석 기반: ROS2 rosbag으로 모든 토픽 기록 가능
- 시뮬레이션 환경: Gazebo (ROS2 Jazzy + Gazebo Harmonic) 구축 완료
- 확장성 확보: 향후 ML/AI, SLAM, Nav2를 위한 기반 마련
핵심 교훈
- 센서 통합으로 비용 절감과 기능 향상을 동시에 달성
- 아키텍처 분리로 안정성(WiFi)과 확장성(ROS2/ML) 확보
- 비용/전력 증가는 사고 분석과 시뮬레이션 환경으로 충분히 상쇄
- STM32 펌웨어 재사용으로 마이그레이션 부담 최소화