어쩌다보니 Logging System 을 만들고, 기록은 해놓아야 할 것 같아서, Singleton 패턴에 대해서 c++ 로 정리 하려고 한다. Singleton 이라는건 Class 를 딱 하나만 생성한다 라고 정의한다라는게 정의된다. static 으로 정의를 내릴수 있다. 그리고 객체가 복사가 이루어지면 안된다. 일단 싱글톤을 만든다고 하면, 하나의 설계 패턴이므로 나머지에 영향이 안가게끔 코드를 짜야된다. 일단 Meyer’s implementation 을 한번 봐보자.

class Singleton
{
public:
    static Singleton& getInstance();
    {
        static Singleton instance;
        return instance;
    }

private:
    Singleton(){}       // no one else can create one
    ~Singleton(){}      // prevent accidental deletion

    // disable copy / move 
    Singleton(Singleton const&) = delete;
    Signleton(Singleton&&) = delete;
    Singleton& operator=(Singleton const&) = delete;
    Singleton& operator=(Singleton&&) = delete
};

그렇다면 더확실하게 생성과 파괴의 주기를 확실하게 보기위해서는 아래와 같이 사용할수 있다.

class Singleton
{
public:
    static std::shared_ptr<Singleton> getInstance();
    {
        static std::shared_ptr<Signleton> s{ new Singleton };
        return s;
    }
private:
    Singleton(){}       // no one else can create one
    ~Singleton(){}      // prevent accidental deletion

    // disable copy / move 
    Singleton(Singleton const&) = delete;
    Signleton(Singleton&&) = delete;
    Singleton& operator=(Singleton const&) = delete;
    Singleton& operator=(Singleton&&) = delete
};

예제를 들어보자, 뭔가 기능상으로는 Random Number Generator 라고 하자. 아래와 같이 구현을 하면 좋을 같다.

class Random
{
public:
    static Random& Get()
    {
        static Random instance;
        return instance;
    }

    static float Float() { return Get().IFloat(); }
private:
    Random(){}
    ~Random();
    Random(const Random&) = delete;
    void operator=(Random const&) = delete;
    Random& operator=()
    float IFloat() { return m_RandomGenerator; } // internal
    float m_RandomGenerator = 0.5f;
};

int main()
{
    // auto& instance = Singleton::Get();   // this is good practice
    // Single instance = Singleton::Get();  // Copy this into new instance; Just want a single instance.

    float number = Random::Get().Float();
    return 0;
}

Resource

• Singleton Design Pattern
• Meyer’s Discussion
• Lecture Note
• The Cherno - Youtube

• Unreal Object 가 만들어지기 위해서는, 실제 컴파일 전에 Unreal Header Tool 에 헤더 파일 분석하는 과정에서 선행이 되며, 이 과정이 완료되면, Intermediate Folder 에 Unreal Object 정보를 담음 Meta File 이 생성 된다.
• 이 Meta 정보는 Unreal Engine이 지정한 UClass 라는, 특별한 클래스를 통해서 보관됩니다.
• UClass 에는 Unreal Object 에 대한 클래스 계층 구조 정보와 멤버 변수, 함수에 대한 정보를 모두 기록하고 있습니다.
• 하지만 단순히 검색하는 것에서 더 나아가, Run Time 에서 특정 클래스를 검색해 형(Type) 을 알아내 인스턴스의 멤버 변수 값을 변경하거나 특정 인스턴스의 member function 호출하는것이 가능하다.

Reflection

• Java / C# 과 같은 경우 Reflection 이라는 이름으로 제공
• Compile 단계에서 Unreal Object 마다 UCLass 가 생성된다면, 실행 초기의 Run Time 과정에서는 Unreal Object 마다 Class 의 정보와 함께 Unreal Object 의 Instance 가 생성됩니다.
• 이 특별한 Instance 는 Unreal Object 의 기본 세팅을 지정하는데 사용되는데, 이를 클래스 기본 객체 (Class Default Object: CDO) 라고 한다.
• Unreal Engine 에서 CDO 를 만드는 이유는 Unreal Object 를 생성할 떄마다 매번 초기화를 시키지 않고, 기본 인스턴스를 미리 만들어 놓고 복제하는 방식으로 메커니즘이 구성되어 있기 때문이다.
• 예를 들어서 복잡한 기능을 수행하는 캐릭터를 담당하고, 기능이 커진다고 했을때 굉장히 큰덩어리로 될수 있다. 이럴때 100 개의 instance 를 만든다고 가정하면, 캐릭터를 하나씩 처음부터 생성 하고, 초기화 시키는 방법보다, 미리 큰 기본 객체 덩어리를 복제하고, 속성 값만 변경하는게 더 효율적이기 때문이다.
• 정리하자면, 아래와 같이 하나의 Unreal Object 가 초기화 될 때에는 두개의 Instance 가 항상 생성 됩니다.

• 이 생성자 클래스는 Instance 를 초기화 해 CDO 를 제작하기 위해서 사용되고, 초기화에서만 실행되고, 실제 게임 플레이에서는 생성자 코드를 사용할 일이 없다.
• Unreal Engine 에서 게임 플레이에서 사용할 초기화 함수는 생성자 대신 Init 이나 혹은 BeginPlay() 함수를 제공
• 

