대기열 모니터링 시스템으로 교육부로부터 표창을 받은 한국 남학생의 이야기

제가 고등학교 2016학년이었을 때(XNUMX년 XNUMX월부터 XNUMX월까지), 학교 구내식당에서 발생한 상황으로 인해 매우 짜증이 났습니다.

문제 XNUMX: 너무 오랫동안 줄을 서서 기다리는 것

어떤 문제가 관찰되었나요? 이와 같이:

배급소에는 많은 학생들이 모여서 오랜 시간(XNUMX~XNUMX분) 서 있어야 했습니다. 물론 이것은 일반적인 문제이며 공정한 서비스 계획입니다. 늦게 도착할수록 늦게 서비스를 받게 됩니다. 그러면 왜 기다려야 하는지 이해할 수 있을 것입니다.

문제 XNUMX: 기다리는 사람들의 불평등한 조건

하지만 물론 그것이 전부는 아니고, 더 심각한 또 다른 문제도 관찰해야 했습니다. 너무 심각해서 마침내 상황에서 벗어날 방법을 찾기로 결정했습니다. 고등학생(즉, 한 학년 이상 공부하는 모든 사람)과 교사는 줄을 서지 않고 배급소로 갔다. 예, 예, 초등학생인 당신은 그들에게 아무 말도 할 수 없었습니다. 우리 학교는 학급 간 관계에 관해 꽤 엄격한 정책을 갖고 있었습니다.

그래서 저와 친구들은 처음에 구내식당에 제일 먼저 와서 밥을 먹으려던 참인데, 고등학생이나 선생님들이 나타나 저희를 옆으로 밀어냈습니다. 우리 자리). 우리는 다른 사람들보다 일찍 도착했지만 XNUMX~XNUMX분 정도 더 기다려야 했습니다.

우리는 점심 시간에 특히 나쁜 시간을 보냈습니다. 낮에는 절대적으로 모든 사람 (교사, 학생, 교직원)이 식당으로 달려 갔기 때문에 초등학생 인 우리에게는 점심 식사가 결코 즐겁지 않았습니다.

문제에 대한 일반적인 해결책

하지만 신인들이 선택의 여지가 없었기 때문에 우리는 라인 뒤쪽으로 던져지는 위험을 줄이기 위해 두 가지 방법을 생각해 냈습니다. 첫 번째는 아주 일찍 식당에 오는 것입니다(즉, 문자 그대로 음식이 제공되기 전). 두 번째는 고의로 탁구나 농구를 하면서 시간을 죽이고 아주 늦게 도착하는 것입니다(점심 시작 후 약 XNUMX분 정도).

어느 정도 효과가 있었습니다. 그러나 솔직히 말해서 식사를 하기 위해 식당으로 빨리 달려가려는 사람은 아무도 없었고, 다른 사람들 뒤에 남은 찬 음식을 비우기 위해 서둘러 식당으로 달려가는 사람도 없었습니다. 왜냐하면 그들이 마지막에 속했기 때문입니다. 우리는 구내식당이 혼잡하지 않을 때 이를 알려주는 솔루션이 필요했습니다.

어떤 점쟁이가 우리의 미래를 점쳐주고, 언제 식당에 가야 하는지 정확하게 알려준다면 우리가 오래 기다리지 않아도 될 것입니다. 문제는 매일 모든 것이 다르게 나타났다는 것입니다. 단순히 패턴을 분석하고 최적의 지점을 식별할 수는 없었습니다. 우리는 식당에 상황이 어떤지 알아낼 수있는 유일한 방법이있었습니다. 도보로 거기에 도착하는 것이었고 경로는 당신이 어디에 있는지에 따라 수백 미터가 될 수 있습니다. 그래서 와서 줄을 보고 돌아와서 짧아질 때까지 같은 정신으로 계속하면 시간을 많이 낭비하게 될 것이다. 일반적으로 초등학생의 삶은 역겨워서 아무것도 할 수 없었습니다.

유레카 - 구내식당 모니터링 시스템을 만드는 아이디어

