시나리오 정리본
시나리오를 짰다가 지웠다가 하다보니 소득이 있었던 시나리오까지 다 까먹을 것 같다는 생각이 들었다. 그래서 정리를 좀 해두는게 좋을 것 같아서 적어보는 유의미한 시나리오 정리 내용!
not remove case
1. 정지된 차량: 예를 들면 주차된 차량
2. 나의 속도보다 훨씬 느린 속도로 움직이는 차량들: 예를 들면 내가 30km/h 로 달릴 때, 속도가 5km/h 정도인 차량들이 줄지어 있는 경우
3. 움직이는 차량 높이보다 큰 static object 가 차량 앞에 놓인 경우
4. 매우 빽빽하게 밀집되어 이동이 없는 거대한 기차처럼 보이는 차량들
5. 높이가 비슷한 static object와 dynamic object가 혼합 되어있는 경우
6. 높이가 변화하는 구역을 지나는 경우: 예를 들면 언덕을 오르거나 내리는 상황
easily remove case
1. 듬성듬성 배치되었으며 나와 유사한 속도로 움직여 이동을 명확히 판단할 수 있는 차량들
2. 높이가 유사한 구역을 지나는 경우
※ map visualization에서 참조할 부분
carla의 semantic lidar 데이터를 뜯어보니 intesity 를 다음과 같은 semantic tag로 사용하고 있음을 발견했다.
이렇게 많아도 내가 필요한 정보는 10번 태그인 vehicles 만이 유일했다
10번 태그 vehicles 만 맵상에서 올바르게 소거 됐는지 아닌지를 일단 따지면 되므로, rviz 상에서 나타낼 때는 intensity 범위를 9 ~11로 한정했다. 그래서 앞으로 볼 화면에서 obstacle 차량은 초록색으로, 배경은 분홍색으로 나타남을 미리 언급하고 시작한다.
정지된 단일 차량 혹은 정지된 연속적인 차량들, 매우 느린 속도로 움직이는 연속적인 차량들은 맵 상에서 잘 지워지지 않는다. 전자의 경우 dynamic object가 아닌 static object로 인식되어서이고, 후자의 경우는 해당 위치에서 높이 변화가 거의 없기 때문에 static object 로 인식되는 부분이 많기 때문이다.
다음과 같은 시나리오들이 첫번째 사례에 해당한다.
scenario 3
다음 시나리오는 매우 느린속도로 움직이는 연속적인 차량들을 배치한 시나리오이다. 차량 행렬중에서도 상대적으로 밀집이 심한 중간 ~ 뒤 부분 차량들이 속도가 더 느리고, 앞 차량들은 상대적으로 속도가 빠르다.
erasor 적용 전 (초록색으로 표시된 부분이 차량)
erasor 적용 후
맨 앞에서 상대적으로 속도가 더 빠른 차량들을 제외하고는, 차량의 소거가 제대로 이뤄지지 않는다는 것을 확인 가능하다.
움직이는 차량 높이보다 큰 static object 가 차량 앞에 놓인 경우에도 차량 소거가 제대로 이뤄지지 않음을 확인할 수 있다. 다음은 그에 해당하는 시나리오이다.
scenario 1
erasor 적용 전
시나리오 1번에서의 naive map이다. 차들을 듬성듬성 배치하고, 느리게 로터리를 돌도록 설정했다. 초록색 원은 돌고있는 연속적인 차들을 의미하고, 원 좌우로 보이는 수평 방향 초록색 궤적은 rotation 영역에서 직선 코스로 이동한 일부 차들을 의미한다. 원 내부의 빨간색 구조물은 차량의 높이보다 훨씬 높은 static object 에 해당한다.
erasor 적용 후
다음과 같이 차량의 높이보다 훨씬 높은 static object 앞에 배치된 차량들은 모두 소거가 된 반면, static object 뒤에 가려진 차량들은 소거가 되지 않은 것을 확인할 수 있다. 이를 확실하게 검증하기 위해 로터리에서의 시나리오를 두어개 더 짜보았다.
scenario 4
erasor 적용 전
시나리오 4번 에서의 naive map, 차들을 로터리에 듬성듬성하게 배치시키고 속도를 최소화하여 차량을 움직여보았다.
erasor 적용 후
마찬가지로 높이가 높은 static object 뒤에 가려진 차량들은 잘 지워지지 않는 것을 확인할 수 있다.
scenario 6
erasor 적용 전
이번엔 로터리에 차량을 매우 빽빽하게 배치하고, 차량의 속도를 더욱 최소화하고 관찰!
erasor 적용 후
역시나 반대방향만 안 지워진다.
움직이는 차량과 정지된 차량이 혼합된 상태에 대해서는 이상한 현상이 발견된다. 1차선에는 움직이는 차들을 배치하고, 2차선에는 정지한 차들을 배치하고 시뮬레이션을 돌리자, static 한 차량들만 전부 지워지는 것을 확인할 수 있었다.
scenario 7
erasor 적용 전
1차선에는 느리게 움직이는 차들을, 2차선에는 완전히 정지한 차들을 배치해보았다. 그래서 1차선 차량들은 연속적인 선으로, 2차선의 차들은 불연속적인 차량 형태가 그대로 나타난 것을 확인할 수 있다.
erasor 적용 후
놀랍게도 움직이는 1차선의 차량 말고 2차선의 정지된 차량이 지워지는 것을 확인할 수 있다.
고로 이 결과를 로터리에서 결과와 혼합해서 생각해보면, 높이가 비슷한 dynamic, static objects 가 혼재되어 있는 경우 / 높이가 더 높은 static object 가 높이가 낮은 dynamic object 들을 가리고 있는 경우 잘 지워지지 않는다는 사실을 추측해볼 수 있다. 일단은 시나리오만 짜놨지만 좀 더 확실하게 하려면 여러번 실험해보면 될 것 같다.
차량이 달리다가 급정거 시나리오도 생각해봤었는데, 한 시나리오는 차량이 모두 지워지고 하나는 안 지워진다.
scenario 2
erasor 적용 전
맨 앞의 차량이 급정거한 차량이다.
erasor 적용 후
위와 같이, 특정 차량이 급 정거하고 완벽하게 정지하면 정지된 물체로 인식해서 소거가 안되는 것을 확인할 수 있다.
근데 급정거가 아니라 아래처럼 느린 속도로라도 더 이동하면 dynamic 으로 인식되어서 소거된다.
scenario 5
erasor 적용 전
erasor 적용 후
전부 소거가 된 모습
고로 차량이 빽빽하게 밀집되지 않았을 때도 지워지지 않으려면 차량이 확실하게 static 인 경우밖에 없는 듯 하다. 어찌 되었던 위 시나리오들에서 얻을 수 있는 유의미한 결과는 급정거와 같은 이유로 정지한 차량들 또한 ERASOR 에서 지워지지 않는 요소라는 것이다.
추가. 땅의 높이가 달라지는 경우에서의 erasor test
scenario 8
높이를 비교해서 장애물을 소거하는 방식이다보니까, 땅의 높이가 달라지는 경우에 차량 소거가 잘 이루어지지 않겠다는 생각이 들었다. 그래서 내가 높은 언덕에서 낮은 곳으로 내려가고, 장애물은 낮은 언덕에서 높은 언덕으로 올라오는 시나리오를 생각해보았다.
언덕은 약간 아래와 같은 느낌의 언덕이고
ego_vehicle은 그 언덕을 내려가는 방향으로, obstacle 차량은 언덕을 올라오는 상황을 생각해 보았다. (빨간색이 ego_vehicle, 무채색 차량들이 obstacle vehicle)
erasor 적용 전
마찬가지로 초록색이 장애물 차량에 해당한다. 이렇게 보니 언덕의 입체감이 안 와닿는데, intensity를 조정해서 다시 보자.
위와 같이 언덕에서 naive map을 형성했음을 확실히 해두고 가자.
erasor 적용 후
예상대로 높이가 변화하는 구간에서 차량이 안 지워진다. ego_vehicle이 이동하는 경로의 높이 변화에 따라 차량이 잘 지워지지 않는 이유는 VOI를 설정할 때, z의 범위를 거의 static 하게 두었기 때문이라 추측한다.
위와 같이 VOI 설정 과정에서 의 범위가 유동적이지 않고 고정적인 것을 확인할 수 있다.
언덕을 내려감에 따라, 땅의 높이가 지속적으로 변화하는데 VOI의 z 범위는 고정적이다. 장애물은 언덕을 올라가는 중이기 때문에 VOI에서 벗어나는 obstacle 차량 부분이 생길 것이고, 이 때문에 완벽하게 지워지지 않는 것이라는 추측이 든다.
이에 대한 해결 방안은...
1. VOI 의 정의를 바꿔볼까?
2. 높이 차이를 기반으로 차량임을 탐지하는 것도 좋은 방법인데, 그 보다 확실하게 차량임을 판단하는 방법은 없을까?
이 것들은 조금 더 생각해볼 부분 ...
Author And Source
이 문제에 관하여(시나리오 정리본), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@se0yeon00/scenario저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)