Skip to content

limitations.md

Latest commit

 

History

History
151 lines (110 loc) · 14 KB

limitations.md

File metadata and controls

151 lines (110 loc) · 14 KB
Raw

현재 한계와 다음 검증

기준일: 2026-08-25

이 프로젝트는 제어·통신·시뮬레이션 모델과 이전 2모터 구성의 제한적 실물 벤치 기록이 있는 MVP입니다. 차체는 기존 M1/M2와 N20 1:298 M3/M4를 합친 4모터 전·후진 구조로 변경됐으며, 현재 구성의 바퀴 공중 시험부터 전체 트랙 왕복, 고전력 부하와 실제 습도 변화 효과까지 아직 검증하지 않았습니다.

검증 경계

확인된 범위

  • 서버·임무·ACK·측정 소비 로직의 자동 회귀시험
  • 3-Uno 프로토콜과 SimulIDE 프록시 계약
  • 운영 스케치의 CI 컴파일 게이트
  • Android 앱의 Gradle wrapper 빌드, lint, JVM 단위시험과 APK 생성
  • 이전 2모터 당시 정지 상태 또는 바퀴를 띄운 기본 보드 연결·통신·안전 출력 기록

확인되지 않은 범위

  • 서로 다른 모터·기어비·바퀴를 함께 쓰는 4모터 차체의 하중 주행과 속도 정합
  • 연속 라인에서의 전진·후진 장시간 추종과 완만한 좌우 보정
  • 실제 속도에서 RFID 판독률, 정지거리와 중간 역 재출발
  • 전체 HOME → ZONE2 → ZONE99 → HOME 왕복
  • 모터와 가습·제습 부하를 함께 켠 전력·열 안정성
  • 임무 수행 전후의 실제 습도 개선량
  • Android 실기기 설치·권한·foreground lifecycle, 실서버 WebView 인증, HC-06 RFCOMM·structured A6와 실차 end-to-end

자동 검사나 컴파일 통과는 위 미검증 항목의 성공 증거가 아닙니다.

주행과 위치 인식

현재 경로 모델은 HOME → ZONE2 → ZONE99 직선 하나입니다.

  • 구역 사이에 분기나 끊어진 선이 없어야 합니다.
  • ZONE2·ZONE99는 주행 중 RFID를 읽어 식별합니다. 등록한 HOME RFID는 복귀 중 보조 도착 수단이며 넓은 검은 종점 마커는 calibration과 RFID 미판독 fallback에 계속 사용합니다.
  • 위치는 엔코더·오도메트리·IMU가 아니라 마지막으로 확인한 역, 진행 방향과 예상 RFID 순서로 추론합니다.
  • RFID를 놓치거나 잘못된 순서의 태그를 읽으면 위치 신뢰도가 떨어지므로 안전 정지와 사용자 회수가 필요할 수 있습니다.
  • 두 IR만 사용하는 현재 배치에서는 특정 입력 조합이 정상 중앙 주행과 라인 유실에서 같을 수 있습니다. 라인 유실을 모든 경우에 독립적으로 검출한다고 가정하면 안 됩니다.
  • HOME의 두 IR 조건은 넓은 마커 위에 있다는 것은 확인하지만 실제 차체가 ZONE2 방향을 보는지는 확인하지 못합니다.
  • HOME RFID도 안테나 방향·거리와 속도에 따라 놓칠 수 있고 방향 자체를 증명하지 못합니다. 출발 시 잔류 HOME 태그 무시와 복귀 UID 판정은 실차에서 확인해야 합니다.
  • 제자리 180도 회전은 사용하지 않습니다. 기존 축/N20 축별 PWM, 후진 보정 방향, 태그 위치, 속도와 제동거리는 4모터 실차에서 조정해야 합니다.

분기 경로, 임의 순서의 다중 구역, 동적 장애물 우회, 지도 기반 위치 추정과 여러 로봇은 지원하지 않습니다.

