학원에서 아두이노 일일 프로젝트로 엘리베이터 호출을 그대로 구현하는 프로젝트를 진행했다.

프로젝트 소개

User Requirements

• 오른쪽 초록 불빛은 호출 상태를 나타낸다. 호출을 한다면 불빛이 커지고, 엘베가 도착하면 불빛을 꺼야 한다.

• 왼쪽 빨간/노란 불빛은 엘베 위치를 나타낸다. 천천히 올라가는 걸 시각화 해야 한다. 엘베가 도착하면 해지해야 한다. 엘리베이터는 초록 불빛이 있는 곳(층)에서 멈춰야 한다.

• 스위치는 층에 있는 엘리베이터 버튼이다. 호출 취소도 나름의 방법으로 구현해야 한다. (나는 스위치를 2번 누르면 호출 취소로 구현했다)

System Requirements

SR_01 호출 기능

• 각 층의 엘리베이터 호출 버튼을 누르면, 엘리베이터가 해당 층으로 이동한다. * 각 층의 엘리베이터 호출 버튼은 동시에 누를 수 있다.

SR_02 호출 취소 기능

• 호출 이후, 한 번 더 호출 버튼을 누르면 호출이 취소된다.

SR_03 호출상태 표시 기능

• 각 층의 엘리베이터 호출 버튼을 누르면 호출상태 LED (초록)이 켜진다.
• 엘리베이터가 도착하거나 호출이 취소되면 호출상태 LED는 꺼진다.

SR_04 엘리베이터 이동

• 엘리베이터 시스템이 시작될 땐 1층에서 시작한다.
• 대기 중 호출이 발생하면 해당 층으로 이동한다.
• 대기 중 호출이 동시에 발생하면, 엘리베이터 위치에서 가까운 순서로 우선순위를 정한다.
• 이동 중 다른 호출이 발생하고, 대기 상태가 아닌 경우엔 다음의 규칙을 따른다:
  • 이동 방향 외에 위치한다면, 목적지로 설정
  • 이동 방향 내에 위치한다면, 경유지로 설정
• 이동 중, 호출이 취소되면 다음의 규칙을 따른다:
  • 호출 횟수가 큰 층에서 대기한다.
  • 호출 횟수가 동일하다면, 가장 가까운 층에서 대기한다.
• 대기 중인 경우, 다음 규칙을 따른다:
  • 기본적으로 호출 횟수가 큰 층에서 대기한다.
  • 호출 횟수가 모두 동일하다면, 대기 중인 층에서 대기한다.
  • 대기 중인 경우 호출이 들어온다면, 더이상 이동하지 않고 바로 호출 위치로 이동한다.
• 엘리베이터는 각 층 사이에서 대기할 수 없다.

SR_05 엘리베이터 위치 표시 기능

• 엘리베이터의 현재 위치에 해당하는 LED가 켜진다.
• 엘리베이터가 이동한 뒤, 이전 LED는 꺼져야 한다.
• 엘리베이터의 이동 속도는 1초로 한다.

하드웨어 구조

loop 함수 구성

러프하게 그렸던 Flow chart다.

• 다음 타겟 위치:last_target_floor
• 호출을 기다리는 층:up_request_list, down_request_list
• 엘리베이터 이동 방향: cur_elev_mode
• 핀 정보

위 변수들은 전역으로 선언한 뒤, 여러 함수들에서 전역 변수를 수정하는 방식으로 구현했다.

사용되는 중심 함수는 이렇다:

• 엘리베이터 위치/이동 방향, 다음 타겟 결정: find_next_floor_with_dir(),find_next_floor_with_idle()
• 엘리베이터가 이동하는 led 설정: write_elev_led()
• 유일한 input인 스위치 값 읽어오기, 층 led 설정: check_elevator_call()

프로젝트 후기

하루만 집중하면 끝날 줄 알았는데 생각보다 시간을 많이 썼다. 실제론 이틀 정도 집중해야 했다.

겪었던 어려움

1. 설계의 모호함

지금까지의 경험상, 설계를 탄탄하게 하고 구현하는 게 훨씬 효율적이었다.
특히 여러 변수가 상호작용하는 이번 프로젝트는 더더욱 그랬다.

테스트케이스를 설계 단계에서 미리 검증했어야 했는데,
"일단 구현하고 보자"는 마음이 앞서서 설계를 대충 넘어갔다.
그 결과 loop 함수에서 예상과 다르게 동작하는 함수들이 생겼다.

교훈: IoT 개발에서는 탑다운 방식으로 접근해야겠다.
loop 함수의 전체 구조를 먼저 설계하고, 그 다음 세부 함수로 내려가자.

2. 자유로운 만큼 어려운 컨벤션

스프링이나 장고 같은 프레임워크는 정해진 컨벤션이 있어서
그것만 따르면 "일단 돌아갈 것"이라는 믿음이 있었다.
디버깅 도구도 잘 되어있고...

하지만 아두이노는 너무 자유로워서 오히려 혼란스러웠다.
어디서 버그가 생긴 건지 찾기도 어렵고, 내가 짠 코드가 맞는 건지 확신이 서지 않았다.
디버깅이 시리얼로만 가능한 것도 답답한 점이었다.

잘한 점

TDD 적용

이번 프로젝트에서 처음으로 테스트케이스를 먼저 작성하고
구현하는 방식을 시도해봤다.

확실히 효과가 있었다! 테스트를 통과한 함수들은
loop에 통합했을 때도 안정적으로 작동했다.

그런데 이번엔 내가 따로 함수에 값을 넣어보며 직접 테스트해본 것이다. 앞으로 있을 팀 프로젝트에선 테스트 툴을 이용해야 할 것 같다.

느낀 점

IoT 개발이 웹 개발과는 또 다른 재미가 있다는 걸 느꼈다.
LED가 실제로 켜지고 엘리베이터가 움직이는 걸 보니
성취감이 더 컸던 것 같다.

복잡한 상태 관리와 우선순위 로직을 직접 구현하면서
알고리즘적 사고의 중요성도 다시 한번 깨달았다.

시간이 더 있었다면 실제 엘리베이터처럼 내부 버튼(목적지 선택)도
구현해보고 싶었다. 여러 대의 엘리베이터가 있는 시스템으로
확장하는 것도 재미있을 것 같다.

다음 프로젝트를 위한 다짐

1. 설계부터 탄탄하게: 상태 다이어그램을 먼저 그리고 시작하기 + 테스트케이스가 통과할지 눈으로 1차 파악하기
2. TDD 습관화: 테스트케이스를 먼저 작성하는 습관 들이기
3. 탑다운 접근: 전체 구조 → 세부 구현 순서로 진행하기

일일 프로젝트였지만 많은 걸 배운 시간이었다!