ETRI(한국전자통신연구원) 협동 로봇용 티칭 소프트웨어입니다. (소스코드는 상업용이므로 공개할 수 없는점 양해 부탁드립니다.)

개발 기간: 2020.08 ~ 2020.12
개발 환경 :
Android Studio Version : 4.0.1
Compile Sdk Version : 28
Min Sdk Version : 23
개발 언어 : Kotlin

• 명령어 드래그앤 드랍 기능 먼저 구현

• Zeplin으로 공유받은 UI와 스토리보드를 참고하여 기능 별 화면 구현.

• Splash
• IP선택
• 사용자 권한 설정
• PW 입력
• 홈 화면 (메뉴 및 최근 작업 리스트, 로그, 로봇 정보 확인)
• 실행 화면 (Unity 시뮬레이션, 프로그램 실행 확인(현재 실행중인 라인 표시))
• 교시 화면 (Unity 시뮬레이션, 로봇 좌표 값 확인, 로봇 이동 버튼 , 프로그램 편집 창, 명령어 별 값 입력 창)
• 설정 화면 (시스템, 로봇 설정, 툴, 마운트, 입출력, 통신 설정, 로그)
• 입출력 화면 (디지털입출력, 아날로그입출력)

• 프로토콜 명세서 기반으로 기능 개발

• 서버와 TCP connection setup
• IP 선택 후 로봇 연결 시 통신 초기 시퀀스에 따라 파일 데이터 수신 및 저장
• 화면 버튼 눌렀을 경우 패킷 정의에 맞춰 서버로 데이터 송신 (기능 별 상이)
• 파일을 프로그램 편집 창에서 열 경우 저장된 파일을 읽어서 명령어로 변환 후 보여줌
• 명령어로 프로그램 쓰고 저장 시 rbl 파일로 저장 후 서버로 송신
• Unity 연결, Unity 데이터 송신하여 값에 따라 로봇 움직임

• 테스트 앱 공유 및 이슈 해결
• 실제 로봇 가동 테스트

• RelativeLayout 여러 개를 중첩 시켜 놨더니 화면 동작이 느려지는 상황 발생 구글링 해보니 RelativeLayout을 많이 중첩하면 화면을 그리는 시간에 소요되는 시간복잡도가 지수시간만큼 증가. 로직상 처리하는 데에는 문제가 없었는데 UI면에서 프레임을 많이 잡아먹는 문제가 생긴 것. 따라서 LinearLayout으로 바꿈. LinearLayout으로 바꾸니까 기존에 구현한 Layout들이 깨지는 문제가 발생. 전체를 고치는 것은 시간 소요가 많이 되므로 해결 위해 ConstraintLayout으로 바꿔서 해결.

https://stackoverflow.com/questions/17493819/is-android-layout-really-exponentially-hard

• 해상도 이슈 해당 어플리케이션은 일반 핸드폰이 아닌 패드 타겟 어플리케이션. 폰은 xhdpi면 대부분 맞는 것 같은데 패드는 화면이 커서 xxhdpi로 해야 맞음. 해상도체크를 신경 써야 했음.
• Tcp통신 이슈 Tcp통신할 때 빅인디언 변환이 필요했음. 보낼때는 빅인디언으로 변환해서 보내야함. 공유 받은 c파일 객체 형식에 맞춰 객체를 생성하고 바이트화해서 서버로 송신했는데 서버 측에서 값이 제대로 읽히지 않는 현상 발생. 객체 자체를 바이트화해서 보내는 것이 아닌 객체 속 데이터들을 바이트화해서 이어 붙여 보내니까 해결.
• Cpp파일 java로 import 이슈 공유 받은 Cpp파일을 java로 import해서 쓰니 포인터에서 에러가 발생. 해결하다 시간 소요 & 이해 안가는 부분이 많아서 crc함수를 java로 새로 짜서 사용. 파일을 write한 후 저장된 파일에서 이상한 특수문자가 끼는 문제 원래는 fileoutputstream과 dataoutputstream을 썼음. 처음엔 bom문자인 줄 알고 관련 해결책을 시도해보았으나 해결되지않았음. 파일 생성하는 부분을 bufferedreader를 사용하여 구현하니 해결.
• GC이슈 Receive thread가 돌고 있는 상태에서 message thread를 보낼 때마다 생성했더니 GC문제가 발생. Thread pool을 사용하면서 calluble로 반환 값을 받는 식으로 진행.
• 멀티스레딩 이슈 멀티스레딩을 하고자 스레드풀을 썼는데 연속적으로 파일데이터가 오는 송수신 작업에서 여러 스레드가 공유데이터에 접근하여 데이터가 꼬이는 현상 발생. synchronized를 사용해서 여러 스레드가 동시에 리시브 스레드의 처리블록에 접근하는 것을 막음. 하지만 싱크로나이즈로 감싸져잇는 블록이 커서 여러 스레드를 사용해서 병렬처리하는것의 이점을 못씀. -> 개선 필요…