센서와 제어

  • 고정 DHT 센서는 응답이 느리고 설치 위치·공기 흐름의 영향을 받습니다. 한 점의 값이 구역 전체 습도를 대표한다고 보장할 수 없습니다.
  • 온도 범위 이탈은 대시보드 경고만 만들며 냉난방 임무는 생성하지 않습니다.
  • 초음파 센서는 차체 전방을 바라보고 MotorUno ECHO=A0/TRIG=A1에 연결됩니다. 전진 중 15cm 미만 또는 STUCK_HIGH이면 MotorUno가 로컬 정지하고, 유효한 18cm 이상을 3회 확인해야 재개합니다. 후진은 감시하지 않으며 NO_ECHO·OUT_OF_RANGE는 새 정지를 만들지 않고 이미 걸린 래치를 풀지도 않는 진단값이므로, 단일 센서가 충돌 방지를 보장하지 않습니다.
  • 기본 stale 제한과 히스테리시스는 데모용 초기값입니다. 센서 전송 주기와 실제 공간 응답을 측정해 조정해야 합니다.
  • 완료한 측정 ID를 MySQL에 소비 처리해 반복 가동을 막지만, DB 손상·수동 변경·잘못된 장치 데이터까지 방어하는 안전 PLC는 아닙니다.
  • 명령 downlink는 WIFI, legacy BLUETOOTH, Android MOBILE_BRIDGE 중 하나입니다. sequence·revision·CRC가 든 7바이트 A6는 legacy gateway에서는 RF 링크 진단, mobile에서는 서버에 제출하는 delivery receipt이지만 어느 경우도 실행·완료 증거는 아닙니다.
  • WIFI는 /api/robot/command가 주 경로이고 legacy BLUETOOTH는 mailbox stale 시 차량 IP의 Wi-Fi GET을 fallback으로 사용할 수 있습니다. MOBILE_BRIDGE는 이 fallback을 닫아 endpoint가 409를 반환하며, Android·HC-06이 stale이면 안전 정지해야 합니다. 세 경로의 실제 RF·HTTP 단절 복구는 실차에서 검증되지 않았습니다.
  • MOBILE_BRIDGE 새·복구 세션의 failsafe는 structured A6 delivery 뒤에도 유지됩니다. delivery된 같은 ALL_STOP revision을 SensorUno가 ESP-01 status로 COMPLETED 보고해야만 해제됩니다. Wi-Fi status uplink가 없으면 서버는 실행·완료 또는 recovery 성공을 확정할 수 없습니다.
  • 소프트웨어 ALL_STOP, I2C watchdog과 제한시간은 물리 비상 정지 회로를 대체하지 않습니다.

액추에이터와 전력

  • 가습기와 펠티어 제습기가 시험 상자나 목표 공간의 습도를 얼마나 바꾸는지 정량 검증하지 않았습니다.
  • 모터, 펠티어와 팬은 Uno 또는 브레드보드 전원 경로로 공급하면 안 됩니다.
  • 펠티어는 큰 전류와 열을 발생시키며 적절한 논리레벨 드라이버, 퓨즈, 굵은 배선, 방열판, 팬과 별도 전력 예산이 필요합니다.
  • 모터의 기동·정지 전류가 논리 전원과 ESP-01을 불안정하게 만들 수 있으므로 접지·전원 분리와 전압 강하를 측정해야 합니다.
  • 기존 축과 N20 축의 실제 선속도가 다르면 강체 4륜이 서로 끌면서 실드 전류와 발열이 증가할 수 있습니다. 각 모터의 정지전류와 채널 정격을 확인하고 빠른 축 PWM을 낮춰야 합니다.
  • 릴레이 LED나 저전력 대체 부하의 성공은 실제 부하의 전기·열 안전을 증명하지 않습니다.
  • 응축수 배수, 누수, 결로, 회전체 보호와 배터리 저전압 차단은 소프트웨어 밖의 기구·전기 안전 항목입니다.

고전력 통합 전에는 전류 제한 전원과 물리 비상 정지를 준비하고, 부하 하나씩 시험하세요.

네트워크 보안