그리고 갑자기 다음 학년도(2017)에 나는 스스로에게 이렇게 말했습니다. “대기열의 길이를 실시간으로 표시하는(즉, 교통 정체를 감지하는) 시스템을 만들면 어떨까?” 내가 성공했다면 상황은 다음과 같았을 것입니다. 초등학생들은 현재 작업량 수준에 대한 최신 데이터를 얻기 위해 휴대폰을 힐끗 본 다음 지금 가는 것이 합당한지에 대한 결론을 내릴 것입니다. .

본질적으로 이 계획은 정보에 대한 접근을 통해 불평등을 완화했습니다. 그것의 도움으로 초등학생들은 자신에게 가장 좋은 것을 스스로 선택할 수 있습니다. 가서 줄을 서거나 (너무 길지 않은 경우) 더 유용하게 시간을 보내고 나중에 더 적절한 순간을 선택할 수 있습니다. 나는 이 생각에 매우 흥분되었습니다.

구내식당 모니터링 시스템 설계

2017년 XNUMX월에 객체지향 프로그래밍 과정에 대한 프로젝트를 제출해야 했고, 이 시스템을 프로젝트로 제출했습니다.

초기 시스템 계획(2017년 XNUMX월)

장비선정(2017년 XNUMX월)

풀업 저항이 있는 간단한 촉각 스위치입니다. XNUMX줄의 줄을 인식하는 XNUMX개의 방패를 XNUMX열로 배치한 방식

저는 1개의 멤브레인 스위치, ESP8266 기반의 Wemos DXNUMX 미니 보드, 그리고 에나멜 와이어를 부착할 링 클램프 몇 개만 주문했습니다.

프로토타이핑 및 개발(2017년 XNUMX월)

저는 브레드보드로 시작했습니다. 그 위에 회로를 조립하고 테스트했습니다. 재료의 수가 제한되어 있어서 발판이 XNUMX개 있는 시스템으로 제한했습니다.

C++로 작성한 소프트웨어의 경우 다음과 같은 목표를 설정했습니다.

1. 지속적으로 작업하고 음식이 제공되는 기간(아침, 점심, 저녁, 오후 간식)에만 데이터를 보냅니다.
2. 데이터를 기계 학습 모델(예: 10Hz)에서 사용할 수 있는 빈도로 카페테리아의 대기열/교통 상황을 인식합니다.
3. 효율적인 방식(패킷 크기가 작아야 함)과 짧은 간격으로 데이터를 서버에 보냅니다.

이를 달성하려면 다음을 수행해야 했습니다.

1. RTC(실시간 시계) 모듈을 사용하여 시간을 지속적으로 모니터링하고 식당에서 음식이 제공되는 시간을 결정합니다.
2. 데이터 압축 방식을 사용하여 쉴드 상태를 한 글자로 기록합니다. 데이터를 XNUMX비트 바이너리 코드로 처리하여 다양한 값을 ASCII 문자로 매핑하여 데이터 요소를 표현했습니다.
3. POST 메서드를 사용하여 HTTP 요청을 보내 ThingSpeak(분석 및 온라인 차트 작성을 위한 IoT 도구)를 사용하세요.

물론 몇 가지 버그가 있었습니다. 예를 들어, sizeof( ) 연산자가 문자열의 길이가 아닌 char * 객체에 대해 값 4를 반환한다는 사실을 몰랐습니다(배열이 아니므로 컴파일러가 길이를 계산하지 않기 때문입니다). 내 HTTP 요청에 모든 URL의 문자가 XNUMX개만 포함되어 있는 이유에 놀랐습니다!

또한 #define 단계에 괄호를 포함하지 않아 예상치 못한 결과가 발생했습니다. 그럼 말해보자:

#define _A    2 * 5 
int a = _A / 3;

여기서는 A가 3(10/3 = 3)과 같을 것이라고 예상하지만 실제로는 다르게 계산되었습니다: 2(2 * 5/ 3 = 2).

마지막으로 제가 처리한 또 다른 주목할만한 버그는 워치독 타이머의 재설정이었습니다. 나는 이 문제로 아주 오랫동안 씨름했습니다. 나중에 알고 보니 ESP8266 칩의 하위 수준 레지스트리에 잘못된 방식으로 액세스하려고 했습니다(실수로 구조에 대한 포인터에 NULL 값을 입력했습니다).