• TCP 통신 구현
  Teaching SW 프로젝트를 통해 소켓 통신을 이용한 실시간 양방향 통신을 직접 구현해보고 관련된 여러 고민들을 해볼 수 있었다. Tcp 통신에 대해서는 네트워크를 공부하면서 접해봤지만 직접 구현한 것은 이번 프로젝트가 처음이었다. 그동안은 Client의 요청 시에만 서버가 응답하는 방식의 Http 통신을 사용하여 구현하였었는데 실시간으로 양방향 통신을 요하는 이번 프로젝트에서는 Tcp 소켓 통신을 통하여 데이터 송수신을 처리하였다. 데이터 송신 시에 서버 쪽에서 정해놓은 패킷 형식과 프로토콜 별 구조체에 맞춰 데이터를 작성하고 보내야했는데, 서버가 C로 작성됐기 때문에 바이트 처리에 있어서 고려해야할 사항이 많았다. C로 작성된 서버는 구조체 데이터 정렬을 할 때 4바이트 기준으로 정렬을 하므로 변수 바이트 사이즈에 맞춰서 데이터를 송신할 때 부족한 바이트들을 빈 바이트로 채워서 보내야했다. 또한 데이터를 송신 할 때 Network By Order에 따라 빅인디언으로 변환하여 보내야 했다.

• 파일 구조 관리
  이전에 개발했던 프로젝트들보다 큰 사이즈의 프로젝트였기때문에 여러 파일을 관리 해야했다. 큰 사이즈의 프로젝트일수록 네이밍과 폴더화가 아주 중요한 역할을 한다는 것을 다시 한번 깨달았다. 딱 보기에 명확하게 무엇을 하는 폴더, 파일인지 와 닿아야 후에 봤을 때도 안 헷갈리고 쉽게 접근할 수 있기 때문이다. 아쉬운 점은 큰 프로젝트의 경험이 많이 없다 보니 저러한 관리를 하는 데에 있어서 일관성이 부족했다. 여기서는 이렇게 썼는데 다른 부분에서는 다른 말을 쓰고 있는 내 자신을 발견했고 나중에는 왜 이렇게 묶어 놨는지 이해 안가는 상황까지 이르렀다. 후에 정리하는 데에 많은 시간을 소요했다. + 프로젝트가 끝난 후에 clean architecture와 AAC에 대해서 공부했는데 이를 적용했으면 좀 더 깔끔하게 구현할 수 있었을 것 같다는 생각을 했다.. databinding이나 view binding, layout include등을 이용했으면 좀 더 메모리도 덜 잡아먹고 구조상으로 좋았을 것 같다.

• 레이아웃 구성
  한가지 부족했던 점은 지식 부족이었다. 디자인 리소스가 많이 들어간 화면이 많았는데 버튼에도 다양한 이미지가 들어가는 것이 많았다. 이러한 이미지들을 입힐 때 단순히 Layout에 background를 바꿔주거나 Layout을 중첩하는 일을 많이 저질렀는데 나중에 Material button이 있다는 사실을 깨달았다.

• 자료서치의 중요성
  함수의 종류와 역할에 대해서도 많이 찾아봐야 겠다라는 생각이 들었다. 기능 구현 중 서버와의 연결이 끊겼는지 주기적으로 확인해주는 것이 필요했는데, 이때 나는 timertask를 사용하여 connection condition을 체크를 하고자 했다. socket클래스에서 제공하는 isconnected라는 함수를 발견하였고 이름과 같이 연결 여부를 체크해주는 것인 줄 알고 socket.isconnected로만 체크를 해주었다. 이렇게 하니 서버와 연결이 끊어진 경우에도 연결이 되어있는 것으로 확인되는 문제가 발생하였다. 구글링 하여 자료를 참고한 결과 socket 클래스가 제공하는 isconnected 메소드는 이름만 봤을 때 소켓이 현재 연결되어 있는지 알려주는 것 같지만 소켓이 원격 호스트에 연결된 적 있는지 여부를 알려주는 것임을 알게 되었다. 따라서 소켓의 현재 연결 여부를 확인하기 위해서는 isconnected와 isclosed를 모두 확인 해주어야 원하는 바처럼 동작하였다. 개발할 때 이렇게 동작하겠지 넘겨짚어 생각하고 짠 부분은 꼭 에러가 발생한다. 단순하게 생각하지 말고 여러 자료를 찾아보고 생각을 많이 한 다음에 짜는 것이 시간을 덜 쓰는 방법이라는 생각이 들었다.

• 소통방식
  마지막으로 개발하면서 개발 지식뿐만 아니라 소통 면에 있어서 많이 배울 수 있었다. 그동안은 혼자 개발하거나 친구와 개발할 때가 많아서 소통 자체에 있어서 크게 문제 될 것이 없었다. 하지만 이번 프로젝트는 백엔드 개발자와 디자이너, 기획자 분들과의 만남이 잦았고 내가 말하고자하는 바를 명확하게 전달하지 않으면 말이 의도한 바와 다르게 전달되는 경우가 많았다. 이러한 경험을 토대로 간단 명료하게 하고자 하는 말을 전달하고, 상대방이 나의 말을 이해했는지, 내가 상대방의 말을 명확히 이해했는지 확인하는 습관을 다지게 되었다.