현재 HTTP 통신은 신뢰 LAN용입니다.

  • TLS가 없어 같은 네트워크에서 패킷을 볼 수 있습니다.
  • MOBILE_BRIDGE는 서로 다른 32자 이상의 CONTROL_API_TOKEN, ROBOT_STATUS_TOKEN, SENSOR_INGEST_TOKEN으로 Android 제어, 차량 status, 구역 sensor ingest를 분리합니다. WIFI/legacy도 robot·sensor token을 설정하면 해당 companion·sensor 요청에 인증을 강제합니다.
  • Bearer token은 장치별 암호 서명, nonce 또는 재전송 방지가 아니며 TLS가 없으면 같은 LAN에서 탈취·재사용될 수 있습니다.
  • legacy BLUETOOTH의 command fallback GET은 요청 IP가 마지막 차량 상태 IP와 같을 때만 delivered를 기록하지만, 이 비교는 장치 인증이 아니며 공유 주소·주소 변경·IP 위조를 방어하지 않습니다. MOBILE_BRIDGE에서는 이 fallback 자체를 금지합니다.
  • 로컬 server/mobile_bridge_secrets.local.ps1, 차량 robot_status_token.h, 두 구역의 sensor_ingest_token.h는 Git 제외 대상이지만 파일 권한·백업·회전은 운영자가 관리해야 합니다. token 변경 뒤 각 ESP-01을 재플래시하지 않으면 인증이 실패합니다.
  • rate limit, 사용자 계정, 역할 기반 권한과 보안 감사 로그가 없습니다.
  • 서버를 0.0.0.0에 바인드하면 LAN의 모든 인터페이스에 열릴 수 있습니다.

따라서 평문 HTTP는 격리된 전용 LAN에서만 사용하고 공인 인터넷, 포트 포워딩, 공개 Wi-Fi와 신뢰할 수 없는 학교·회사 공용망에 직접 연결하지 마세요. 더 넓은 네트워크에 배포하려면 TLS 종단, 장치별 자격증명, 요청 무결성·재전송 방지, 방화벽 allowlist와 비밀 회전 절차가 먼저 필요합니다.

서버와 데이터베이스

  • 단일 Python 프로세스와 단일 MySQL 인스턴스에 의존하며 고가용성·자동 failover가 없습니다.
  • 기본 운영은 사전 생성된 DB와 전용 humibot 계정을 사용합니다. 관리자 계정이나 DB 자동 생성 권한을 상시 운영에 사용하면 안 됩니다.
  • 서버 시작 시 테이블과 일부 호환 마이그레이션은 적용하지만 임의의 오래된 스키마를 자동 복구하지 않습니다.
  • DB 백업, 보존 기간, 개인정보 분류와 장애 복구 목표가 제품 수준으로 정의되지 않았습니다.
  • 장치 시간이 아니라 서버 수신 시간을 기준으로 stale과 지속시간을 계산하므로 네트워크 지연·재전송이 측정 시점과 다를 수 있습니다.
  • legacy humidity listener는 호환을 위해 선택적으로 제공되며 새 설치에서는 기본 비활성 상태를 유지하는 편이 안전합니다.

SensorUno 자원 한계

HTTP·JSON과 Wi-Fi 처리를 ESP-01 companion으로 옮겼지만 SensorUno는 RC522, DHT22, 경로 상태와 두 I2C slave 조율을 계속 담당하므로 Uno R3 자원 여유를 관리해야 합니다. 현재 로컬 빌드는 flash/SRAM 28,270B / 949B이고 CI budget은 29,000B / 1,500B입니다. 같은 빌드의 MotorUno는 11,546B / 464B, ActuatorUno는 16,530B / 765B입니다. ESP-01은 companion 263,772B / 28,544B, ZONE2 258,272B / 28,428B, ZONE99 258,352B / 28,440B입니다.

  • 작은 라이브러리·로그·파서 추가도 flash budget을 넘길 수 있습니다.
  • 플래시가 남아도 SRAM 부족이나 스택 충돌이 발생할 수 있습니다.
  • companion UART/HTTP 재시도나 긴 시리얼 출력이 RFID 스캔, I2C keepalive와 정지 확인을 지연시킬 수 있습니다.
  • 디버그 문자열을 줄이는 것만으로 런타임 타이밍이 안전하다고 결론 내릴 수 없습니다.

기능 확장이 필요하면 먼저 불필요한 호환·진단 기능을 분리하고, 더 큰 플래시·SRAM과 하드웨어 UART를 가진 컨트롤러로 이전하는 방안을 검토하세요. 용량 제한을 피하려고 안전 검사나 ACK 계약을 제거하면 안 됩니다.

시뮬레이션 한계