내가 디자인하고 제작한 발 보호대. 사진 촬영 당시 그는 이미 XNUMX주간의 짓밟힌 상태에서 살아남은 상태였다.

하드웨어(발판)

쉴드가 매점의 혹독한 조건에서 살아남을 수 있도록 다음과 같은 요구 사항을 설정했습니다.

• 쉴드는 항상 사람의 체중을 지탱할 수 있을 만큼 강력해야 합니다.
• 줄을 선 사람들에게 방해가 되지 않도록 방패는 얇아야 합니다.
• 스위치를 밟으면 활성화되어야 합니다.
• 쉴드는 방수 처리되어야 합니다. 식당은 항상 축축합니다.

이러한 요구 사항을 충족하기 위해 베이스와 상단 덮개에는 레이저 절단 아크릴을, 보호 층에는 코르크를 사용하는 XNUMX층 디자인을 선택했습니다.

저는 AutoCAD에서 방패 레이아웃을 만들었습니다. 치수 – 400 x 400mm.

왼쪽은 제작에 들어간 디자인입니다. 오른쪽에는 레고식 연결 옵션이 있습니다

그건 그렇고, 그러한 고정 시스템을 사용하면 실드 사이에 40cm가 있어야한다는 것이 밝혀졌고 이는 필요한 거리 (XNUMXm 이상)를 커버할 수 없었기 때문에 결국 오른쪽 디자인을 포기했습니다.

모든 스위치를 연결하려면 에나멜 와이어를 사용했습니다. 총 70m 이상이 걸렸습니다! 각 실드 중앙에 멤브레인 스위치를 배치했습니다. 측면 슬롯에서 스위치 왼쪽과 오른쪽으로 두 개의 클립이 돌출되어 있습니다.

글쎄, 방수를 위해 전기 테이프를 사용했습니다. 전기테이프가 많아요.

그리고 모든 것이 효과가 있었습니다!

기간은 XNUMX월 XNUMX일부터 XNUMX월 XNUMX일까지

시스템 사진 - 여기에 1개의 실드가 모두 표시됩니다. 왼쪽에는 전자 장치(DXNUMX-mini / Bluetooth / RTC)가 있습니다.

XNUMX월 XNUMX일 오전 XNUMX시(아침 식사 시간)에 시스템은 식당 상황에 대한 최신 데이터를 수집하기 시작했습니다. 나는 내 눈을 믿을 수 없었다. 불과 두 달 전 저는 잠옷 차림으로 집에 앉아 일반적인 계획을 구상하고 있었는데, 여기 전체 시스템이 문제 없이 작동하고 있었습니다.

테스트 중 소프트웨어 버그

물론 시스템에는 많은 버그가 있었습니다. 내가 기억하는 것은 다음과 같습니다.

클라이언트를 ThingSpeak API에 연결하려고 할 때 프로그램이 사용 가능한 Wi-Fi 포인트를 확인하지 않았습니다. 오류를 수정하기 위해 Wi-Fi 사용 가능 여부를 확인하는 추가 단계를 추가했습니다.

설정 기능에서는 연결이 나타날 때까지 "WiFi.begin"을 반복해서 호출했습니다. 나중에 ESP8266 펌웨어에 의해 연결이 설정되고 시작 기능은 Wi-Fi를 설정할 때만 사용된다는 것을 알게 되었습니다. 설정 중에 함수를 한 번만 호출하여 상황을 수정했습니다.

제가 만든 명령줄 인터페이스(시간 설정, 네트워크 설정 변경을 위한 것)가 휴식 시간(즉, 아침, 점심, 저녁 및 애프터눈 티 시간 외)에는 작동하지 않는다는 것을 발견했습니다. 또한 로깅이 발생하지 않으면 내부 루프 속도가 과도하게 빨라지고 직렬 데이터가 너무 빨리 읽히는 것을 보았습니다. 따라서 시스템이 예상되는 시간에 추가 명령이 도착할 때까지 기다리도록 지연을 설정했습니다.

감시견에 대한 찬가

