9th review meeting

[fora22]

Meeting Rule

• 회의가 끝나면 다음 Review Meeting Issue 를 올린다.
• 회의(의견을 묻거나, ~해줬으면 or ~했으면 좋겠다 싶은 거, 진행에 있는 결정 사항 의논 등) 내용이 생길 때마다 Issue에 올려서 대화한다.
  • 이 때 각 주제별로 새로 Issue를 올리고 Review Meeting Issue에 링크를 남긴다.

  • 을 쓰면 알아서 Issue와 PR에 대한 링크를 고를 수 있다.

  • 만약 Issue를 올릴 정도로 복잡하지 않을 것 같다면 Review Meeting Issue에 올린다.
• 회의 날짜까지 모든 Issue에 대하여 결론이 지어지면 해당 날짜의 회의는 없어진다.
• 만약 결론이 지어지지 않거나 Comment로 이야기를 나누기 어렵다는 생각이 들 경우 회의날짜에 회의를 진행한다.

9th review meeting

With Mentor 5th (Online)

2021/01/19 화요일 오후 11시

[fora22]

After review meeting (Offline) - 2021.01.14(화)

Image 처리 방향성에 대한 논의

선택지는 다음과 같다.

1. Server Api 를 활용
2. 존재하는 모델을 수정해서 사용(아마 Yolov4)
3. 이미지를 준비하여 모델을 직접 구현
4. 1 번으로 기능 완성 후, 2 혹은 3번 실행

   김기용 교수님 의견

   • 번호판이 정형화된 글씨를 사용해서 하는 것이기 때문에 Server Api를 사용하던 기존 기능(OCR: Image to Text)을 사용하던 성적 면에서는 큰 차이가 없을 것으로 본다고 답변해주심

     논의 결과

   • 팀원들끼리는 4번으로 합의 됐으나 졸업 작품에 한해서는 졸업 작품 담당 교수님의 의견도 들어가니 4번을 제외한 1,2,3 중에 의견을 여쭙기로 함.

Server Api 논의

한글 예제가 있는 GCP와 기존 웹, DB 서버를 사용하는 Azure 중에 어떤 것을 활용할지에 관한 논의

GCP의 장단점

• 장점
• 한국어로 된 자료가 많다
  • 블로그
  • 유튜브
  • 공식 문서
• 단점
• 기존 Web, DB 서버와 다른 플랫폼이다.
• 한이음에서 지원을 해줄지 모른다.

  Azure의 장단점

• 장점
• 기존 Web, DB 서버와 같은 플랫폼이다.
• 한이음에서 공식적으로 지원해준다.
• 단점
• 자료가 대부분 이해하기 힘든 번역 혹은 영어로 되어 있다.

  논의 결과

  멘토님 의견에도 서로 다른 플랫폼에서 서비스를 구현하면 나중에 생각치 못한 문제로 돌아올 수 있고 #73 한이음에서 GCP 지원도 불확실하니 Azure로 결정

• 한이음 문의 결과 실습장비 담당자가 현재 바뀌어서 2021년도꺼는 새로 물어봐야 한다고 함. 이메일(hanium@fkii.org)로 연락을 달라고 했으니 일단 물어보도록 진행.

Server TODO 3 분업

지연, 대원의 8th Plan (#69 , #71 )이 전반적으로 거의 똑같음 + 똑같은 일을 굳이 두명이 해야할 필요가 없기 때문에, 담당자를 지정해서 역할을 분배하는 것이 좋다고 판단!!

74 Issue 내용 참고 바람

지연

• [ ] Swagger 이용하여 api 문서 만들기(DB Design)
• [ ] Wiki정리하기 (서버 구축, DB구축, Swagger로 api문서화하기)

  대원

• [ ] fetch()를 통해 DB Insert, Update, Delete 테스트하기
• [ ] router code 쓰기
• [ ] Azure 예제 찾기 및 실습하기

추가적으로 아름에게 TODO 추가

• 프론트에서 어느 상황에 어떤 데이터가 필요하고 수정해야하는지 알 수 있도록 문서를 만들기로 함.
• 완료되면 Swagger Api 문서를 작성하면 됨.

추가 논의

• Postman의 필요성에 대해 정확히 알지 못해서 이야기를 해봐야 함

모형도 디자인 논의

• 현재 SketchUp 이라는 프로그램을 통해 STL파일로 변환 할 수 있다고 함(확실치 않음).
• STL 변환 여부를 Areum Plan 이슈 #68에 추가하기로 함.

컨베이어 벨트 논의

드라이브 스루 자료조사 #67 진행하고 생각한 문제점

• 기존의 벨트가 미는 방식은 차량과 부딪힐 수 있는 문제점이 있다.

  해결방안 논의(김기용 교수님)

• 함 같은 곳에서 앞 뒤(차량과 매장방향), 위 아래(하늘과 땅 방향)으로 움직일 수 있게 하는 것이 가장 최상 같다.
• SUV와 세단의 경우 차 문 높이가 다르니 높이 조절 기능은 필수로 보인다.
• 앞 뒤 움직이는 것은 기능을 넣는다면 센서를 통해 부딪히지 않도록 제어를 해야함
• 앞 뒤 움직이는 기능은 넣어도 되고 안넣어도 될 것 같다고 답변해주심(우선순위가 낮다).
  • 실제 고속도로 톨게이트 혹은 주차표 의 경우 차량 운전자가 거리를 계산해서 갖고오기 때문에 앞 뒤 움직이는 것은 추가 기능(우선순위가 낮다)이다 라는 것이 답변의 이유

[fora22]

@kiJiyeon @dkfma4915 회의 내용 올렸는데 추가하거나 수정해야 할 부분 있으면 comment 해주삼~ 없으면 이모티콘~

[fora22]

논의 내용

멘토님과

• [x] #77

  우리끼리

• [x] https://github.com/JEoN-Ha/Senior-Project/pull/76/files/1f7e85ecf3d7d60ee33be605fb6a11520d15a1d5#r559517027 @dkfma4915
• [x] #74 #76

[fora22]

After review meeting(Online)

Image Classification Api 최소한 호출에 대한 논의

논의점

• 차량이 언제 올지 모르니 Api를 실시간으로 호출한다.
• 차량이 왔을 때만 사진을 찍게 한다.
  • 음..어떻게??
  • 차량이 왔다는 것을 어떻게 인식하지

해결점

1. 입구에 차단바를 세운다. 차량을 멈추게 하여 거리 센서(적외선, 초음파)를 이용해 차량이 왔을 때를 인식하고 Api를 호출한다.
2. 딥러닝을 활용해 차량을 인식하고, 인식되면 Api를 호출한다.

-> 차량 번호판의 경우에도 번호판 위치가 차량마다 다르기 때문에 특정 차량 몇 대만 선정해서 잘 되게 만든는 최적화 작업을 하는 것이 좋아보인다는 멘토님 의견 https://github.com/JEoN-Ha/Senior-Project/issues/77#issuecomment-762901009

Warning Error

에러 내용

React does not recognize the customer_ID prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase customer_id instead. If you accidentally passed it from a parent component, remove it from the DOM element.

• 큰 문제가 될 에러는 아님
• 앞으로 코딩쪽으로 진로 개발할 생각이 있다면 해결해보는 것이 좋음

벨트(하드웨어) 높낮이에 대한 논의

• 모든 상황에서 잘 되는 것을 만드는 것에 집착할 필요는 없다.
• 특정한 Case에서 동작이 잘 되게 하는 것이 중요하다.
  • Service Target에서 잘 동작해도 훌륭한 프로젝트
• SUV, 혹은 세단의 Target을 정하여 높낮이 대책을 세우는게 좋을 것으로 보임 https://github.com/JEoN-Ha/Senior-Project/issues/77#issuecomment-762901009

Swagger: Api Design에 대한 논의

• 장바구니 취소 및 주문 취소에서 필요한 파라미터에 대한 논의
• 장바구니 취소에서 예외 상황 발견
  • 현재는 Order Table의 State가 1 -> 4로 변경하려 했지만 장바구니 특성상 Menu No에 따라 각자 다르게 취소할 수 있음
  • 쉽게 설명하자면 fora22가 메뉴 넘버 1: 싸이버거와 메뉴 넘버 2: 콜라를 장바구니에 넣음
  • 하지만 메뉴 넘버 1: 싸이버거를 취소함
  • Order State가 1 -> 4로 변경되어야 현재 table 구성도 상 하지만 메뉴 넘버 2: 콜라 또한 취소하지 않았음에도 불구하고 1 -> 4로 변경될 것임
• 해결 방안
  • Order State 필드를 ordertomenu table로 옮김
  • 메뉴에 따라 OrderState를 각각 주도록 함
  • 장바구니 취소는 문제 없어 보임
  • 주문(결제) 취소의 경우에도 OrderNo가 1이면서 OrderState가 2인 것들을 골라 OrderState를 5로 바꾸면 됨

앞으로의 Plan 및 진행방향

다음 Plan

• 지연 @kiJiyeon
  • Swagger 마무리
  • Wiki 정리 마무리
  • Web Deploy -> Web Server 에서도 fetch 및 Api 동작이 제대로 이루어지는지 확인 필요
• 아름 @dkfma4915
  • 현물 사이즈로 진행하는 것으로 합의 완료
  • 대원의 의견으로 이후에 Atmega128 로 구현해보도록 합의
  • 아두이노를 활용해 입구 차단바, 음식 전달해주는 벨트의 높낮이 제어
  • 현물 사이즈기 때문에 토크가 큰(즉, 힘이 센) 모터에 대해 알아보기로 함
• 대원 @fora22
  • 현재 OPIC 학원으로 인해(1월 29일 종강) 진행속도가 더딘 것을 설명, 양해 부탁함
  • Swagger를 보고 Router 코드 작성
  • Jetson에 Ubuntu 깔고 이미지 처리(Azure) 서버 Api 동작하도록 연결

진행방향

현재 Azure의 image 처리의 예제코드가 큰 문제없이 동작함 -> 아주 다행

• 하지만 서버쪽이 예상보다 시간이 많이 걸림
• 또한 하드웨어의 경우 현물 사이즈로 진행하기로 하면서 금전적인 부분에서 장애가 발생
• 따라서 지원받을 수 있을 것으로 예상되는(2월 16일: 수강신청날) 이후에 현물 작업을 실시 할 수 있을 것으로 보임
  • 그래서 하드웨어는 로직 구성부터 시작 -> 아름 Plan
• 따라서 기존 계획은 3월 초에 마무리되는 것으로 진행 계획 수정

[fora22]

확인바람~ @kiJiyeon @dkfma4915