SimulIDE 회로는 지원되지 않는 ESP-01, RF 환경, 실제 RC522와 고전력 부하를 버튼·LED·프록시 펌웨어로 대신합니다. 체크인 artifact는 이전 주변기기 배치를 보존하며, 현재 SensorUno D4 DHT22·MotorUno A0/A1 HC-SR04 핀맵의 검증 근거가 아닙니다.

검증 가능한 것:

  • 3-Uno 역할과 기본 I2C 주소
  • 명령·ACK·상태 전이 계약
  • 일부 watchdog, calibration과 실패 처리
  • 현재 회로와 빌드 manifest의 파일 일치

검증할 수 없는 것:

  • legacy Bluetooth structured A6·Wi-Fi command fallback, Android Classic SPP와 MOBILE_BRIDGE structured A6의 실제 UART·RF·HTTP 타이밍
  • RFID 안테나 방향·거리와 주행 중 판독률
  • 모터 토크, 관성, 미끄러짐과 제동거리
  • 전원 노이즈, 전압 강하, 발열과 실제 가습·제습 효과

다음 검증 순서

위험을 한 번에 합치지 않도록 다음 순서를 권장합니다.

  1. 구성 동결: 현재 M1~M4 배선, 보드별 펌웨어와 네트워크 설정을 식별하고 CI를 통과시킵니다.
  2. 무부하 벤치: 바퀴를 띄우고 M1~M4를 한 채널씩 500ms 시험한 뒤 좌우 쌍·전체 전진·전체 후진을 확인합니다.
  3. 저속 트랙: 고전력 액추에이터를 분리한 채 전·후진 선 추종, 축별 PWM 정합, HOME·구역 태그 판독률과 정지거리를 측정하고 HOME 마커 fallback을 확인합니다.
  4. 통신 모드 벤치: WIFI, legacy BLUETOOTH, MOBILE_BRIDGE를 섞지 않고 하나씩 시험합니다. mobile은 Android 권한·background·disconnect, HC-06 structured receipt, /api/robot/command 409와 같은 ALL_STOP revision의 SensorUno COMPLETED까지 확인합니다.
  5. 무부하 폐루프: 두 구역 센서와 MySQL 서버를 연결해 TASK → 이동 → 도착 → 대체 부하 → 새 측정 → 복귀 전체 흐름을 검증합니다.
  6. 단일 실제 부하: 가습과 제습을 각각 전류 제한 상태로 시험해 전류·발열·자동 OFF와 습도 변화량을 기록합니다.
  7. 통합 전력: 최악의 동시 부하에서 전원, 퓨즈, 드라이버, 배선과 방열의 여유를 확인합니다.
  8. 고장 주입: RFID 누락, 라인 이탈, 보드 재부팅, I2C·Wi-Fi·Bluetooth·Android·DB 단절과 센서 stale에서 안전 정지를 확인합니다.
  9. 반복성: 같은 코스와 환경에서 여러 회 반복하고 성공률·실패 유형·복구 절차를 기록합니다.

각 단계는 테스트 문서의 결과 형식으로 증거를 남기고, 실패한 단계의 원인을 해결하기 전 다음 단계로 넘어가지 않습니다.

완료로 표시하기 위한 최소 기준

프로젝트 첫 화면에서 “실차 폐루프 검증 완료”라고 표시하려면 최소한 다음 증거가 필요합니다.

  • 현재 커밋과 대응되는 세 Uno 펌웨어 빌드 결과
  • 두 활성 구역의 실제 센서 입력과 MySQL 기록
  • HOME calibration 이후 양 구역을 포함한 무부하 왕복 영상·로그
  • 명령 revision, RFID 도착, Motor ACK, Actuator RUNNING → DONE, 새 측정 watermark와 HOME 복귀의 연속 기록
  • 네트워크·RFID·I2C 중 하나를 끊었을 때 안전 정지와 복구 기록
  • 실제 부하를 사용할 경우 전류·온도·전압 강하와 퓨즈·방열 검증표

그 전까지는 현재 상태를 자동 검사와 Android 소프트웨어 빌드 제공 / 이전 2모터 벤치 기록만 있음 / 현재 4모터·Android HC-06 실물 end-to-end 미검증으로 유지합니다.