이름뭐로짓지

국민대 자율주행 경진대회 예선(이자 마지막..)

Woouuk — Wed, 24 Jun 2026 15:33:01 +0900

자율주행 경진대회에 5명이 한 팀으로 출전했다.

예선을 붙고 나서 본선을 보는데, 예선은 크게 두 가지 미션으로

1. 국민대 시뮬레이터에서 정해진 코스를 미션을 수행하며 빠른 시간 안에 완주

2. 자율주차 시스템을 디자인하여 보고서 제출

이다.

예선에 대해 말해도 되는지 몰라 시뮬 코스와 미션에 대해 간략하게 설명하겠다.

1. 먼저, 라바콘으로 이루어진 길을 따라 코스까지 도달한다.

2. 코스는 일방 통행의 2차선으로, 코스에 도달하여 잠시 길을 따라 전진 후, 정지선과 신호등 구간을 만난다.

3. 신호등은 빨간불, 좌회전, 초록불 신호로 구성되어 좌회전 시 지름길로 갈 수 있다.

4. 단, 랜덤으로 경찰차가 지름길로 가는 길을 막고 있을 수 있다. 지름길에는 아무런 장애물이 없다.

5. 직진을 하게 되면 S자 코스가 나오고, 도중에 보행자가 가로지른다.

6. 당연히 보행자는 멈추거나, 가로질러서 부딪히면 안되고, S자 코스를 지나면 차량 두 대가 기다리고 있다.

7. 차량 두 대는 2차선을 막고 있으나, 두 대가 함께 전진을 시작한다.

8. 이 두 대는 서로 속도가 다르다. 속도가 느린 차를 추월해서 진행해야만 한다.

9. 이 부분을 지나면 지름길에서 빠져나오는 부분과 만난다.

10. 직후에, 어린이 보호구역이 나와 차량 속도가 15 이하로 제한된다.

11. 이후 맨 처음 라바콘을 지난 시점의 코스를 다시 만난다.

12. 이렇게 총 두 바퀴 반을 돌면 완주

기본적으로 국민대에서 제공하는 ROS2 기반의 아키텍처가 있다(cam, pointcloud, imu 패키지 등). 이를 따라서 만들었다.

맨 처음, 감지할 수 있는 원시 데이터들과 우리가 주행해야 하는 코스 및 미션을 토대로 필요한 패키지들(서브시스템들)을 명세하여 인터페이스를 정의하였고, 다 같이 "판단부"를 어떻게 만들지 정했다. (yolo 객체감지나 차선 감지가 워낙 오픈소스가 잘 되어 있어 오히려 판단이 key라고 생각했기 때문이다.)

판단부는 최근에 구현해 본 경험이 있던 state_machine으로 만들었다.

state machine

그리고 위의 판단부 중 상태머신 패키지를 시작으로 lidar 패키지, vision 패키지, 경로 생성 패키지, 컨트롤 패키지로 설계를 나누었고, 나는 이 중 상태머신과 컨트롤 패키지 알고리즘 설계 및 구현을 담당했다.

대회에서 제공해주는 imu 패키지 등이 파이썬 기반이라 상태머신도 파이썬으로 만들었다.

단, 제어부는 cpp로 구현하였고, ROS2 기반으로 구현된 stanley 오픈소스를 찾아 만들었다.

https://github.com/Team-Stier/kookmin-Stier1-src/tree/main

(현재 해당 github는 private으로 되어있다.)

중간에 상태머신을 구현하며, 한 바퀴 돌고 끝이 아니기 때문에 다음 상태로 전이하며 기존 상태로의 전이를 판단한 bool 값 등의 파라미터들을 초기화해줘야 하는 문제가 있었다. 이를 제외하고는 SW 규모가 크지 않고, 초반에 명세서를 만드는 데에 공을 많이 들여 비교적 수고가 적었다. (또한 내가 맡은 파트가 크게 신경써야 할 부분이 없었던 것 같다. 제어는 수신/발행 인터페이스와 그 로직이 거의 정해져 있고, 상태머신 또한 실차 테스트에서 파라미터 수정 정도뿐이 없기 때문이다.)

다행히 예상한 대로 코드는 잘 흘러갔다.