아, 그리고 워치독 타이머 문제에 대해 한 가지 더 말씀드리겠습니다. 저는 "필드" 조건의 테스트 단계에서 이 문제를 정확하게 해결했습니다. 과장하지 않고 나흘 동안 내가 생각한 것은 이것이 전부였다. 쉬는 시간마다(8266분 동안) 나는 새 버전의 코드를 시험해 보기 위해 식당으로 달려갔습니다. 그리고 배포판이 열렸을 때 나는 한 시간 동안 바닥에 앉아 벌레를 잡으려고 노력했습니다. 음식은 생각도 못했어요! ESPXNUMX Watchdog님, 좋은 일을 해주셔서 감사합니다!

내가 WDT를 알아낸 방법

내가 어려움을 겪고 있던 코드 조각

Wdt-reset이 발생할 때 소프트웨어의 데이터 구조를 분석하여 컴파일된 코드(함수와 포인터 간의 상관 관계)의 ELF 파일에 액세스하는 프로그램 또는 오히려 Arduino용 확장을 찾았습니다. 이 작업이 완료되면 다음과 같이 오류를 제거할 수 있는 것으로 나타났습니다.

젠장! 글쎄요, 실시간 시스템에서 버그를 수정하는 것이 이렇게 어렵다는 걸 누가 알았겠습니까! 그런데 버그를 제거했더니 멍청한 버그인 것으로 드러났습니다. 경험이 부족하여 배열이 범위를 벗어나는 while 루프를 작성했습니다. 윽! (index++와 ++index는 두 가지 큰 차이점입니다).

테스트 중 하드웨어 문제

물론 장비, 즉 발 보호대는 이상적이지 않았습니다. 예상한 대로 스위치 중 하나가 멈춰 있습니다.

XNUMX월 XNUMX일 점심시간에 세 번째 패널의 스위치가 멈췄습니다.

위에서는 ThingSpeak 웹사이트의 온라인 차트 스크린샷을 제공했습니다. 보시다시피 12시 25분쯤에 문제가 발생했고 그 후 3번 쉴드가 실패했습니다. 그 결과 실제로 세 번째 실드에 도달하지 못하였음에도 불구하고 큐 길이는 3(값은 100*XNUMX)으로 결정되었다. 해결책은 스위치에 더 많은 공간을 제공하기 위해 더 많은 패딩(예, 덕트 테이프)을 추가했다는 것입니다.

때로는 전선이 문에 걸렸을 때 내 시스템이 말 그대로 뿌리째 뽑혔습니다. 카트와 꾸러미가 이 문을 통해 식당으로 운반되어 와이어도 함께 운반되고 닫히고 소켓에서 당겨집니다. 이런 경우 데이터 흐름에 예상치 못한 오류가 발생하는 것을 발견하고 시스템이 전원에서 분리된 것으로 추측했습니다.

학교 전체에 시스템에 대한 정보 전파

이미 언급했듯이 사이트의 데이터를 그래프 형태로 시각화하는 ThingSpeak API를 사용했는데 매우 편리했습니다. 일반적으로 저는 학교 페이스북 그룹에 제 일정에 대한 링크를 게시했습니다(이 게시물을 2017분 동안 검색했지만 찾을 수 없었습니다. 매우 이상합니다). 그런데 학교 커뮤니티인 내 밴드에서 XNUMX년 XNUMX월 XNUMX일자 게시물을 발견했습니다.

반응이 뜨거웠어요!

나는 내 프로젝트에 대한 관심을 불러일으키기 위해 이 게시물을 게시했습니다. 하지만 보는 것만으로도 그 자체로 꽤 재미있습니다. 여기에서 사람 수가 6시 02분에 급격히 증가하여 6시 10분에는 거의 XNUMX으로 떨어졌음을 분명히 알 수 있다고 가정해 보겠습니다.

위에는 점심 및 애프터눈 티와 관련된 몇 가지 그래프를 첨부했습니다. 점심시간 작업량이 거의 항상 12시 25분에 최고조에 달했다는 점은 흥미롭습니다(대기열이 다섯 번째 실드에 도달함). 그리고 오후 간식의 경우 일반적으로 많은 사람들이 모이는 것은 특징적이지 않습니다(대기열은 최대 한 판 길이입니다).

