ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [3차 프로젝트] 문제 해결 Q&A
    Projects/project3 2022. 6. 21. 19:12

    - 와핑 관련 

     

    1) 왜 와핑을 하고 BBOX를 쳤는지? bbox를 치고 난 다음 와핑을 하면 안 됐는지?

    -> 와핑을 하기전에 bbox를 치게 된다면 bbox도 와핑이 되는 도중에 왜곡이 되어 버립니다. 그러면 가용폭 산출을 위해 왜곡된 bbox의 좌표를 계산해주어야 문제가 추가적으로 발생해 와핑 후 객체탐지를 진행하였습니다. 

     

    18) 와핑을 직접 좌표를 찾아서 하셨는데 cctv가 추가될때마다 사람이 직접 좌표를 따서 해야하는지 아니면 자동화 할수 있는 방안을 생각해 보셨는지?

     ->현재는 직접 좌표를 찾아줘야합니다. 자동화의 경우에는 왼쪽, 오른쪽의 차선을 찾아서 화면의  구도를 파악한 뒤 한 점을 찍으면 그 점의 동일선상에 위치한 점을 직선으로 표시해주는 와핑 보조도구를 생각해 보았습니다.



    12) 와핑에 앞서 도로 추출이 자동화가 가능하다면 확장성이 용이할 것 같은데 그렇게 하지 않은 이유는? 

    -> 도로 추출 자동화를 하기 위해서는 추가적으로 도로에 대한 인공지능의 학습이 필요한데 이미 차량을 감지하는 인공지능 모델을 사용하고 있으므로 추가 했을때 알고리즘의 처리 속도가 저하될 가능성이 있습니다. 그리고 cctv 특성상 고정된 화면을 보여주기 때문에 굳이 자동화의 도움을 받지 않고 고정된 cctv 이미지를 통해 와핑 좌표의 자료를 추가하는 방식이 정확하다고 생각합니다. 다만 cctv가 움직이면서 촬영하는 것이 가능하다면 자동화에 대한 방식을 고민해볼 필요가 있다고 생각합니다.

     

    10) 직선도로가 아닐때는 어떻게 와핑을대신 다른 방식으로 사전작업을 해야 할 것 같은데?

    ->저희의 솔루션은 직선도로만을 상정하고 만들어졌기에 곡선도로를 직선으로 만들어주는 작업이 아니라면 저희 솔루션에 곡선도로는 적용하기 어려워 추가개선사항으로 생각하고 있습니다

    -> 곡선도로의 데이터 없었고 안 해봐서 정말 대답할 수 없음

     

     

    13) 와핑이 최선이었는지 ? 다른 작업은 해보지 않았는지

    -> 다른 방법으로 도로의 구도를 학습해 와핑없이 바로 가용폭을 산출해내는것을 생각해보았는데 이는 저희가 실제로 측정한 값을 바탕으로 라벨링 작업을 해서 지도학습을 시켜주어야 하는 문제라 데이터라벨링작업 이슈로 인해 하지 못하였습니다.

     

    15) 가용폭의 원근으로 인한 차이를 해결하기 위해 와핑을 하였는데, 왜곡이 심할 수도 있다고 생각한다. 와핑 외에 다른 방법을 생각하거나 시도한 것이 있는가?

     -> 이미지 상 Y축(기준점) 픽셀마다 1픽셀마다 라벨 (값을 줌)  계산이 필요, 기준 점 잡는 게 어렵다 차선도 사선으로 돼 있으니 현재로서는 와핑이 최선이다 

     

     14) cctv 이미지를 와핑해서 도로의 원근감을 없앴다고 하는데 차선이 정확히 직선으로 보이지는 않습니다. 그 원인을 무엇인지 알 수 있을까요?

    ->  원근감있는 도로  이미지 보정작업을 하면  이미지 상 좁았던 도로 폭을 임의로 넓힘으로써 직선 가용폭이 구부러 진 것처럼 보일 수 있다

    -> 평면을 기준으로 도로가 와핑되니 도로 자체에 약간의 높낮이가 있는 도로의 경우 보정 작업을 하면 가용 폭 직선이 휘어보일 수 있음 

    -모델 관련

     

    7) 차선 검출은 왜 안했는지?

    -> 차선검출을 시도해 보았었을때 (yolov5 사용) 정확도가 높게 나오지 않았고 주위의 차선과 비슷한 굵기의 선만 있다면 차선으로 인식 하는 경우가 많아서 쓰지 않게 되었습니다. 

     

    2) 세그멘테이션 왜 사용 안했는지? 정확도가 더 높아질 것 같은데?

    -> 세그멘테이션은 저희가 가지고 있는 데이터의 수로는 학습이 제대로 이루어 지지 않아 도로 산출 불가능. 추후 더 많은 데이터가 생긴다면 시도해 볼만하다고는 생각하고 있습니다.

     

    3)미검출 문제 해결이라는 거 자체가 얼마나 해결이 되었는지? 

    -> coco dataset 모델 사용시 검출율이 약 45% 이었으나 노이즈가 존재하는 모델들을 제거하여 100퍼센트로 끌어올렸습니다


    -기능 관련 

     

    3) 차선이 없는 도로는 어떻게 가용폭 검출한건지에 대해서는 생각 안 해봤는지?

     -> 가용폭 검출을 위해서는 실제 도로의 길이를 계산할 수 있도록 기준이 될만한 것이 필요합니다. 저희는 그 기준을 도로에서 가장 흔하고 통일된 폭원을 가진 차선으로 해결을 하였기에 차선이 없는 도로에서는 가용폭을 검출할 만한 다른 기준을 찾아야하는 문제가 있습니다. 현재로서는 차선만큼 좋은 기준을 찾지 못하였기에 차선이 없는 도로에서의 가용폭 검출은 힘듭니다.



    8) 중심점 좌표의 이동으로 이동중인 차를 판별한다고 했는데 정지되어있는 차량의 비박스가 움직이는것에 대해 임계치를 어떤기준으로 설정 하였습니까?

     -> 중심점이 이동하는 오차는 그렇게 크게 나타나지는 않았기에 저희가 지속적으로 모델을 돌려보면서 미세하게 움직이더라도 허용해주는 임계치 조정하였고 그 결과로 bbox의 5퍼센트 정도의 오차율 이내가 가장 안정적으로 주정차차량을 판별하였습니다.

     

    4) 성능 개선시켰을 때 어떤 점이 핵심 요소였다고 생각하는지?

     -> 기존의 코코데이터셋으로 학습시킨 모델을 사용했을 때는 원근보정 이후의 이미지 상에서 차량 인식이 어려워 가지고 있는 데이터셋으로 roboflow를 활용해 커스텀 모델을 만들어 검출률을 항샹시킨 것이 가장 큰 개선이었습니다.



    9) 차량의 회전반경에 따라 실제로 통행하지 못하는 길목에 통행가능이라고 표시되는점은 어떻게 해결할 수 있습니까

     -> 각 도로(CCTV영상)와 차량별 회전반경(커브 틀 때) 가용 폭을 고려한 통행가능 값을 설정한 후 최종적으로 통행가능 여부를 표시

     

    6) 가용폭 기준은 어떻게 선정한 것인지 ? 

     -> 이 기준을 현직 소방관님께 물어보았는데 단순 직선 통과는 가능 하지만 회전반경 및    아우트리거를 생각했을 때 6미터 필요하다는 것을 확인 따라서 이런 기준들은 추후 옵션을 넣어서 보여주면 활용 가능할 것 같다. 

     

    11) 사용한 4개 도로 영상 외에 다른 도로에 대해서 해당 서비스가 바로 적용될 수 있을 것 같은가 (일반화가 가능한가)?

     -> CCTV의 구도가 곧은 一 자라면 새로운 환경이라도 적정 수준의 성능은 보일것 같다.

    -> 새로운 환경의 각 도로 마다 최적의 와핑작업을 수행하면 잘 작동 할 것으로 기대된다.

     

    19) 도로만을 기준으로 가용폭을 산출하였는데 긴급상황이라면 꼭 도로가 아니더라도 여유공간이 있다면 차량이 통행 가능할텐데 그부분에 대한 생각은?

     -> 차선 외에도 차량이 통행 가능한 영역을 포함하여 와핑을 진행한다면 가능할 것으로 보인다. 다만 실제로 통행이 가능한 최대치를 고려하여 좌표 설정을 해야하기에 현장 실측데이터를 보다 많이 필요로 할 것 같다.

     

    15) 야간 상태에서 긴급상황이 발생해 출동시 해당 시스템을 적용시킬 수 있나요? 아니면 야간 상태에서도 적용시키기 위해 보완해야 할 점은 무엇인가요?

     -> 야간 도로 영상의 경우, 주행중인 차량의 라이트로 인한 빛 번짐이 영상에 그대로 나타나 차량 검출에 큰 장애를 겪는다. 하지만 해당 솔루션은 움직이지 않는(라이트가 들어오지 않는) 주차 및 정차 차량만을 활용한다. 그렇기에 주변 가로등의 충분한 조명, 야간 촬영에 용이한 적외선 카메라를 활용한다면 충분히 작동할 것 같다. 다만 야간 촬영 이미지를 추가로 학습시킬 필요는 있을 것 같다.


    -그 외

     

    16) 기술 상용화 부분에서 언급한 Edge Device나 통합 서버가 벤치마킹하는(또는 모티브가 되는) 컴퓨팅 연산 장치의 구체적인 예시를 알려주실 수 있나요?

    -> 상용화를 구상하며 어려움이 있었다. 하드웨어의 스펙별 성능과, 우리의 솔루션이 요구하는 리소스 및 연산의 양, 적절한 하드웨어 스펙을 몰랐기에 대략적인 금액 산정도 하기 힘들었다. 이후 멘토님들께 자문을 통해  모델 성능을 가정하여 금액을 산출할 수 있었습니다.

    통합서버 하드웨어 : Asus Workstation E900-G4

    edge device - jetson nano

     

    17) 긴급차량 길막음으로 발생하는 사회적 비용이 62억원 감소할수 있다 했는데 이는 어떤식으로 산출된 액수인지?

     -> 2019년 한국지방행정연구원에서 연구한 불법주정차의 사회적비용 추정 연구 논문을 참고하여 파악했습니다



    21)  왜 yolo 여러 버전 중 yolov5 모델 사용했는지

     ->  학문적인 관점에서는 Yolov4 가 더 가치있지만, 실용적이고 빠르게 구현하기 위해서는 Yolov4와 비교해서 빠른 속도와 용량이 낮고 성능은 비슷한 Yolv5를 사용하였습니다.

     

    22) 다른 객체탐지 알고리즘 중 왜 yolo 를 사용한건지

    -> 우리의 목표는 실시간 객체탐지라 빠른 속도로 객체를 탐지할 수 있는 기능이어야 합니다. 

    이미지 객체 탐지에는 one-stage detector와 tow-stage detector 로 나뉘는데 one-stage detector가 정확도가 빠름 . 

    정확도를 높이기 위하여 Segmentation 모델을 사용 해 보았으나 적은 데이터 수 (약 800개) 로 인해 오류가 크게 나타남 (Yolo 같은 경우는 바운딩 박스로 차량을 네모 형태로 인식하지만, 세그먼테이션 경우 차량 모양에 맞게 인식되는데 오차가 클 경우 도로 폭 산출에 오류가 심해져서 더 큰 문제가 발생된다 판단) 

     

    반응형
Designed by Tistory.