상반기에 자율주행 직무로 나가고 싶어 커피챗도 해보고, 교육도 듣고 했지만

알아볼수록 현재 나의 상황으로는 모빌리티 직무를 맡기에는 전망이 좋지 않다는 판단이 서 이번 국민대 자율주행 대회 참가를 마지막으로 더 이상 자율주행 SW를 개발할 일은 없을듯 하다. 또한 이 대회를 참가하는 도중, ax에도 관심이 많아 skala에 지원하였는데

감사하게도 나를 붙여주셔서 다음 글은 skala 활동이 될 듯 하다..! 자율주행 안녕 ㅠ

자율주행 개발일지 04

Woouuk — Sun, 31 May 2026 20:15:11 +0900

또 다시 문제가 발생했다!! ㅎㅎ,

기본적으로 pi0-FAST는 CE로 출력을 뽑는데, 이게 fine-tuning하면서 출력 시 10개의 waypoint가 아닌, 하나의 waypoint로 출력되는 문제가 발생했다..! (근데 왜 앞전의 poc 단계에서는 10개를 뽑았을까? 이건 도저히 모르겠다,, 나중에 교수님께 여쭤보던가 해야지. 혹시 아는 분 계시면 댓글좀..)

위와 같이 출력된다..

그래서 부득이하게 pi0.5로 전환했다. 코드 다시 짜기 힘들다,,

이후 이번에는 poc 단계에서 10개의 waypoint가 찍히는 것을 확인하고, 1000개의 에피소드를 필터링해 각 앞의 2hz씩, 약 38프레임씩 총 38000 프레임을 10epoch 학습시켰다. 소요시간은 무려 30시간..! 가난한 학생은 어쩔수 없지 싶다.

그래서 하루 정도 휴식 시간을 갖기로 하고, 돌아와서 확인한 결과는,

실망스러웠다.. ㅠㅠ

위와 같이 궤적을 어느 정도 잘 추론한 경우도 있었지만 (최우측 그래프는 좌우를 좀 더 벌려놓은 것이다.)

이렇게 trajectory를 전혀 예측하지 못한 경우도 있었다.

데이터들을 쭉 살펴보며 무슨 차이가 있나 봤더니 로봇 팔을 학습시킨 것을 생각했을 때, 특정 에피소드의 instruction을 넘겨주면. 예를 들어 "두 팔을 들어 컵을 집어라 "라고 했을 때 만약 camera image 상 두 팔을 이미 든 상태라면 instruction에서 '두 팔'의 가중치를 낮게 주게 된다. 이런 식으로 출력인 action을 chunk 형태로, 사이클마다 주게 될 것이고 이에 맞게 로봇이 action을 취하는 것이다.

하지만 어쩐 이유에선지 위의 추론하지 못한 상황을 예로 들면 "직진한 후 우회전해라"에서 이제 우회전해야 하는 상황인데, '직진한'에 낮은 가중치를 주지 못한 것으로 보인다. 그래서 정말정말 마지막으로, 각 에피소드를 앞의 2hz씩 자르는 것이 아닌 1000개의 에피소드의 시작하는 첫 프레임만 가지고, 1000개의 데이터로 학습시켜보기로 했다.

-> 학습 결과

큰 변화는 없었다. 아니, 애초에 에피소드 index가 전혀 다른 상황이 아니라 연속적인 주행에서 촬영한 데이터셋인듯 하다.

그래서 앞전의 결과와 거의 동일하므로, 따로 결과사진을 올리진 않겠다.

다만 Loss는 줄어들었는데, minADE와 minFDE가 전혀 줄어들지 않는다. 아무래도 내가 설계한 학습 파이프라인 자체가 collapse를 유발하는 형태로 보인다. 이를 어떻게 고치면 좋을지는 좀 더 딥하게 아는 분들의 자문이 필요할 듯 해서, 교수님께 자문을 구하고 와야겠다..

우선 pi0 모델을 사용하여 차량의 미래 주행 궤적을 예측해내는 프로젝트는 여기서 마치도록 하겠다.

이 프로젝트를 통해

- 데이터 전처리와 정제 작업의 중요성

- 데이터를 시각적으로 처리하고 남겨두는 것