웃긴 게 뭔지 알아? 이 시스템은 아직 살아있습니다(https://thingspeak.com/channels/346781)! 이전에 사용했던 계정으로 로그인했는데 다음과 같은 내용이 표시되었습니다.

위 그래프를 보면 XNUMX월 XNUMX일에는 유입인원이 현저히 적은 것을 알 수 있습니다. 그리고 당연히 일요일이었습니다. 이 날에는 거의 모든 사람들이 어딘가로갑니다. 대부분의 경우 일요일에만 학교 운동장을 떠날 수 있기 때문입니다. 주말에는 식당에서 살아있는 영혼을 볼 수 없을 것이 분명합니다.

내 프로젝트로 한국 교육부로부터 최우수상을 받은 방법

보시다시피 저는 어떤 상이나 인정을 받으려고 이 프로젝트에 참여한 것이 아닙니다. 나는 학교에서 직면하고 있던 만성적인 문제를 해결하기 위해 내 기술을 사용하고 싶었을 뿐입니다.

그런데 프로젝트를 기획하고 개발하면서 많이 친해진 학교 영양사 오 선생님이 어느 날 급식 아이디어 공모전에 대해 아느냐고 물으셨습니다. 그러다가 식당에 대한 아이디어를 비교하는 것이 일종의 이상한 아이디어라고 생각했습니다. 그런데 안내책자를 읽어보니 프로젝트가 24월 XNUMX일까지 제출되어야 한다는 걸 알게 되었어요! 글쎄요. 빠르게 컨셉과 데이터, 그래픽을 확정해 지원서를 보냈습니다.

공모전의 원래 아이디어 변경

그런데 제가 최종적으로 제안한 시스템은 이미 구현된 시스템과 조금 달랐습니다. 본질적으로 나는 훨씬 더 큰 한국 학교에 원래의 방법(실시간으로 대기열 길이 측정)을 적용했습니다. 비교하자면, 우리 학교에는 XNUMX명의 학생이 있고 다른 학교에는 한 학급에 너무 많은 사람이 있습니다! 시스템을 확장하는 방법을 알아내야 했습니다.

그래서 저는 "수동" 제어에 더 기반을 둔 개념을 제안했습니다. 요즘 한국 학교에서는 이미 모든 수업에 식사 계획을 도입했고, 이를 엄격하게 준수하고 있기 때문에 저는 다른 "신호-반응" 유형의 프레임워크를 구축했습니다. 앞서 식당을 방문한 그룹이 줄의 길이가 일정 한도에 도달하면(즉, 줄이 짧아지는 경우) 벽에 있는 버튼이나 스위치를 사용하여 수동으로 신호를 보내는 것이 아이디어였습니다. . 신호는 TV 화면이나 LED 전구를 통해 전송됩니다.

저는 단지 전국의 모든 학교에서 발생한 문제를 해결하고 싶었을 뿐입니다. 오씨의 이야기를 듣고 더욱 마음이 굳어졌습니다. 이제 말씀드리겠습니다. 일부 대형 학교에서는 줄이 구내식당을 넘어 거리까지 XNUMX~XNUMX미터까지 뻗어 있는 것으로 나타났습니다. 심지어 겨울에도 그 과정을 제대로 조직할 수 있는 사람이 없기 때문입니다. 그리고 때로는 몇 분 동안 식당에 아무도 나타나지 않는 경우도 있으며 이는 또한 나쁩니다. 학생 수가 많은 학교에서는 식사 시간이 단 XNUMX분도 낭비되지 않더라도 교직원이 모든 사람에게 봉사할 시간이 거의 없습니다. 따라서 배급소에 가장 늦게 도착한 사람들 (보통 초등학생)은 식사 시간이 충분하지 않습니다.

그래서 서둘러 신청서를 제출해야 했지만 어떻게 하면 더 폭넓게 사용할 수 있을지 매우 신중하게 생각했습니다.

제가 XNUMX등상을 받았다는 메시지!

간단히 말해서, 저는 정부 관료들에게 제 프로젝트를 발표하도록 초대받았습니다. 그래서 나는 나의 모든 파워포인트 재능을 발휘하여 와서 발표했습니다!

발표 시작(맨 왼쪽 - 장관)

그것은 흥미로운 경험이었습니다. 저는 방금 구내식당 문제에 대한 뭔가를 생각해냈고, 어쩌다 보니 대회에서 우승하게 되었습니다. 무대에 서서도 '흠, 내가 여기서 뭐하는 거지?'라는 생각이 계속 들었다. 그러나 일반적으로 이 프로젝트는 나에게 큰 이점을 가져왔습니다. 저는 임베디드 시스템 개발과 실제 프로젝트 구현에 대해 많은 것을 배웠습니다. 물론 상도 받았죠.

결론

여기에는 아이러니가 있습니다. 의도적으로 등록한 각종 대회와 과학 박람회에 아무리 많이 참가해도 좋은 결과가 나오지 않았습니다. 그러다가 마침 그 기회가 저를 찾아왔고 좋은 결과를 안겨주었습니다.

이를 통해 내가 프로젝트를 수행하도록 동기를 부여하는 이유에 대해 생각하게 되었습니다. 내가 일을 시작하는 이유는 "승리"하거나 내 주변 세계의 실제 문제를 해결하기 위해서입니까? 귀하의 경우에 두 번째 동기가 작용하고 있다면 프로젝트를 포기하지 말 것을 강력히 권합니다. 비즈니스에 대한 이러한 접근 방식을 사용하면 도중에 예상치 못한 기회를 만날 수 있으며 승리해야 한다는 압박감을 느끼지 않을 것입니다. 주요 동기는 비즈니스에 대한 열정이 될 것입니다.

그리고 가장 중요한 것은 괜찮은 솔루션을 구현했다면 즉시 현실 세계에서 사용해 볼 수 있다는 것입니다. 내 경우 플랫폼은 학교였지만 시간이 지남에 따라 경험이 축적되고 누가 알겠습니까? 귀하의 애플리케이션이 전국 또는 심지어 전 세계에서 사용될 수도 있습니다.

이 경험을 생각할 때마다 제 자신이 자랑스럽습니다. 이유는 설명할 수 없지만 프로젝트를 진행하는 과정은 나에게 큰 기쁨을 안겨주었고 상금은 추가 보너스였다. 또한, 매일매일 그들의 삶을 망치는 문제를 반 친구들을 위해 해결할 수 있어서 기뻤습니다. 어느 날 학생 중 한 명이 나에게 와서 이렇게 말했습니다. “당신의 시스템은 매우 편리합니다.” 나는 일곱 번째 천국에 있었습니다!
상이 없어도 이것만으로도 제 발전이 자랑스러울 것 같아요. 어쩌면 나에게 그런 만족감을 안겨준 것은 다른 사람들을 돕는 일이었을지도 모릅니다. 일반적으로 나는 프로젝트를 좋아합니다.

이 글을 통해 내가 얻고자 했던 것

이 글을 끝까지 읽으면서 여러분이 지역 사회나 자신에게만 도움이 되는 일을 하려는 영감을 얻었기를 바랍니다. 나는 당신이 주변의 현실을 더 나은 방향으로 바꾸기 위해 당신의 기술(프로그래밍은 확실히 그중 하나이지만 다른 것도 있습니다)을 사용하도록 권장합니다. 그 과정에서 얻게 될 경험은 다른 어떤 것과도 비교할 수 없다고 확신합니다.

또한 예상하지 못한 길을 열 수도 있습니다. 그것이 나에게 일어난 일입니다. 그러니 부디 당신이 좋아하는 일을 하고 세상에 당신의 흔적을 남기세요! 단 하나의 목소리의 메아리가 온 세상을 뒤흔들 수 있으니 자신을 믿으세요.

다음은 프로젝트와 관련된 몇 가지 링크입니다.

• Instructables에 대한 참고 사항
• 프로젝트를 위해 작성한 코드
• 동일한 차트(지난 XNUMX일)
• 2017년에 공개적으로 공개한 그래프
• 여러 언급 프로젝트에 대해 뉴스 자료에

출처 : habr.com