Skip to content

Repository files navigation

구르미 — 이동형 습도 제어 로봇

두 구역의 온·습도를 수집하고, 우선순위가 가장 높은 구역으로 이동해 가습 또는 제습 임무를 수행하도록 설계한 Arduino·Python 팀 프로젝트입니다.

CI

구르미 관제 대시보드

합성 데이터로 렌더링한 관제 UI 예시입니다. 실차 왕복이나 고전력 가습·제습 부하의 성공 증거가 아닙니다.

프로젝트 한눈에 보기

  • 고정 센서 노드 2대가 Wi-Fi로 구역별 온·습도를 전송합니다.
  • Python 서버가 측정값과 임무 이력을 MySQL에 저장하고, 습도 편차와 지속시간으로 임무 우선순위를 계산합니다.
  • 자동차는 SensorUno(RC522·DHT22·임무 조율), MotorUno(4모터·라인·전방 초음파·HOME·watchdog), ActuatorUno(Bluetooth 명령 수신·릴레이·원격 온·습도 LCD) 3개 Uno R3와 ESP-01 companion(상태·실행 ACK Wi-Fi uplink, WIFI/legacy 명령 downlink)으로 역할을 분리합니다.
  • 4모터 구동부는 차체를 돌리지 않고 전진·후진하며 하나로 이어진 검은 선을 추종하고, 주행 중 RFID로 중간·목표 구역과 등록 시 복귀 HOME을 확인합니다.
  • 부팅 직후 위치를 추측하지 않습니다. HOME 마커에서 방향을 맞추고 CALIBRATE_HOME을 완료하기 전까지 주행을 차단합니다.
  • 임무 완료 뒤에는 같은 측정값으로 액추에이터를 반복 가동하지 않고, 새로운 구역 측정을 기다립니다.

현재 검증 범위

범위 상태 의미
서버·프로토콜·폐루프 회귀시험 자동 검사 제공 python scripts/check.py로 소스 모델과 체크인 SimulIDE artifact 무결성을 검사합니다. SimulIDE의 이전 센서 배치는 현재 실물 핀맵 검증이 아닙니다.
운영 펌웨어 CI 컴파일 게이트 제공 현재 로컬 빌드 flash/SRAM은 SensorUno 28,270B / 949B, 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입니다. SensorUno CI budget은 29,000B / 1,500B입니다.
Android HC-06 브리지 소프트웨어 검사·CI 제공 Gradle 빌드·lint·JVM 단위시험 24/24와 Debug/Release APK 생성은 통과했지만 Android 실기기 설치, foreground lifecycle, 실서버 인증, HC-06 RFCOMM·structured receipt와 실차 end-to-end는 아직 검증하지 않았습니다.
이전 3-Uno·2모터 벤치 기록 제한적 과거 증거 정지 상태의 연결, RFID→STOP→액추에이터와 안전 출력 기록이며 현재 M3/M4가 포함된 4모터 검증은 아닙니다.
현재 4모터 하드웨어 부분 시험 M1~M4 개별·좌우 쌍·전체 방향 출력을 짧게 확인했습니다. 전방 센서와 실제 하중·장시간 주행은 별도 검증해야 합니다.
연속 라인·RFID 실차 왕복 미검증 서로 다른 기존 모터와 N20 1:298을 함께 쓰는 4모터 차체의 속도 정합, 전·후진 선 추종, 카드 판독과 제동거리를 트랙에서 검증해야 합니다.
가습·제습 고전력 부하 미검증 전류·발열·퓨즈·방열과 실제 습도 변화량을 별도로 측정해야 합니다.

자세한 증거 범위와 재현 명령은 테스트 문서, 남은 위험은 한계 문서를 확인하세요.

SensorUno·MotorUno·ActuatorUno와 ESP-01 companion은 반드시 같은 커밋의 운영 펌웨어를 모두 업로드합니다. SensorUno는 companion의 protocol version을 확인하고, 보정 시작 시 PROTOCOL_SYNC(7) exact ACK를 확인합니다. 이동은 구형 값 1/2와 분리된 0x11/0x12만 사용합니다. 일부 보드만 다른 버전이면 주행·액추에이터 시험을 시작하지 않습니다.

시스템 구성