- 입력값과 출력값의 관계의 정합성의 중요성

- poc 단계의 중요성

에 대해 깨달았다. 뭔가 하다보니 좀 더 학구열이 생기는데, vla 모델을 좀 더 깊게 파보고 다시 학습시켜보도록 하겠다.

--- 추가 업데이트

codex와 씨름한 결과 이렇다고 한다.

전제가 일부 잘못됐고, 현재 세팅의 pi0.5는 waypoint predictor로 거의 "평균 궤적"을 내는 상태이다.

train mean trajectory baseline on val을 보면, ADE = 10.97, FDE = 22.98

최종 모델의 1250 step(마지막 스텝)을 보면 ADE = 10.97, FDE = 21.07

zero-baseline: ADE = 50.27, FDE = 93.66

즉, 모델은 zero보다는 훨씬 낫지만 train set의 평균 baseline과 거의 동일하다. 그래서 로스는 감소했지만 FDE와 ADE는 줄지 않는 것.

모델이 조건부로 장면을 읽고 궤적을 잘 예측한다기 보다, 대충 앞으로 8~90m를 가는 평균 패턴을 학습한 쪽에 가깝다,,

이런 일이 생긴 이유로는

1. loss와 metric이 서로 다른 vector이다. (다른 공간을 본다)

학습 loss는 quantile-normalized된 [10, 32] action denoising/regression loss인데 나는 [x, y] waypoint를 32차원에 각각 반반씩 넣었고, 추론 때 다시 평균을 냈다. 이 구조에서는 loss가 줄어도 실제 ADE/FDE가 줄지 않을 수 있다. 실제로, action_replica_std_mean은 12.63 -> 2.09로 크게 줄었다. 즉, 32개 replica channel consistency는 좋아졌으나, waypoint 위치 정확도는 별로 안 좋아진 것.

2. 평균으로 수렴하기 쉬운 문제이다.

waypoint 예측은 장면/route ambiguity가 크다. MSE류 loss는 불확실할 때 평균 궤적을 선호한다.(즉, 불확실해서 평균 궤적으로 수렴했다는 것..) 최종 예측의 final waypoint 분산도 traget보다 작다. traget final std는 대략 [22.2, 23.7]인데 prediction final std는 [12.0, 11.2]이다. 출력이 덜 다양하고 평균 쪽으로 눌린 상태인 것..

3. train/val 분포가 다르다. -> 이것도 중요해보인다,, 데이터 전처리에서 중요해보임!

train은 각 에피소드 첫 프레임 1000개만 사용했다. 그런데 val은 100개 에피소드에서 2Hz로 뽑은 3800개, 즉 중간 frame이 대부분이다. 첫 프레임만 보고 배운 모델을 주행 중간 frame들에 평가하면 평균 궤적으로 버티는 쪽으로 가기 쉽다.

4. minADE/minFDE 이름도 지금은 약간 오해의 소지가 있다. (?)

현재 num_sample = 1이라서 minADE/minFDE는 ADE/FDE와 같다. 여러 궤적 샘플 중 best를 고르는 일반적인 minADE/minFDE가 아니다.

즉, 현재 pi0.5 + 32D 반복 action encoding + first-frame-only 1000개 + normalized loss 조합은 waypoint 예측에 적합하지 않다. 지금 결과는 모델이 쓸만하거나를 판단하기보다, 평균 baseline에 수렴했다고 봐야 한다..

SVM

Woouuk — Wed, 27 May 2026 20:04:42 +0900

https://velog.io/@dkim1540/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B3%B5%ED%95%99-Objectorientation

소프트웨어 공학 - Object_orientation

OOT?객체지향(object orientation)에는 4가지 키워드가 있다.등장 배경HW의 부품처럼 SW도 modulization을 통해 각 모듈이 독립적으로 동작하도록 설계전체 기능을 모듈 단위로 분해하고각 모듈의 인터페이

velog.io

velog에 작성해두었다.

객체지향 설계

Woouuk — Wed, 27 May 2026 20:04:12 +0900

https://velog.io/@dkim1540/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B3%B5%ED%95%99-Objectorientation

소프트웨어 공학 - Object_orientation

velog.io

velog에 작성해두었다.

