컴퓨터비전 기반 자율주행으로 이끌었습니다.
vision
path planning (based on vision)
3개의 RGB-D 카메라가 부착된 루돌프 2세대
자율주행 킥보드 개발 초기 단계에서, ORB-SLAM 을 기반으로 돌아가는 시스템을 고도화시키는 수준으로는 현실의 문제를 풀기 어렵다고 지적했습니다. 팀이 프로젝트의 방향성을 SLAM 기반의 방법이 아닌 Vision Based 로 변경할 것을 제안했습니다. (@12/1/2020 → 2/1/2021)
자율주행 및 자율주차 킥보드 프로토타입을 개발했습니다.
메이커들과 함께 제작되고 있는 루돌프 프로토타입
사람의 도움 없이, 킥보드가 한번도 보지 못한 길 약 100m 을 주행할 수 있도록 만들었습니다. 공장 초기화된 상태의 Jetson Xaiver AGX 에 간단한 Perception 시스템을 밑바닥부터 구성하고 그 과정을 문서화했습니다. 3개의 카메라에서 작동하는 2가지 태스크를 수행하는 모델을 원활히 관리하기 위해 신경썼습니다. (@2/1/2021 → 11/1/2021)
•
문제
1.
데이터 전처리 전략 - 모델 아키텍쳐 선정 전략 - 모델 훈련 전략 - 태스크 선택 - 대상 카메라 선택 - 모델 최적화 전략 등에 의해 시스템이 수많은 모델 부산물들로 쉽게 더러워졌습니다. 생성되는 모델은 각 전략을 달리 할 때마다 심하게 분화되었고 사용중인 모델의 성능 및 학습 이력 추적도 어려웠습니다. 내가 어떤 카메라에서 사용하는 모델파일이 어떤 과정으로 생성된 모델인지조차 헷갈리는 상황에 이르렀습니다.
2.
딥러닝 인프라를 위한 투자를 할 리소스가 없었습니다. 클라우드에서 최대한 저렴하게 성능 좋은 모델을 훈련시켜야 했습니다.
3.
균일한 간격으로 차선이 그려져 있는 차도환경과 달리, 인도 환경은 그 폭이 다양하고 지면에서 가까운 카메라가 획득할 수 있는 일관된 직선 피처를 찾기가 어려웠습니다. 킥보드의 진행방향과 글로벌 맵의 각도 오차가 누적되는 문제가 있었습니다.
4.
개발 초기에는 Jetson 을 초기화해야 하는 일이 빈번하게 발생했습니다. 하지만 이때마다 과거 개발환경이 사라지는 문제가 있었습니다. 이를 복구하기 위해서는 높은 운과 많은 시간이 따라 주어야 했습니다.
•
해결
1.
빠르고 정확하게 원하는 모델을 원하는 목적으로 골라 사용할 수 있는 파이프라인이 필요했습니다. 생성된 모델들의 이름 컨벤션을 정의, 학습 로그 포맷을 만들어 기록하기, 모델 학습 메타데이터와 연결되는 json 파일을 정의해 사용했습니다.
after
after
2.
COLAB에서 제공하는 TPUv2x8 을 비롯해 선점형 Google Cloud TPU 는 퍼포먼스에 비해 그 가격이 매우 저렴했습니다. TensorFlow x Google Cloud TPU 를 이용해 딥러닝 인프라에 비용을 거의 들이지 않고 모델을 만들어냈습니다.
3.
시각장애인의 접근성을 위한 인도 위 점자블럭이 상당히 표준화되어 있으며 설치규정이 까다롭다는 것을 알게 되었고 이를 잘 이용할 수 있겠다는 생각이 들었습니다. 킥보드에 설치된 카메라의 각도를 이미 알고 있으므로 ODD를 완전평지라고 가정하면 소실선을 얻을 수 있습니다. 그 다음 ‘인도 보행 데이터셋’ 으로 학습시킨 Segmentation 모델의 출력 중 점자블럭으로 검출된 부분이 안정적으로 검출되면 2D 이미지상에서 직선을 피팅합니다. 피팅된 직선, 글로벌 지도에 나타난 인도의 방향, 소실선이 만나는 점으로부터 센서값으로부터 취득한 헤딩을 보정할 수 있었습니다.
4.
환경 구축 명령어들을 중심으로 최대한 문서화했습니다. 그리고 각 명령어의 실행에 따라 나타나는 변화와 발생했던 이슈들을 문서화했습니다.
•
성과
1.
한번 리눅스가 초기화되고 난 뒤, 환경을 다시 맞추어 과거 코드가 문제없이 돌아가도록 하는데 걸리는 시간을 비교했습니다. 2020년 11월에는 3달이 걸렸지만, 2021년 1월에는 문서화를 통해 1~3일로 줄어들었습니다.
2.
학습 파이프라인을 구동하는 데 준비하는 시간과 학습된 모델을 다운로드받고 실행하는 과정 자체에서 소비되는 시간이 단축됐습니다. 파라미터를 달리해 훈련시키고 엣지 디바이스에 포팅하는 속도를 각각 17배, 4배 단축시켰습니다.
데이터가 없는 상태에서 자율주행을 개발하는 행동의 한계를 지적했습니다.
성수동 소재의 횡단보도. 붉은 테두리로 둘러싸인 영역은 과연 ‘인도’ 일까? ‘횡단보도의 일부’ 일까? ‘차도’ 일까?
AI Hub 에 공개되어 있는 외부 데이터셋의 한계를 지적했습니다. 자율주행을 통해 Real World 문제를 풀기 위해서는 데이터를 수집할 계획부터 세워야 한다고 주장했습니다. (@11/1/2021 → 1/1/2022)
•
문제
◦
당시 디어는 6개월이 넘는 시간동안 인지시스템의 ‘성능' 을 높이는 일에 대해서 집중하고 있었습니다. 하지만 무인으로 100m 가던 것이, 1000m 이동 가능하게 된다고 하더라도 아무것도 달라지는 이 없다는 것을 자율주행팀이 인지하지 못하고 있었습니다.
•
행동
◦
“자율주행으로 얼마만큼 주행하기” 같이 설정된 성능 높이기에 초점을 맞춘 자율주행팀 마일스톤이 잘못되었다는 점을 지적하고 완전히 새로운 목표를 세워야 하는 이유를 제시했습니다. 첫 번째 이유는, 2D 이미지만 이용해서는 특정 성능 임계점을 돌파하는 것이 불가능하기 때문입니다. 두 번째 이유는, 우리가 특정 성능을 달성한다고 하더라도(심지어 100km 가 넘는 거리를 자율주행할 수 있다고 하더라도) 어차피 우리 프로덕트는 현장에 투입될 수 없을 것이기 때문입니다.
◦
자율주행의 대안으로, 원격제어(Teleoperation) 이라는 방법을 제시했습니다. 꼭 자율주행 기술이 아니더라도, 고객을 만족시키기 위해 다른 기술을 사용는 것이 부끄러운 일이 아니라고 설득했습니다. 고객이 동일한 가치를 만들 수 있는데, 그것을 달성하는 훨씬 더 쉬운 방법이 있다면 그렇게 해야 한다고 주장했습니다.
◦
한번에 완벽하게 자율주행을 만들겠다는 생각이 잘못되었음을 지적했습니다. 데이터를 확보하는 동시에 자율주행의 ODD(자율주행 기술이 동작 가능한 범위) 를 조금씩 넓혀 나가야 한다고 주장했습니다. 디어가 자율주행을 상당히 고도화시키더라도 ODD 는 매우 좁을 것이고, 자율주행 시스템을 강화시키기 위해서는 배포된 킥보드들의 카메라 센서로부터 수집된 영상이 디어 서버로 흘러들어오는 킥보드를 일단 배포해야 한다고 주장했습니다.
•
성과
◦
디어가 무엇을 하기 위해서 자율주행 기술을 개발하는 것인지 생각해보도록 만들었습니다.
◦
이 행동으로 인해 자율주행팀은 우리가 이것을 왜 하는가를 다시 고민하게 되었습니다.
◦
자율주행팀이 완전히 다른 패러다임으로 고민하도록 이끄는 데 성공했습니다.
•
배움
◦
이러한 행동으로 인해 만들어진 디어의 변화는, ‘우리가 이것을 왜 하는가' 를 돌이켜보고 문제를 다시 정의하고 목표를 다시 수립하는 과정의 일부였다고 표현할 수 있습니다. 문제 해결이 아니라, 문제 정의의 중요성에 대해 절실히 배울 수 있었습니다.
•
문제를 다시 정의하기 위해 엄청난 속도로 다양한 자율주행기업들의 방향성에 대해서 빨아들일 수 있었습니다. Autonomy 2.0 이라는 컨셉이 있다는 것을 알게 되었습니다. 배달의민족 딜리 프로젝트는 텔레오퍼레이션을 먼저 뚫어 두었다는 것, 42dot 은 데이터레이크, 테슬라는 데이터 엔진을 만들었다는 것을 알게 되었습니다. 특히 테슬라는 데이터 피드백 루프를 매우 훌륭하게 만들어 두었다는 것을 알게 되었습니다. 테슬라도 초기(2017년) 디어가 2D 데이터만 사용할 때와 완전히 동일한 문제를 겪었다는 사실을 알게 되었습니다. 그리고 오늘날에는 적극적으로 비디오모듈을 사용하고 있다는 사실을 알게 되었습니다.
연구를 넘어 상용화에 대해 깊게 고민했습니다.
상용화를 하면 원격제어+자율주행 킥보드가 사회경제적으로 얼마나 많은 가치를 만드는지, 상용화를 하기 위해서 해결해야 하는 문제는 어떤 것들이 있는지를 고민해볼 필요가 있음을 설득했습니다. 문제를 완전히 재정의할 수 있도록 고민을 촉구했습니다. 문제를 재정의하는 과정에서, 의미가 통하는 함축적인 단어로 문제를 잘게 나누어 각 단계를 추상화했습니다. (@1/1/2022 → 3/1/2022)
•
문제
◦
디어의 자율주행팀은 회사 내에서 R&D 조직으로 여겨졌습니다. 기술 개발에는 서비스화에 대한 고민이 결여되어 있었습니다. 또한 이 기술로부터 만들어질 미래가 아주 먼 미래로만 여겨졌습니다.
◦
프로젝트가 길어지고 루즈해지면서 자율주행팀이 만들 미래의 가치에 대해서 조금씩 불분명해졌습니다. 확신을 잃어가는 분위기가 있었습니다.
•
해결
◦
디어의 문제정의가 잘못되어 있었음을 간파했습니다. “자율주행 기술이 완벽히 만들어지지 않았다고 해서 우리가 가치를 만들 수 없는 것이 아니다” 라는 점을 지적했습니다.
◦
내가 커밋하는 프로젝트의 완성이 아주 먼 미래가 되기를 원하지 않았습니다. 고객의 가치를 그대로 유지하면서 앞서 언급한 기술적 한계를 우회하여 빠르게 목표에 도달할 수 있는 방법을 경영진보다 먼저 제시했습니다.
◦
자율주행팀이 만들어낼 기술이 ‘5년 뒤에 완성될 것이다’ 라고 여기는 경영진의 태도를 지적하고, 자율주행팀이 궁극적으로 하고자 하는 일까지 가는 길을 네 단계로 잘게 나누어 제시했습니다. 지금 자율주행팀이 하고 있는 일이 네 단계 중 어떤 단계에 기여를 하고 있는 것인지 판단할 수 있는 기준이 되었습니다.
◦
프로젝트를 현실로 만들기 위해 반드시 필요한 일이 무엇인지를 기준삼아 올바른 방향으로 갈 수 있도록 개발을 잠시 내려놓고 매일매일 회의시간을 할당해 팀원과 경영진에게 생각을 얼라인했습니다.
◦
맨 처음에, 이 프로젝트를 진행하기로 했었던 이유를 상기시켰습니다. 이것이 사업적으로 충분히 가치있는 일이라는 점을 지속적으로 설득했습니다. 킥보드를 떠나 자율주행팀이 어떠한 가치를 만들 수 있을지를 고민해서 먼저 제안했습니다. 기술을 떠나 프로젝트의 실현 관점에서 고민해보아야 하는 요소들에 대해서 생각을 촉구했습니다.
•
성과
◦
“지금 그러한 시도를 해 보려는 것은 STEP2 에 해당하는 일이야. 우리는 지금 STEP1 에 대한 고민을 해야 해!” 와 같이, 팀은 훨씬 원활한 의사소통을 할 수 있었습니다. 목적성을 가지고 프로젝트가 진행되기 시작했습니다. 2년간 느린 속도로 진행되던 프로젝트는 3개월만에 빠르게 실패했습니다.
◦
제가 떠남과 동시에 디어의 경영진은 자율주행 프로젝트를 언제 다시 시작해야 하고, 다시 시작하면 어디서부터 시작해야 하는지에 대해서 확신을 가지게 되었습니다.
◦
이러한 노력은 단기적으로는 프로젝트가 종료되었기 때문에 실패라고 여겨질 수 있습니다. 하지만 회사 입장에서는 1년이 넘는 시간동안 커다란 발전 없이 한발 한발 주행거리만 늘려 가던 프로젝트가 4개월만에 모든 의사결정을 마치고 마무리짓게 되도록 했다는 점에서 리소스를 정말 많이 아낀 셈이 되었습니다. 회사는 잉여 리소스로 미래의 자율주행 프로젝트를 위해 소프트웨어개발보다 더 중요한 일을 할 것이라고 약속했고, 저도 제 시간을 허비하지 않을 수 있기 때문에 충분히 성공이라고 생각합니다.
자주 받았던 질문들
머신러닝 프레임워크로 파이토치 대신 텐서플로를 사용한 이유가 무엇인가요?
1.
2019년 당시 pytorch는 프로덕션에 적합하지 않다는 여론이 있었습니다.
2.
TensorFlow가 all-in-one 프레임워크를 표방했기 때문입니다. TensorFlow는 당시 TF-TRT 같은 고수준 도구를 제공했습니다. 이를 이용하면 API 콜 한 번만으로도 TensorRT 프레임워크를 이용해 다양한 모델에 대해 최적화작업을 수행할 수 있었습니다. 이뿐 아니라 TensorFlow 생태계에는 당시 pytorch 환경에 없었던 TFLite 와 같은 도구들이 있었고(현재는 파이토치 라이트닝 등이 존재함), Google CORAL 등의 제품군(2018년 이후 업데이트가 없음)은 NVIDIA 플랫폼에서 벗어나 외장 연산장치 연결을 통해 엣지 디바이스 저전력 머신러닝 연산이 가능한 미래를 만들어줄 것이라는 희망을 심어 주기에 충분했습니다.
3.
적은 인원이 모델 선정 - 모델 최적화 - 모델 포팅까지 거대한 사이클을 모두 커버해야 하는 상황이었습니다. 이런 상황에서 연구와 모델링에 최적화된 pytorch 를 사용하면, 혹시나 있을 모델링 작업에는 매우 유용하겠지만 빠르게 제품을 개발하는 것에는 적합하지 않을 것이라고 판단했습니다.
ROS2가 아닌 ROS1을 사용한 이유가 무엇인가요?
•
당시 ROS2의 버그와 이슈가 많았습니다. ROS2 연동을 쉽게 지원하는 패키지들이 많이 없었습니다.
•
당시 NVIDIA Jetson 플랫폼을 사용했는데 2019~2020년 Jetpack은 Ubuntu 18.04 만을 지원했습니다. Ubuntu 18.04 에는 ROS2를 사용할 수 없었습니다. 그래서 ROS1 melodic 에서 python3 환경을 구성하기 위해 많은 삽질을 할 수밖에 없었습니다.
자율주행 킥보드를 만들면 사람이 탈까요?
•
왜 SLAM 기반의 접근을 포기해야 한다고 생각했나요?
•
서울시 성동구 성수동은 하루종일 차가 지나다닐뿐 아니라 보행자, 노상, 불법주차 차량, 장애물 등이 매일매일 변하고 툭하면 건물공사 도로공사를 하는 아주 ‘힙한’ 환경입니다.
•
이 상황에서 정밀지도를 만드는 일이나 이들 피처를 관리하는 일은 매우 도전적인 작업이라고 생각했습니다. 이 복잡한 상황들에 모두 대응할 수 있는 정밀지도를 만들 수 있는 기술력은 세계적으로도 유일무이하므로 저희가 가진 리소스로 도전하기 어렵다고 생각했습니다.
•
따라서 정밀지도에 의존하는 방법 대신, 인지 기술로 풀어나가야 한다고 생각했습니다.