flowchart LR
    Z2[구역 센서 ZONE2] -->|온·습도 HTTP| API[Python 제어 서버]
    Z99[구역 센서 ZONE99] -->|온·습도 HTTP| API
    API <--> DB[(MySQL)]
    UI[웹 대시보드] <--> API
    API -->|legacy BLUETOOTH: USB B-frame| GW[서버 Uno<br/>D0/D1 USB · D2/D3 Bluetooth]
    GW -->|legacy Bluetooth| ACT[ActuatorUno]
    API -->|MOBILE_BRIDGE: HTTP lease| PHONE[Android 앱]
    PHONE -->|Classic SPP · HC-06 D8/D9| ACT
    ACT -.->|structured 7-byte A6 진단| GW
    ACT -.->|structured 7-byte A6| PHONE
    ESP -->|상태·실행 ACK HTTP| API
    API -.->|WIFI 또는 legacy fallback 명령 HTTP| ESP[ESP-01 companion]
    ESP <-->|CRC UART D5/D6| SENSOR[SensorUno + RFID + DHT22]
    SENSOR <-->|I2C 0x08| MOTOR[MotorUno]
    SENSOR <-->|I2C 0x09 제어·명령 mailbox| ACT
    MOTOR --> DRIVE[4모터 전·후진 + 라인 + 전방 HC-SR04]
    ACT --> OUTPUT[가습·제습 릴레이 + 원격 DHT 표시 LCD]
Loading

자동차 downlink는 실행 시 하나의 모드만 선택합니다.

ROBOT_COMMAND_TRANSPORT 명령 경로 receipt와 fallback
WIFI 서버 → ESP-01 /api/robot/command → SensorUno HTTP 제공이 delivery이며 Bluetooth를 사용하지 않습니다.
BLUETOOTH (legacy) 서버 → USB gateway Uno → Bluetooth → ActuatorUno mailbox exact B echo가 서버 delivery이고 7바이트 A6는 차량 링크 진단입니다. mailbox가 stale이면 차량 IP의 Wi-Fi command GET fallback을 허용합니다.
MOBILE_BRIDGE 서버 → Android 앱 → 차량 HC-06 → ActuatorUno D9/D8 [A6, sequence, revision LE32, CRC8] 7바이트 receipt만 delivery로 인정합니다. Wi-Fi command fallback은 닫혀 /api/robot/command409를 반환합니다.

세 모드 모두 실제 EXECUTING·COMPLETED는 SensorUno가 ESP-01의 Wi-Fi 상태 uplink로 보고해야 확정됩니다. MOBILE_BRIDGE 복구 latch는 같은 ALL_STOP revision의 structured receipt만으로 풀리지 않으며 SensorUno의 COMPLETED까지 필요합니다. Android 절차와 HC-06 배선은 설치 문서를 따르세요.

물리 경로는 HOME → ZONE2 → ZONE99의 직선형입니다. 구역 사이의 검은 선은 끊기지 않으며, ZONE2·ZONE99는 RFID로 식별합니다. 등록한 HOME RFID는 복귀 중 보조 도착 수단이고, 넓은 검은 HOME 마커는 보정에 계속 필요하며 RFID를 놓쳤을 때의 fallback으로 남습니다. 전체 상태 전이와 안전 조건은 아키텍처 문서에 정리되어 있습니다.

빠른 시작

이 절차는 하드웨어를 움직이지 않는 로컬 서버 데모입니다. Python 3.12와 실행 중인 MySQL 서버가 필요합니다. 먼저 설치 문서에 따라 데이터베이스와 전용 humibot 계정을 만든 뒤 서버를 실행하세요. 관리자 계정이나 데이터베이스 자동 생성 권한을 상시 운영에 사용하지 않습니다.

git clone https://github.com/oioihoihoih/mobile-humidity-control-robot.git
cd mobile-humidity-control-robot
python -m venv .venv

가상환경을 활성화한 뒤 의존성을 설치합니다.

python -m pip install -r server/requirements.txt

PowerShell에서는 로컬 MySQL 접속값을 현재 셸에만 설정하고, USB 브리지를 끈 상태로 서버를 시작할 수 있습니다.

$env:MYSQL_USER = "humibot"
$env:MYSQL_PASSWORD = "<mysql-password>"
$env:SERIAL_ENABLED = "0"
python server/server.py

브라우저에서 http://127.0.0.1:8000을 열고 다음 상태를 확인합니다.

  • /health: 프로세스와 빌드 정보
  • /ready: MySQL 연결 준비 상태
  • /logic: 실행 중인 시스템 로직 문서
  • /app: 휴대폰용 간이 화면. / 관제 대시보드와 같은 /api/dashboard 데이터를 쓰며, 지도·출동 버튼·정상 범위만 남기고 추이 차트와 시리얼 터미널은 /에 그대로 둡니다.

가상환경 활성화, 샘플 측정 전송, 펌웨어 설정과 신뢰 LAN 연결 방법은 설치·실행 문서를 따르세요.

저장소 구조