K-means

Woouuk — Wed, 27 May 2026 20:01:04 +0900

https://velog.io/@dkim1540/K-means-%EC%8B%A4%EC%8A%B5

K-means 실습

K-means앞선 KNN은 라벨이 있는 상태에서 새로운 데이터의 위치를 찾는 분류 모델이었다.K-means는 라벨이 없는 상태에서 데이터를 정해진 개수의 군집으로 나누는 비지도학습 알고리즘이다. 작동

velog.io

velog에 작성해두었다.

KNN

Woouuk — Wed, 27 May 2026 20:00:33 +0900

https://velog.io/@dkim1540/KNN%EC%8B%A4%EC%8A%B5

KNN_실습

keras dataset을 이용한 KNN 실습을 해보았다.KNN?KNN은 데이터 분류나 회귀에 사용되는 매우 직관적인 머신러닝 알고리즘이다.새로운 데이터가 들어왔을 때, 그 데이터와 가장 가까운 거리에 있는 k개

velog.io

velog에 작성해 두었다.

RNN & Seq to Seq & LSTM

Woouuk — Wed, 27 May 2026 19:59:29 +0900

RNN

앞서 이미지 처리에서 CNN에 대해 배웠다. 또한 잘 작동한다는 것을 알았다. (실습도 많이 해봤고)

그렇다면 언어 처리는 어떨까?

위와 같이 음파를 형태로 만들고, 음절 별로 구분해서 모델을 만들 수는 있을 것이다.

하지만 The sound라고 한다면, 기본적으로 이산적이고 모델에게 The까지인지 Thes까지인지 Theso까지인지 알려주기가 어렵다.

이미지 내에서는 기본적으로 '순서'라는 개념이 모호하다. 앞선 CV를 처리하는 모델들도 이 순서라는 개념이 들어가있지 않았다.

또한 실제 우리 말에는 '맥락'이라는 것도 존재한다. 이렇듯 언어 뿐만 아니라 우리 주위에는 '순서'라는 개념이 들어간 데이터가 많은데 이러한 시계열 데이터와 같은 '순서'가 중요한 데이터들을 가지고 모델을 만들고자 나온 것이 RNN이다.

RNN 파이프라인을 도식화하면 아래와 같다. 이미지를 넣어 언어로 출력하는 모델을 상상해보자.

one-to-many RNN

one-to-many 방식이다. (many to one, many to many, one to one 전부 가능하다. 입력 벡터 대비 출력 벡터에 따른 것)

이미지를 x 벡터로 인코딩하고 이를 h(히든 레이어)로 보내 디코딩하여 I라는 글자를 추론한다.

여기서, 히든 레이어란 히든 스테이트로 만드는 레이어를 뜻하고, 히든 스테이트란, 지금까지 받은 정보를 요약해서 잠시 저장해두는 공간 정도로 이해하면 된다.

이 다음 두 번째 히든레이어로 인코딩한 뒤(이전 '순서'에 대한 정보가 있다고 보면 된다) , 다시 디코딩하여 look이라는 글자를 추론하고,,, 를 반복한다.

이때 각 인코딩 방식은 fc레이어로 생각하면 된다.(거의 fc레이어로 이루어져있다고 함)

fc레이어로 이루어져 있는 이유는, 실제 '시간'이나 '순서'에 대한 정보가 넘어가는게 중요하고 이 레이어를 지나는 과정 자체에서 뭔가를 얻고자 하는게 아니여서 그냥 단순 연산인 fc 레이어를 쓴다는 거 같다.

또한 연산량을 줄이고자 같은 레벨에서는 전부 같은 가중치를 공유한다.

만약 사전의 모든 단어(6만개)를 6만 차원의 embedding vector로 one-hot encoding한다면 출력도 자유로울 텐데, 실제로는 데이터가 너무 방대해서 줄여야 한다. 이 때 두 가지 방법이 있다.

먼저, PCA나 autoencoder로 사이즈를 줄이는 방법이다. 다만 이러한 방법은 의미가 연관된 단어끼리 비슷하게 매핑이 안된다는 단점이 있다.

그래서 a boy has 라는 문장에서 boy를 매핑한다면, 먼저 모래시계와 같은 구조에서 boy를 인코딩한 뒤, 디코딩 과정에서 일부는 a와, 다른 일부는 has와 연관지어 매핑하는 방법이 있다. (매핑 방식은 다양하다. 상황에 맞게 쓰면 됨)

좀 더 간단하게 도식화하면 아래와 같다.

t가 시간이라면, t 시간에 x 벡터가 RNN으로 넘어가며 ht가 되고, 이전 t-1 시간에 인코딩 되었던 벡터가 들어오며 h(h(t-1) + h(t)가 될 것이다. 이로부터 디코딩 과정을 거쳐 y벡터가 나온다.

새로운 상태 ht는 h(t-1)과 이전에서 넘어온 '순서'가 포함된 정보 x(t)를 어떤 가중치의 레이어에 통과시킨 값이 된다는 것이다.

여기서 activation func으로 tanh를 쓰는데, 그 이유는 글자라는 모든 값을 -1~1로 매핑하여 버려지지 않게 하기 위해서라고 한다.

Seq to Seq

여기서 좀 더 복잡하게 만든 것이 seq2seq이다. RNN의 문제는 한글을 영어로 번역한다고 했을 때 실제 입력한 글자 수와 출력 글자 수가 다르거나, 입력의 첫 단어가 번역 시 동일하게 첫 어순으로 매칭되지 않는 상황에서 성능을 제대로 내지 못한다는 단점이 있다. 그래서 기존의 RNN 자체를 many to one과 one to many 두 개의 RNN으로 이어 붙여 각각 인코더와 디코더로서 하도록 만든 모델이다.

당연히 한글 -> 벡터화의 인코딩의 가중치가 있고, 벡터 -> 영어로의 디코딩의 가중치를 각각 학습하여 성능을 더 높일 수 있었을 것이다.

학습시키는 하나의 예시를 보면 다음과 같다.

실제로 어느 정도 성능이 잘 나왔다. 셰익스피어 글을 학습시킨건 너무나도 유명하고 코딩과 같은 영역에서도 잘 만들어냈다.

하지만 아직도 여러 문제가 있었다.

너무 긴 문장을 넣게 되면 메모리를 엄청 잡아먹는다는 문제가 있었다. 또한 길이가 고정된 하나의 context 벡터로 인코딩하는 데엔 문장의 길이가 길면 한계가 있었다. 문장의 길이가 너무 길면 context vector에서 정보가 희미해지고 성능이 떨어졌다.

이를 해결하려고 단락을 나누어 학습시킨다거나 이런 방법을 썼는데, 이러다가 나온게 바로 그 유명한 attention 메커니즘이다. attention은 다음 글에서 정리하도록 하고 CNN과 RNN으로 만든 Image captioning 모델만 보여주고 다음 내용으로 넘어가겠다.

Image Captioning

CNN 모델을 가지고 context vector로 만든 뒤 이를 RNN 디코더에 넣는 구조이다.

RNN 구조를 조금 더 뜯어보면 사실 학습이 잘 안되는 구조라고 한다.(물론 이건 attention이랑 비교해서 하는 말이다.. ㅠㅠ)

동일한 가중치가 글자 수에 따라 계속 곱해지는 형태라 w가 계속 곱해져 값이 점점 커지게 되고, 이를 잡아주기 위해 activation func으로 tanh를 쓸 수밖에 없다.(LeRU 안쓰는 이유..)

그래서 나온게 LSTM이다.

LSTM

LSTM은 Long Short Term Memory로, 흔히 우리 인간의 뇌를 생각했을 때 장기기억 어쩌구~ 하는거를 본따 만들었다고 한다. 이 RNN의 구조를 일부 그대로 채용하고 있는데, 도식을 보면서 설명하겠다.

i,f,o,g는 스위치이다. on/off 스위치라고 생각하면 된다. 시그모이드 함수를 거쳐 on/off 여부를 결정한다.

g는 우리가 앞서 배운 그 RNN이다.

c가 앞서 말한 장기기억 cell인데, 수식을 보면 저 식의 결과를 토대로 f,c 식에서는 장기기억을 얼만큼 지울지 정하고, 뒤의 i,g에서 현재 정보를 쓸지 말지를 정한다고 한다.

h는 히든 스테이트로 이 장기기억 셀 c를 얼마만큼 꺼내쓸지 결정하는 구조이다.

사실 진짜 포인트는 '내부 구조가 더 중요해졌다'는 것이다. CNN에서도 복잡하면 기울기 소실 문제가 있어 학습이 되지 않았다. 그래서 skip connection(resnet)으로 해결하였다. 얘도 같은 원리로 RNN에서 발전된 형태인 것이다. 다음 시간엔 개인적으로 ML이 대중적이게 되는데 큰 역할을 한, ML의 꽃이라 생각하는 attention에 대해 알아보겠다.

자율주행 개발일지 03

Woouuk — Wed, 27 May 2026 18:31:42 +0900

pi0-FAST 모델 학습 결과 ADE/FDE가 6점대에서 2점대 중반까지 내려왔다. 하지만 마냥 좋지 않았다..

html 기반 visualized한 첫 학습 결과

전방에 장애물이 많으면 값이 튀는걸 볼 수 있다.

로스는 성공적으로 떨어졌다. 하지만 데이터 전처리 과정에 문제가 있어 제대로 학습하지 못했다,,

바로 target인 waypoint가 gps 절대좌표 상의 waypoint였고, 당연히 로컬 waypoint로는 추론이 불가능했던 것.

(보면 GT와 PRED 값의 시작점이 많이 벌어져있다. 절대좌표 vs 상대좌표이기 때문)

또한 실패 원인으로 input data로 [전방 이미지, instruction, waypoint] 세 개를 주고, 데이터 셋도 적은 에피소드에서 동일한 상황으로 그 외 메트릭들을 filtering한 것이 크다고 생각했다.(유연하게 적용하지 못할 거니까 생각해보면 당연하다. 수학 문제도 새로운 유형을 많이 연습하지 않으면 풀지 못하지)

poc 단계였어도 episode 하나를 정해 프레임을 잘라 학습시켰는데 이는 무모했던 것 같다,,

그래서 데이터 명세와 전처리의 중요성을 실감하고 이를 제대로 잡으려 한다.

기존 실패 원인 분석들 ㅠ

먼저 LeRobot yaaki-v3 dataset의 column들을 보면 아래와 같다.

observation.* : 모델 입력 후보
- speed: ego 속도(단위 따로 없음)
- heading: 차량의 진행 방향(0~360 범위)
- heading_error: (기준 경로 대비 차량 heading 오차, 0.2인 값들이 많아 radian일 수 있음)
- hp_loc_latitude: 고정밀 위치 latitude
- hp_loc_longitude: 고정밀 위치 longtitude
- hp_loc_altitude: 고도
- acceleration_x: 촤량 좌표계 x축 가속도로 전후방향
- acceleration_y: 좌우방향
  - 여기서부터는 환경상태 컬럼
- state.lanes: 차선 수
- state.road: 도로 타입(고속도로 등)
- state.surface: 노면(아스팔트, 흙 등)
- state.max_speed: 제한속도(string 값임.. 왜지?)
- state.precipitation: 강수량, 강수 강도 계열
- state.conditions: 날씨 상태(clouds, clear, rain, snow)
- state.lighting: 조명 상태(day, dawn, dark)
  - 여기서부터는 waypoints
- state.waypoint: shape [10, 2]
- readme 설명 상 future waypoints는 openstreetmap graph에 snap된 미래 경로점
- longitude, latitude로 되어있음. (위의 고정밀 위치에서 이 값을 뺀 값을 상대 경로로서 예측하게 주면 될 거 같음)
- [waypoint_abs_lonlat -> ego position 기준 local ENU 좌표 -> ego heading 기준 rotate] - gpt 추천
- task.* : instruction/policy 조건
  - policy: student와 expert 두 종류(운전자의 숙련도로 보임)
  - instructions: 자연어 instruction
- action.* : 모방 학습의 정답 라벨
  - continuous: float 라벨로 0,1,2 세 개의 index 존재
  - 가속 페달 입력, 브레이크 패달 입력, 조향각 세 개로 존재
  - discrete: int 라벨로 기어와 방향지시등 상태
- 샘플링 메타데이터들
  - 이미지 컬럼 - 전방, 좌우 2개씩 , 후방 , 그리고 지도까지 총 7개
  - timestamp, frame_index, episode_index, index - 시퀀스 정렬/샘플링용 메타데이터

우선 모델이 다양하게 학습할 수 있게 입력 모달리티를 추가했다. waypoint 예측을 고려했을 때, ego 값으로서 speed, heading_error, acceleration_x/y, max_speed를 추가하였다.

다음으로 ego 위치 값(0, 0)부터 시작해서 예측을 시키면 초기 값은 (0, 0)으로 고정되므로 Loss가 쉬워질 수 있는 것을 고려했다. 따라서 ego로부터 한 스텝 다음부터 시작하는 t+0.5s(실제 0.5초 간격은 아님)와 같은 한 스텝 다음 지점에서 시작하는게 좋다.

비디오를 보면 한 영상당 약 최대 30초 간격, 한 에피소드의 최대 시간. 평균 간격은 약 190프레임, 19초10fps이므로 0.5s를 프레임 단위로 잡고, offset은 5프레임 단위로 5, 10, 15, 20… 으로 주고자 하였다.

또한 동일 에피소드 기준 마지막 지점에 도착 시 그 다음 값들이 없어 mask 처리가 되므로영상에서 마지막 부분은 자르고, 타겟 값만 주고자 한다. (10개의 웨이포인트를 찍으므로 5초 자름)또한 영상 평균 주기가 19초인데 정규분포를 따를 확률이 높아 5초로 통일하려 한다.

당연히 기존의 waypoint는 절대좌표였으므로 이번엔 lat과 lon, 그리고 heading 값으로 타겟 라벨을 상대좌표로 바꿔주었다.

마지막으로 filtering 과정을 거쳐 각 에피소드를 나누고, straitified sampling으로 골고루 뽑고, 이를 round-robin 방식으로 모델에게 골고루 먹여주고자 하였다.(어차피 LoRA이기 때문이다.)

아, 프레임도 각 에피소드별로 약 2hz로 제한을 두었다. 동일 에피소드에 여러 프레임이 필요없기도 하고, 무엇보다 우리 자원으로 너무 오래 걸리기 때문이다 ㅠㅠ

아래와 같이 명세를 작성하여 데이터를 추출했다.

모델 입력:

observation.images.left_forward
observation.images.front_left
observation.images.right_forward
observation.state.vehicle[0] speed
observation.state.vehicle[6] acceleration_x
observation.state.vehicle[7] acceleration_y
observation.state.max_speed
task.instructions

target 전처리용:

observation.state.vehicle[1] heading
observation.state.vehicle[3] hp_loc_latitude
observation.state.vehicle[4] hp_loc_longitude
observation.state.waypoints

필터링/샘플링용:

task.policy
episode_index
frame_index
timestamp
observation.state.road
observation.state.surface
observation.state.precipitation
observation.state.conditions
observation.state.lighting
observation.state.lanes

일단 제외:

heading_error
hp_loc_altitude
action.continuous
action.discrete
observation.images.map

데이터셋 filtering 기준

state.lanes = 1 or 2

state.road = motorway, trunk, primary, secondary, tertiary 5개

state.surface = 아스팔트 고정

max_speed = NA 제외 자유

precipitation = 자유

condition = clouds, clear 2 종류

lighting = day 고정

task.policy = expert 고정

aciont - dont care

episode_index = straitified sampling로 에피소드 추추하고 이 안에서 2~3hz 정도 프레임 추출

에피소드 당 38프레임(2hz)에서 1000 에피소드 정도

이제 이 데이터셋으로 학습을 시켜보고 오겠다.

졸업 프로젝트 11주차

Woouuk — Fri, 22 May 2026 20:13:48 +0900

저번주에 고안한 C 언어 베이스 hook과 map, 그리고 이를 검출하는 로직의 명세를 작성하였다.

구현한 팀원에게 참고하라고 명세를 작성한 터라 실제 구현은 조금 다르게 되었고, 이를 바탕으로 go기반 프로메테우스 연동 agent를 만들었다. 사실 고랭에 익숙하지 않아 대부분 codex가 만들어주었고, 설계도 구성과 환경변수 세팅, 주석처리 정도만 주로 한 거 같다.(codex 짱..!)

이번 주는 구현 위주로 하여 Git에 올린 것이 전부이다.

https://github.com/weeeeestern/NetworkDoctor

GitHub - weeeeestern/NetworkDoctor: eBPF와 Prometheus로 Kubernetes 네트워크 장애 신호를 수집하고 원인 후보를

eBPF와 Prometheus로 Kubernetes 네트워크 장애 신호를 수집하고 원인 후보를 추론하는 Incident 진단 도구 - weeeeestern/NetworkDoctor

github.com

다음 주에 마무리 발표가 있으므로 다음 글에서는 전체적인 프로젝트의 마무리 보고서를 작성하면서 어떤 프로젝트인지 정리하도록 하겠다.

VAE

Woouuk — Thu, 21 May 2026 03:16:07 +0900

저번에 GAN에 대해 정리하였다. 오늘은 이보다 좀 더 앞선 VAE에 대해 다뤄보려 한다.

VAE는 Autoencoder에 Variational을 붙인 Variational Autoencoder의 약자이다. 그렇다면 Autoencoder가 뭘까?

오토인코더는 아래와 같은 구조를 갖고 있다.

저 네모난 블랙박스를 기준으로 왼쪽 Encoding 부분과 오른쪽 Decoding 부분으로 나눌 수 있다.

왼쪽에 Input data를 넣어 encoding을 하여 더 작은 일명 'feature vector'로 만든다.

encoding layer는 conv layer로 구성된다.(정보는 정보대로 두며 크기를 줄이니까 당연히 conv 레이어일 것이다.)

이제 이 feature vector를 decoder로 다시 원상복구한다. (decoding layer는 당연히 deconv 레이어일 것이다.)

이렇게 복원하면 원본과 100% 동일하진 않지만 어느 정도 비슷한 퀄리티로 나온다고 하고, 본래 압축하는 용도로 많이 쓰였다고 한다.

이때 원본과 얼마나 차이가 있는지를 Reconstruction Loss라고 한다.

여기에서 우리가 관심있는건 encoder 부분 따로, decoder 부분 따로이다. 먼저 encoder로부터 나온 feature vector에 classifier를 달고 라벨을 준다면 어떤 의미를 capturing 하는 모델로 쓰기에 용이할 것이다.

그렇다면 decoder는?

앞서 배운 GAN을 다시 생각해보면, 무작위로 z를 뽑아 어떤 '확률 분포'를 토대로 '결과물을 생성'하였다. 그렇다면 위에서 Decoder 부분만 떼와서 feature vector z를 가지고 생성형 모델을 만들 수 있지 않을까 하는 생각이 든다.

하지만 아쉽게도 바로는 불가능하다. 우선 입력값이 한정되어 있다. 즉 무작위로부터 decoding해서 나오는 결과물이 아니라는 것.

그림으로 표현하면 아래와 같은 상황이다.

실제 출력이 가능한 입력값은 저 파란 벡터들인데, 우리가 빨간 벡터를 준다면 decoding이 불가능할 것이다.

그래서 약간의 트릭이 필요하다. 바로 위의 파란 벡터들의 분포를 정규분포로 만드는 것이다. (앞서 배운 가우시안 정규분포의 workaround 기법을 사용면 될 거 같다.)

얘를

이렇게

위처럼 정규분포로 바꿔주는 과정을 거쳐 만든 생성 모델이 VAE이다.

Mean Vector는 encoder로부터 추론한 확률분포의 중심 - (정규분포의 기준점이 될 것이다.)

Standard Deviation Vector는 이 추론한 확률분포의 분산 정도로 어느 정도 범위에서 z를 뽑을지 범위를 잡는 역할을 한다.

VAE에서 Loss function은 Reconstruction Loss에 KL divergence(mean, deviation)을 더한 형태로 이루어져 있다.

궁극적으로 위의 사진처럼 생성값이 출력될 것이다.

딱봐도 모델이 단순하다. 이런 장점이 있지만 그만큼 퀄리티가 GAN이나 diffusion과 같은 다른 생성형 모델에 비해 안좋다고 한다.

VAE의 자세한 아키텍처