Resource

• Class Default Object

어쩌다 보니, Jpub 에서 Python Rust 책을 리뷰 하게 되었는데, Function 과 Closure 에 대해서 이야기를 하는데, 뭔가 배웠는데 기억이 안나서 작성하게 됬다.

Lambda 함수에 대해서 잠시 이야기를 해보자. 소스코드는 모두의 코드 C++ Resource 를 가지고 왔다.

vector<int>::const_iterator iter = cardinal.begin();
vector<int>::const_iterator iter_end = cardinal.end();
int total_elms = 1;
while(iter != iter_end){
    total_elms *= *iter;
    ++iter;
}

위의 코드는 cardianl 이라는 std::vector<int> 타입이 존재 했을때, const_iterator type 으로 begin 과 end 를 각각 iter 와 iter_end 로 변수로 지정해놓았다. 그리고 while 문 에서는 total element 에다가 vector 에 있는 모든 int 을 곱해서 결국은, 벡터의 모든 원소들의 곱을 나타낸다.

이런 방법도 있지만, 조금 더 Modern C++ 로 다른 방법으로 해결한다면 Functor 를 이용할수 있다.

int total_elms = 1;
for_each(cardinal.begin(), cardinal.end(), product<int>(total_elms));

template<typename T>
struct prodcut {
    product(T& storage) : value(storage){}
    template <typename V>
    void operator()(V& v){
        value *= v;
    }
    T& value;
}

하지만 위의 코드는 product 라는 struct 를 만들고, for_each 로 while 문을 대신해서 사용된다. 하지만 struct 에 대한 operator 그리고 constructor 를 지정하므로 코드가 생각보다 길어진다. 그렇다면 어떻게 더 간단하게 만들수 있을까? 아래의 코드를 보자. 아래의 코드가 바로 lambda 로 구성한 코드이다.

int total_elms = 1;
for_each(cardinal.begin(), cardinal.end(), 
    [&total_elm](int i) {total_elms *=i; });

lambda 식은 아래와 같다.

각각의 부분은 introducer(capture), parameters, return type, statement 로 구성이 되어있다. introducer 같은 경우는 [] 안에 있는 my_mod 라는 변수를 람다 내부에서 사용할 수 있게 된다. 그리고, parameter: () 안에서는, 받을 인자를 적게 되는데 위의 예에서는 int 형을 가지고 와서 lambda 내부에서 사용할 수 있게 된다. trailing_return type 같은 경우는 따로 말하지는 않겠다. 이런 한 lambda 식을 결국은 쓰게된다. 여기서 바로 closure 과 lambda expression 에서 이야기를 하게 된다.

lambda expression 을 쓰긴 하지만, Runtime 에는 이름이 없지만, 메모리 상에 임시적으로 존재하는 Closure 가 생성이된다. 예를 들어보자. 아래의 = 옆에 부분에 lambda expression 이 있다고 가정하면, 결국 Runtime 에 closure 가 생성이되고, f 는 closure 에 대한 복사값이 될것이다. 물론 closure 를 복사하는 부분은 std::move 로 넘길수 있지만 f 가 closure 는 아니다.

auto f = [&](int x, int y){ return fudgeFactor * (x + y); };

실제 closure object 는 이 statement 가 끝났을때, 파괴된다. 즉 closure 과 lambda 의 차이는 정확하게 클래스와 클래스 인스턴스의 차이인거다. 결국 class 같은 경우는 정의를 한거고, closure 는 class 의 instance 이다. 결국 class 는 소스코드에만 존재하고, runtime 에서는 존재 하지않고, class instance 들은 run time 에 존재하게 되는것들이다.

void addDvisionFilter()
{
    auto calc1 = computeSomeValue1();
    auto calc2 = computeSomeValue2();

    auto divisor = computeDivisior(calc1, calc2);

    filters.emplace_back(
        [&](int value){ return value & divisor == 0; }
    )
}

여기에서 문제가 되는건 runtime 에서 filter 라는 컨테이너에 클로져가 local variable 보다 오래살기 때문에, divisor 의 값이 이 함수가 끝나면 사라진다. 그래서 Reference Error 가 나올것이다.

Resource

• Lambda_Closure
• Lambda Function

• Drone Software Developement 을 시작한 계기
• Drone Software & Hardware Dev Stack
• Resource

Drone Software Developement 을 시작한 계기

사실 드론을 개발한다고 하면 하드웨어 측면이나 소프트웨어 측면에 있을것 같은데, 난 embeded engineer 도 아니고 dynamics 또는 control 을 잘 알고 있는것도 아니다. 하지만 최근 Virtual Data 팀에 들어가면서 Project 를 하나 맏게 됬는데, 오! 이거로 뭔가?를 많이 할수 있다는 아이디어로 시작이 됬다. 물론 SLAM 그 어려운 학문을 하는건 정말 내 인내심을 테스트 하지만 뭔가 할수 있지 않을까? 라는 생각으로 시작을 하려고 한다.

드론 관련되서 생각보다 한국어 Resource 가 없다고 생각해서 Drone Software Dev 가 어떤게 있는지 이것 저것 찾아보고 있으면서 ROS2 도 한번 뒤집어 엎을 겸 시작을 해보려고 한다. drone 으로 뭘 할수 있을까? 의 Listing 은 아래와 같다.

Drone Software & Hardware Dev Stack

전체 그림은 아래와 같다.

Resource

• Coursera
• PX4 Documentation
• PX4 Tutorial - 1
• Ardupilot

• 엔지니어로서의 회고록

엔지니어로서의 회고록

• Hexagon Developer
• Resource

Hexagon Developer

이 책을 보기 시작한 보게된 계기는, 내 직장 동료가 신기해서 구매 요청을 올렸다고 해서 책을 한번 빌려봤다. 육각형 개발자 책의 표지는 아래와 같다.

책의 표지만 봐도 개발자로서 밸런스를 맞출려고 하는 것 들이 보인다. 일단 대체적인 이 책에 내용과 느낌은 일단 이번 년도를 가만히 돌아보게 되었고, 주니어로서 내가 멈춰있다고 생각했는데, 이걸 계기로 뭔가 더 성장할수 있겠다라는 마음이 들었다. 몇 부분은 생각나는대로 적어보려고 한다.

일단 나는 소프트웨어 엔지니어로서, 새로운 기술과 배우는거에 있어서는 누구 보다 빠르게 적용을 해보고 싶어하고, 공부하고 도전해보고 싶은 생각이 많다. 하지만 나는 이것에 대한 위험함을 잘 모르고 있었다. 실제 product 로 녹여내는 일은 쉬울수는 있다. 하지만 녹여내기 이전에 팀장과 그리고 팀원들과 합의하고, 성능만으로 좋다? 가 아니라 더 디테일을 가지고 접근하고 조금 더 보수적으로 가져가는 시선이 필요하다. 하지만 이 의미가 보수적으로 모든것을 바라보아야한다는 의미는 아니다. 물론 혼자서 여러 기술을 꾸준히 탐색하면서 구현도 해보고, 지금 당장 사용하지 않더라도 주기적으로 요즘은 어떤 기술이 주목받고 있는지 조사하고 핸즈온이나 별도의 학습을 빠르게 경험을 해봐야한다. 여기서 굉장히 중요한건 모든 개발자라면 알겠지만 쉽게 얻은건 쉽게 사라진다. 그 의미는 한번 실습해봤다고 해서 특정 기술을 완벽하게 제대로 구사하기 힘들수도 있다. 하지만 대체적으로 해보면서 노력하다 보면 결국 언젠가 내가 이 기술을 적용을 하려고 할때 수월해질수 있고, 이런 끊임 없는 노력이 결국엔 개발자 또는 엔지니어로서 미래 경쟁력을 유지 할 수 있다.

하지만 항상 이러한 새로운 기술력에는 기본적인 Base 가 깔린다. 어떤 언어를 구사하고 발표하려면 기본적인 언어의 구성이나 문법을 알고, 그 다음에 Idion 을 찾아서 자유롭게 쓸수 있게끔 해야한다. 이런 만큼 기본기는 충실하되, 어떤 새로운 기술력을 바라보게 되면 새로운 Insight 가 생길것 같다.

이 책을 읽으면서 내가 놓친 부분은 정말 많다. 나는 항상 구현해 대한 욕심만 있었을뿐, Archiecture Design 그리고 코드 Refactoring 작업, Test 코드에 관해서 되게 신중하게 접근을 하지 못했다. 심지어 구현 완료가 될것 같다라는 위험한 말들을 했었고, 바쁘고 장벽이 높다라는 이유로 갈팡 질팡했었고, 내 미래에 대해서 Career 을 잘못쌓고 있다라는 기분에 정말 다 하기 싫었다. 하지만 이건 나의 오만과 욕심이 컷었고, 하고 싶은 일만 할수 없었기에 정말 위에서 보기에는 어려웠을 것 같다. 이제 팀을 옮기고 나서 조금 말을 하기전에 아래와 같은 생각을 해보려고 한다.

1. 코드의 완료는 정확하게 이해하고, 왜 그렇게 짲는지의 의도를 자세하게 설명을 할수 있어야한다. (코드의 Archiecture 는 왜 이렇게 될수 밖에 없었는지, 더 좋은 방법이 있으면 물어보고, 왜 그게 좋은지 역질문을 하는 적극성이 필요하다.)
2. 코드의 완성은 테스트 코드까지다 (절대로 함부로 끝났다라고 말을 하면 안된다.)
3. 팀원들끼리 협업 또는 다른 그룹과 협업을 하기 위해서 자기 방어로서 말을 하는게 아니라, 조금 더 추상적인 면에서 적극적으로 이야기 할것
4. 팀장이 있다면, 팀장님의 말은 법이 아니라 제시하는것 이고, 왜 그런지를 자주 물어보아야 나도 그 의도를 파악을 할수 있다. (물론 코드로 이해하는것도 좋지만, 더 정확한걸 대화로 마무리를 지어야한다.)
5. 리더를 할수 있는 사람은 완벽하지 않다. 그리고 그 전의 리더가 했던 일을 그대로 할 필요가 없다. 나는 나로서 그리고 코드는 코드로서 꼭 분활해서 생각해보자.
6. 절대 두번 작업 할 일을 하지말자.
7. 꼭 왜? 라는 말에 공격적으로 듣지말자. 왜라고 하면 당당하게 이야기하면 되고, 그 배경과 근거에대해서 정확하게 말을 할수 있는 사람이 되도록 하자.

물론 더 있겠지만, 대표적으로 이 7가지일 것 같다. 내가 해매왔던 시간 들이 아쉽기도 하지만, 이제 알아갔다라는 사실이 참 다행이면서 좀더 좋은 환경을 만들수 있는 엔지니어로 성장하게 될것 같은 기대감이 있다. 이 책에서는 정말 경험으로 부터 나오는 조언들이 많았다. 다른 좋은 책들의 인용을 써서 조금 더 신뢰있는 말을 했다. 쓰다 보니 신뢰라는 단어를 써서 생각 나는 말이긴 한데, 신뢰를 얻는 거는 정말 어려운 일이다. 엔지니어로서 신뢰를 얻을 수 있는 방법은 개발 실력 뿐만아니라 조리 있게 말하고 문서 정리도 잘하는게 엔지니어다. 그리고 고객의 요구 사항을 빠르게 파악하는것도 엔지니어의 일이 아니라고 무시할수 있지만, 결국엔 회사라는건 이익을 창출 해야하는 곳이며, 창출을 하기 위해서 더많은 개발자와 엔지니어를 뽑는거고, 나는 엔지니어이기에 절대로 무시할수 없는것이라는걸 배웠다.

나는 가끔씩 내 말이 흐려질때가 가끔씩 있다. 뭔가 머리속으로 정리해서 말을 하고 있다고 했는데 순간적으로 내가 무슨말을 학소 있는지 모를때가 종종 있는데 그럴 때마다 내가 영어와 한국어의 생각을 왔다갔다해서 생각을 했는데, 제일 중요한 건 내가 필요 이상의 말을 할때가 많다라는것이 있다. 그래서 결국엔 내가 커뮤니케이션 스킬이 굉장히 좋지 않구나라는 결론에 다다르게했다. 그래서 이 부분이 정말 내가 간지럽고 너무 힘들었던 부분인데 이 책은 일단 author 도 말에 재능이 없다고 했었다. 이 부분에 있어서 공감이 갔었고, 여러 책과 경험이 필요하다고 했다. 핵심만 말하는건 결국 짧게 말하는게 아니다. 하나의 작은 음식이더라도 말은 푸아그라 처럼 맛있는 맛이 있어야 전달도 잘되고 의미 있는게 된다. 그래서 나와 같이 똑같은 경험을 하고 있는 개발자나 엔지니어에게 꼭 읽어야할 책 들을 author 가 소개를 해줬다.

말을 잘할수 있고 나의 커뮤니케이션을 잘할수 있게 연습 할수 있는 책!

• 유시민의 글쓰기 특강
• 엔지니어를 위한 문장의 기술
• 마케터의 문장
• 내 문장이 그렇게 이상한가요

물론 글쓰기의 책이지만, 나는 이렇게 생각한다. 글을 잘쓰기 시작하면, 이제 머리로 글을 자연스럽게 쓰다보면 나의 말하기가 잘 다듬어지지 않을까? 의 생각도 있다. 결론적으로 주제가 분명한 말을 해야하며, 주제를 다루는 데 꼭 필요한 사실과 중요한 정보를 담아야한다. 사실과 정보사이에 어떤 관계가 있는지 분명하게 나타내야 한다. 주제와 정보, 논리를 적절한 어휘와 문장으로 표현해야한다. 그리고!! 많이 쓸수록 더 잘쓰게된다. 이 문장은 굉장히 추상적이면서도 바로 꽃힐수 있는 말이다. 꼭 뭔가를 말하기전에 이러한 연습을 하다보면 쓰기 뿐만 아니라 나의 말이 더 명료 해지지 않을까? 의 생각이 든다.

그리고 다른 하나는 사실 대학원에 있었을때 지도 교수님이 말씀해주신것 중에 하난데 바로 Mind Map 이다. 나는 Plan 을 세울때, 약간 오만일수도 있지만 머리속에서 할수 있는데 왜저런걸 하지라는 생각이 있었다. 하지만 늘 공부할때, 실제 내 손을 거친것과 머리속에서 스치는것과는 큰 차이를 만들어낸다. 일단 생각할 내용이 많거나 계층을 가지게 될때는 하나씩 하나씩 정리하면서 마인드 맵을 활요하면 좋을것 같다라는 생각이 들었다. XMIND

리더쉽에 관한책은 많고, 너무나 황당한 책들도 굉장히 많아서 다 쓸데가 없다고 생각했지만, 이 책은 Author 가 추천해준 책이기 때문에 꼭 읽어볼 필요는 있을것 같다. 테크니컬 리더 꼭 MOI (Motivation, Organization, Innovation) 을 생각을 해보자. 개발자 또는 엔지니어는 기술로 문제를 해결한다. 이런 관점에서 보면 개발자에게 필요한 리더십이 문제 해결 리더십인 것은 당연해보인다. 테크니컬 리더 책에 따르면 뛰어난 기술 리더는 혁신, 즉 “더 좋은 방법으로 무언가를 한다’ 라는 가치로 사람들의 능력을 발휘한다고 한다. 그리고 현신을 위해서 다음 3 가지 활동에 초점을 맞춘다고 한다.

1. 문제 이해하기
2. 아이디어 흐름 관리하기
3. 품질 유지하기

그리고 마지막으로 동기 부여에 관련된 이야기를 하고 싶다. 물론 개발을 하다보면 동기부여가 안되고 특히나 개발 문서 만들때는 정말 지루하고 힘들다. 하지만, 이 또한 중요하고 뒤에 더 귀찮은 일을 만들면 안된다. Author 는 다니엘 핑크의 드라이브 라는 책을 소개 했는데, 인용을 하자면 내적 동기를 일으키는 요인으로는 주도성, 전문성 그리고 목적이 있다고한다. 주도성은 자신의 삶을 결정하고 싶어하는 욕망이고, 전문성은 의미 있는 것을 더잘하고 싶다는 용막이며, 목적은 자신보다 더 큰 무언가를 향해 뭔가 하고 싶다는 열망이다. 이 3 가지에 집중을 하다 보면, 내적 동기 부여를 높일 수 있다고 한다. 물론 외적 동기부여가 중요할수 있다. 예를 들어서 회사의 복지나 급여가 있지만 하지만 이러한것들은 장기적으로 영향을 주지 못한다. 단기가 아닌 중장기적으로 개발자에게 동기를 부여하고 싶다면 외적 동기 부여와 함께 내적 동기 부여를 끌어 올려야한다. 물론 리더로서 또는 자기 자신에게 할수 있는 말이다. 자기를 성장 시키는 건 자신이여야하며 자신의 교육은 자신이 책임져야 한다. 꼭 더 성장하고 싶은 개발자라면 명심할 필요가 있다고 생각한다.

기타는 팔로워십이 있는데, 이건 조금 추상적이기도 하고 와닿지는 않지만 생각보다 중요한 이야기인것 같다. 스태프 엔지니어

1. 관리자를 놀라게 하지말자. 관리자를 놀라게 하면 신뢰가 사라질 수 있다.
2. 관리자에게 놀라지 말자. 관리자가 모든 세세한 사항을 챙길 것이라고 기대하지 말자. 대신 관리자와 적극적으로 소통해서 정보 및 피드백을 얻자.
3. 관리자에게 관련 정보를 제공하자. 유용하다고 생각하는 정보가 있다면 관리자에게 전달한다.

이 책 정말 주옥같은 말들이 많이 있다, 그리고 엔지니어 또는 개발자로 살아가면서 꼭 누군가가 말로 정리한게 아닌, 글로 정리가 되어있어서 더더욱 공감을 할수 있었던것같다.

Resource

• 육각형 개발자

• 강의 내용 및 후기
  • GPS
  • IMU
  • HD Maps (센서 X)
  • Camera
  • RADAR
  • LiDAR
  • Radar in Deep
• Picture

강의 내용 및 후기

사실 나는 자율 주행과는 조금 가깝지도 멀지도 않은 직종에서 Simulator 와 그의 부가 되는 내용들을 개발을 하고 있다. 물론 실제 차량에 쓸수 있을지는 전혀 알지도 모르고, on-time 으로 뭔가를 할수 있다는것과도 거리가 멀지만, Autonomous Vehicle Simulator 이기에 또 가깝기도 하다. 그래서 뭔가 개요? Perception 에 대한 대체적인 것 들을 배우기 위해서 이 강의를 듣게 됬다. 그리고 SOS Lab 의 이용이님과 bitsensing 이재은, Seoul Robotics 의 이한빈님들의 알려주는 이야기를 짧게 또는 개요를 듣고 싶어서, 이 강의를 선택하게 되었다.

대부분의 이야기는 Perception 에 살짝 치우쳐져 있다는 느낌이 있었고, 인지 부터 시작해서 제어까지의 총 통틀어 하나로 나오는 Fullstack 은 어떻게 진행하고 있는지와 그리고 자율 주행에서의 큰 문제점을 어떻게 해결할지 (Perception Module 에서 부터 센서 퓨전 한 이후에 Command 까지 보내주는데에 있어서의 Latency 를 줄여야한다.) 등을 이야기 했고, Data-Driven 이 rule-based 보다 좋을수 밖에 없다라는 말도 조금 받아들이기는 쉽지 않았다.

일단 센서의 종류 부터 보자면, 아래와 같다. 딱히 HDmap 은 센서의 종류라고 말은 할수 없지만, 또 자율주행에 있어서 빼놓을수 없는 것이다.

• Camera
• Lidar
• Radar
• GPS / IMU
• Hdmap

즉, 자율 주행 자동차가 주변 환경을 인지해 주행에 필요한 정보들을 획득 및 취득하고, 그리고 이렇게 다양한 센서가 필요한 이유는 각 센서별로의 장단점이 있기 때문이다.

GPS

• 차량의 위치를 위성으로 부터 지구 좌표계의 절대 위치 정보(lat, long, altitude)를 받아온다.
• 1 ~ 10 HZ 의 느린 주기를 가지고 있다.
• 지하 / 터널 / 도심등에서 음영 지역이 발생한다.(***)
• 일반적인 GPS 는 수 m 오차가 있으므로, 자율주행에서는 부적합하다. (DGPS, GPS-RTK 사용)

(***) GPS 의 단점이므로 이걸 해결하기 위해서는 IMU 의 센서가 보완할수 있게 이용된다.

IMU

• 결국엔 차량의 위치를 절대적 좌표만으로 볼수 없기 때문에, 차량의 가속도, 각속도, 지자기 를 측정해서 자기의 위치를 판단할수 있게 한다.
• 200 HZ 이상의 빠른 주기 이다.
• 추측 항법을 통해 이동 거리 및 방향 추정 가능
• 외부 환경에 대해서 강건하나, 시간에 따른 누적 오차가 발생한다.

HD Maps (센서 X)

• IMU 와 GPS 들의 단점을 마지막 매칭하기 위해서, 자율 주행 차량이 필요한 도로 정보를 정밀하기 기록 되어있늕 지도
• 도로 규칙이나 도로의 형상, 교통 정보, 센서 데이터등이 포함도니다.

Camera

• 개체 인지 및 위치 추정에 활용
• 풍부한 텍스처 정보를 포함
• 30 ~ 60 HZ 의 빠른주기
• HD 급 카메라를 다수 장착해 FOV (Field of View) 확보.
• 조명 환경 변화에 취약, 정확한 깊이 추정 불가 (***)

RADAR

• 장애물 회피 및 충돌 감지에 활용
• 전자기파를 이용해 측정한 거리, 속도 정보를 제공
• 근거리와 원거리에 대해 모두 측정가능
• 눈, 비 조명 등 외부 환경에 강건
• 작은 물체 측정에 취약, 낮은 해상도. (4D Imaging RADAR 로 발전해 가는중)

LiDAR

• 개체 인지 및 위치 추정에 활용
• 레이저를 이용해 고해상도의 정확한 3차원 거리 정보 제공
• 10 ~ 20 Hz 의 주기
• 대상체에 대한 반사도 정보 제공
• 조명 환경 변화에 강건
• 눈, 비, 안개 등 약천후에 민감하고, 높은 비용

위와 같은 센서를 이용해서 하나의 모듈을 같이 쓰기도 하고, 다같이 쓰기도 한다. 하지만 LiDAR 에 대한 설명으로서는 아래와 같이 비교가 나와있다.

LiDAR 를 약천후가 제외한다고 하고, 많은 채널을 사용한다고 하면, 높은 해상도를 얻을수 있다고 한다. LiDAR 의 원리같은 경우는 빛의 이동 시간 (Time of Flight) 으로 측정하는 원리를 이용해서 높은 정밀도의 3차원 공간정보를 고속으로 획득할수 있다는거에 대해서 큰 장점을 가지고 있다. 대표적으로는 Velodyne 64 channel 이 있고, 이건 Scanning Lidar 인데, Scanning LiDAR 같은 경우 Motor 로 Physically 하게 돌아가게 때문에, 기계적인 요소로 인해서 Maintain 하기도 쉽지가 않아서 MEMS (Mirror Scanning LiDAR) 을 사용한다고 한다. 결국에는 빛을 Mirror 에 쏘아서 스캐닝을 한다고 한다. 물론 여기에는 단점이 있는게 FOV 이다. 그래서 여러대를 달아서 모아놓고 정합하는 작업을 후처리로 한다고 한다.

또 LiDAR 의 단점으로서는 Transmitter 에 있는데, 파장을 905 또는 1550 사이에서 적당하게 laser source 를 사용해야된다는거다. 파장을 905 를 사용하게 되면, 사람의 눈에 피해가되고, 1550 를 사용하게 되면 카메라가 파괴될수도 있다고 하기에 모든건 적절? 하게 사용해야한다라는걸 알게됬다.

Radar in Deep

RADAR (RAdio Detection And Ranging) RADAR 는 사실 학부때 들었었는데 기억나는건 RADAR 공식 밖에 기억은 안나지만 결국에는 전자기파를 송신해서, 물체에 반사된 수신신호를 통해 물체의 위치(거리, 속도, 각도)를 감지 할수 있다.

앞에서 말했던것 처럼 RADAR 의 장점으로서는 기후에대해서 굉장히 강건하다, 하지만 작은 물체에 대해서는 Detection 이 불가능하고, 이 물체가 있는지 없는지만 판별이 가능하지 이게 사람인지, 차선인지, 차량인지는 알수가 없다.

주로 사용되는 Frequency 는 77 GHZ (1Ghz Bw / 55dBm) 이고 나중에는 79 GHz(4GHz Bw, 55dBM, -3DBm/MHz) 정도 된다. 그리고 아래의 그림 처럼 현재와 미래에 대한 RADAR 가 달리는걸 보면 대체적으로 어떻게 RADAR 가 개발될지는 알수 있다.

그리고 인지쪽을 결국에 하려면, Hardware 가 Support 가 되어야하며, 그거에따른 Modulation 과 Signal Processing 이 따로 필요하다는걸 강조하셨다. 또 여기서 볼수 있는건 결국엔 Data-Driven 의 강조가 보였다.

그리고 앞서 말했듯이 각 센서들의 단점들이 존재 하지만 결국엔 어떻게 쓰는지에 따라서 였는데, 앞에서는 LiDAR 로 해결할수 있는 부분이 있다고 말씀하셨지만, 이번 bitsensing 에 계시는 분은 Camera 와 Radar 두개를 한꺼번에 융합하는 시스템이 있다고 하면, 서로 단점을 더 잘보완할거다? 라는 말씀을 하셨다.

물론 자율주행이라는게, 굉장히 상용적이여야하면서, 완성이 되려면 보수적으로 볼수 밖에 없다고 한다.

사실 다른건, 조금 Career 적으로 인것같아서 적진 않겠지만, 그래도 좋은 자료와 어떻게 자율주행쪽에서 살아가려면 어떤게 필요하고, 어떤 마음가짐으로 임해야겠다라는 생각이들었다. 그래고 Data-Driven.. 정말 rule-based 를 선호했지만, 성능차이에서는 무조건적으로 좋을수도 있지만 이게 Model 이라는게 되게 Light 해야되고, 조금 더 사용할수 있게끔 될때까지는 오래걸리기에, 조금더 넓은 안목을 가지고 자율주행쪽으로 임하는 마음을 가지게 되었다.

Picture

• 미국에서의 여행
  • 첫날 (11/10/2023)
• 마지막 및 소감

미국에서의 여행

정말 정말 2 년동안 이런일도 많고 저런일도 많아서, 글쎄? 어떤게 제일 나에게 좋은 선물을 할수 있을까? 할수 있었던데 바로 시애틀 여행이다. 뭔가 후회도 굉장히 많이 남는게, 미국에 있었을때, 여행을 같이 갈수 있었는데도 경제적 사정도 그렇고, 뭔가 부모님에게 덜 부담을 주기 위해서 생활비를 아껴야 한다라는 그런 부담감에 사로 잡혀 많이 하지 못했던 것도 있다. 그래서 이번엔 350 만원 정도 주고 미국, 시애틀에 다시 오게 되었다. 큰 설렘과 그리고 새로운 곳에 대한 무서움도 있었다.

첫날 (11/10/2023)

첫날은 시애틀에 도착했을떄는, 참 미국이 이런곳 이였지 하면서 화장실부터 느껴졌었다. 미국 화장실의 더럽고, 약간 순박한 그런것 들이 있었는데, 또 다시 보니 은근 반가웠었다. 그리고 도착해서 담배를 피면서, 미국에 대한 그리움이 점점 더 풀려가는것 같았고, 내가 진짜 이걸 하네? 그렇게 걱정도 많았고 탈도 많았었는데 이걸 하네? 이런 생각만 들었다. 캐리어를 가지고, 셔틀 버스에 올라 타는데 영어로 이야기하는게 정말 그래웠었나? 라는 생각들 들고, 그냥 스쳐 지나가는 말들도 귀에 꽃히더라. 확실히 나는 언어를 습득 한게 맞는것 같았다. 물론 완벽하지는 않지만, 아직 많이 부족한점도 굉장히 많은것 같다. 셔틀 버스에 내려서, 차 렌트를 하는데 200+ 600 불이 나와서 생각보다 많이 나왔다고 생각했다. 하지만 뭐 인슈어런스 드는것도 나쁘지는 않으니까? 어떻게 될지 모르니까? 이러면서 그냥 지나 보냈었다. 차를 타고, 호텔까지 찍는데 37 분이나 걸리는 거리였다. 내가 가는 곳은 Microsoft 옆 Redmond 라는 동네이다. 딱히 막 비싼곳도 아니고, 그렇게 도시에서 멀지도 않으니 숙박은 정말 잘잡은것 같다.

날씨는 흐리고 비가 왔었다. 축축하지만 운전하면서 보이는, 단풍나무랑 내가 미국에서 보지 못했던 언덕들 위의 집들은 정말 다 새로웠다. 와 대박? 그러면서 또 하는 생각은 나 미국인거 맞지? 나 이렇게 이런게 그리웠을까? 이렇게 차가 많은데도 운전하는게 즐거웠었던걸까? 정말 호텔가면서 뭔가 내가 진짜 잘왔구나? 이런 생각이 들었다. 호텔에 도착하자마자, 바로 미국에서 항상 짖는 나의 미소로 check-in 하고, 바로 방으로 들어와서 짐을 풀기 시작했다. 짐풀고 씻고, 누웠더니.. 밤 11시가 되버렸다?! 그래서 내가 대학원생때 진짜 많이 먹었던 two mac chicken & midium fries 를 먹으로 갔다. 근데? 와 확실히 물가가 거기에서 확 느껴지더라 원래는 6달러에 먹을수 있었던게 10 달라가 되버린거다. 시애틀이 물가가 비싸긴 하지만, 그래도 후회없이 뇸뇸하고 오늘 하루를 잘 끝냈다.

마지막 및 소감

항상 늘 똑같이 챗바퀴처럼 돌아갔던 삶을 잠시 내려두고, 여행을 온건 정말 잘한것 같다. 그리고 독립적으로 내 스스로 많은걸 했었다. 물론 그 과정들이 외롭고 무섭기는 했어도, 그리고 돈이 조금 들더라도, 큰 용기가 생겼다. 그리고, 항상 내가 스스로 결정이 아닌 환경에 의해서 나의 결정이 났었던것 같다. 내가 스스로 뭔가를 하려고 했지만, 늘 구체적인 계획을 세워서 실패와 실망감이 더많이 들었던것 같다 라는걸 알게되었다. 구체적인 플랜은 잠시 제쳐두고, 가볍고 추상적인 계획 부터 시작해서 하나씩 하나씩 붙여나가는걸 해야겠다라는 생각이 무척들었다. 물론 이 여정가운데서, 무서워서 운전하다가 손에 땀이 나고 그랬던 적이 여러번이였지만, 그만큼의 두려움은 결국 행복과 목표에 도달했을때의 성취감이 들더라. 후회는 남기지 않는 삶을 내가 만들어가야하겠다 라는 생각도 정말 많이 들었다. 감정을 잠시 제쳐두고, 내가 진짜 뭘하고 싶은지, 어떤 생각으로 내가 이런 저런것을 할수 있는지 부터 차근차근 살을 붙이는 작업을 해야겠더라. 미국의 삶 물론 외로운점도 굉장히 많고, 혼자 해내야할 산들이 정말 많았구나, 고생많았구나 라는 점도 많이 느끼고, 한국이랑 정말 다른점을 느끼게 되더라. 어느새는 내가 정말 한국인인가 보다 라는걸, 성급해서 맥도널드에 직접 찾아가서 버거 달라고 하는걸 보면 많이 한국 스러워졌다? 라고 말을 할수 있게되더라.

미국에 가는건 더 clearer 해졌다. 뭔가 나의 행복과 삶을 찾기 위해서는 이게 방법이다 라는걸 쌓게 되는 계기가 되고, 그리고 목표도 조금 뚜렸해졌다. 이제는 사람에 이끌어지지말고, 조금 필요한곳에 자존심을 세워서 자신감있게 해내야겠다라ㅏ는걸 생각 하게 되었다. 물론 지금 현재는 부족한게 많을수 밖에 없지만, 그래도 이게 하나의 계기가 되서 좋은 기억과 추억들이 나의 하나의 Journey 가 될수 있게 하는 계기가 되서 좋았다. Having a freedom in my life is supposed to be getting out of comfort zone 이 맞는 말이라는걸 알게 되서 정말 좋은것 같다. 여행을 시작하기전과 여행을 끝내고 나서의 나의 모습들이 좋게 달라졌으면 하는 바램으로, 이번의 시애틀 여행을 잘 맞춘다.

조금더 나에게 더 너그러운 사람이 될수 있게…

• Mouse Picking
• Resource

Mouse Picking

3D 게임 상에서의 물체를 Mouse 를 통해서 클릭을 해서 색깔이 변하게 하려면 크게 두가지 방법이 있다.

• 하나는 Ray Casting 기법이다. Mouse 로 부터, 물체쪽으로 광선을 쏴서, 광선이 충돌했는지 안했는지의 방법 (대신 광추적은 많이 느리다.)

Resource

• https://learnopengl.com/Advanced-OpenGL/Cubemaps

• Physically Based Rendering From Theory to Implementation

Physically Based Rendering From Theory to Implementation

이책에서 정말 인상 깊었던 말 중에 이런 말이 있다.

배우고 싶은 이들을 위해 제공되는 다른 정보처럼 프로그램 소스코드는 프로그래머가 선배들의 예술을 배울 수 있는 유일한 방법이다. 극작가가 자신의 연극을 관람하며 대사를 받아 적고 메모하는 다른 극작가의 출입을 금하는 것은 상상할 수 없는 일이다. 마찬가지로 글쓰기를 배우는 모든 아이가 글쓰기보다 글을 읽는 데 몇백 배 많은 시간을 투자하듯이 훌륭한 작가는 많이 읽는다. 하지만 훌륭한 프로그래머가 되려면 마치 긴 소설을 집필하기 위해 필요한 알파벳을 직접 발명하고 스스로 깨우쳐 글을 써나갈 수 있어야 하는 상황이다. 이전 세대의 프로그래머들이 모은 지식과 정보에 접근할 수 없다면 다은 세대의 프로그래머들은 프로그래밍을 배우고 프로그래밍을 발전시킬수 없을 것이다.
- Erik Naggum - 

아주 가끔씩, 개발자 또는 엔지니어는 정말 차고, 따뜻한 말을 종종 하지 않는다고 느끼지만 이 말을 듣고 감명 깊어서 읽어봐야겠다는 생각이 들었다. 그래픽스는 워낙 오래된 학문이다 보니, 뭔가 세대와 세대를 거쳐서 기술의 발전이 된다는걸 상기 시키게 되었다.