.
├── firmware/                  # 운영·진단 Arduino/ESP 스케치
│   ├── uno_robot_esp01_rfid_relay/        # SensorUno
│   ├── robot_esp01_companion/              # ESP-01 Wi-Fi·HTTP companion
│   ├── uno_line_tracker_motor_controller/ # MotorUno
│   ├── uno_humidity_module_controller/    # ActuatorUno
│   └── uno_home_rfid_registration/        # HOME UID 읽기 전용 예제
├── server/                    # Python 서버, 대시보드, 서버 단위시험
├── android/                   # HC-06 Classic SPP 모바일 브리지 앱
├── tests/                     # 3-Uno·ESP companion 프로토콜·폐루프 회귀시험
├── simulide/                  # 회로 프록시와 검증 도구
├── scripts/check.py           # 전체 오프라인 검사 진입점
└── docs/                      # 아키텍처·설치·API·검증 문서

현재 자동차 기준 소스는 위 3개 Uno 스케치와 ESP-01 companion입니다. 그 밖의 펌웨어는 구역 센서, 업로드·배선 진단 또는 이전 실험을 위한 보조 자료이므로 파일명과 각 폴더 문서를 확인한 뒤 사용하세요.

HOME UID 등록 예제는 SensorUno의 RC522 D8~D12 배선을 그대로 사용합니다. 읽은 실제 UID는 Git에서 제외되는 robot_network_config.h에만 넣고, 예제 확인 뒤에는 반드시 SensorUno 운영 스케치를 다시 업로드해야 합니다. HOME 카드가 리더 아래에 남은 채 출발해도 이를 새 도착으로 재사용하지 않으며, HOME RFID를 등록해도 넓은 마커에서 수행하는 CALIBRATE_HOME 절차는 생략할 수 없습니다.

제어 로직 요약

기본 습도 범위는 환경 변수나 대시보드에서 바꿀 수 있습니다. 범위 아래는 HUMIDIFY, 범위 위는 DEHUMIDIFY 후보가 되며 우선순위는 다음과 같습니다.

우선순위 = (임계값 초과 폭 × 100) + 위반 지속시간(분)
  • 큰 편차가 먼저 선택되고, 편차가 같으면 오래 지속된 구역이 우선입니다.
  • 습도 정상 복귀에는 기본 2%p 히스테리시스를 적용합니다.
  • 신선한 위반 후보가 없는데 센서가 누락·stale 상태이거나 새 측정을 기다리는 중이면 ALL_STOP을 유지합니다.
  • 모든 활성 구역이 신선하고 정상일 때만 RETURN_HOME을 만듭니다.
  • 온도 범위 이탈은 경고로 표시하지만 온도 조절 임무를 생성하지 않습니다.

안전 및 네트워크 경계

  • 이 시스템은 격리되거나 신뢰할 수 있는 로컬 LAN의 교육용 프로토타입입니다. HTTP는 암호화되지 않으므로 인터넷에 직접 노출하거나 포트 포워딩하지 마세요.
  • MOBILE_BRIDGE에서는 서로 다른 32자 이상의 CONTROL_API_TOKEN, ROBOT_STATUS_TOKEN, SENSOR_INGEST_TOKEN이 각각 앱 제어, 차량 상태, 구역 측정을 보호합니다. 비밀은 Git에서 제외되는 로컬 파일에만 두고 차량 companion과 ZONE2·ZONE99를 토큰 헤더와 함께 다시 플래시합니다.
  • 세 Bearer 토큰은 전송 암호화나 장치별 서명·재전송 방지를 제공하지 않습니다. 평문 HTTP는 격리된 LAN에서만 사용하고, 그 밖의 환경에는 HTTPS 종단을 먼저 구성하세요.
  • 모터, 펠티어, 팬의 전류를 Uno나 브레드보드로 공급하지 마세요. 별도 전원, 공통 GND, 퓨즈, 정격 드라이버와 방열 대책이 필요합니다.
  • 첫 시험은 바퀴를 띄우고 고전력 부하를 분리한 상태에서 진행하세요. 소프트웨어 ALL_STOP은 물리 비상 정지 스위치를 대체하지 않습니다.

문서

버그나 기능 변경을 제안할 때는 재현 조건, 영향을 받는 보드·API, 실행한 검사 결과와 실물 여부를 함께 남겨 주세요. 검증되지 않은 실차 동작은 완료된 기능으로 표현하지 않습니다.

라이선스

팀의 오픈소스 라이선스가 아직 결정되지 않아 현재 LICENSE 파일이 없습니다. 공개 저장소라는 사실만으로 재사용·수정 권한이 부여되지는 않습니다. 팀 합의 후 목적에 맞는 라이선스를 선택하고 이 절을 갱신해야 합니다.

About

Three-Arduino mobile humidity-control robot with RFID navigation, distributed sensing, Python/MySQL control, and a real-time dashboard.

Topics

Resources

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages