download package(online)

pip3 download --platform linux_aarch64 pyelftools

• 설치된 pyelftools 설치 압축파일을 설치목적지로 복사

install package(offline)

pip3 install --no-index --find-links pyelftools-xxxxxxxxxxxxxxxx.whl pyelftools

offline pip upgrade

pip3 download pip # online
python pip-xxxxxxxx.whl/pip install --no-index pip-xxxxxxxxxx.whl # offline

fix gazebo client coordinates

vi ~/.gazebe/gui.ini

[geometry]
x=0
y=0
width=1754
height=1043

set camera projection

vi warehouse.world

<?xml version="1.0" ?>
<sdf version="1.4">
  <world name="default">
    <include>
      <pose>4 1 30 0 0 0</pose>
      <uri>model://sun</uri>
    </include>
    <model name="warehouse">
      <include>
        <pose>0 0 0 0 0 0</pose>
        <uri>model://warehouse</uri>
      </include>
    </model>
    <gui fullscreen='0'>
      <camera name='user_camera'>
          <pose frame=''>0 0 0 0 1.57 0</pose>
          <!--projection_type orthographic or perspective-->
          <projection_type>orthographic</projection_type>
      </camera>
    </gui>
  </world>
</sdf>

1. Apache 2.0 License
- ASF(Apache Software Foundation)에서 만든 라이센스
- 아파치에서 만드는 소프트웨어는 모두 적용
- Apache 2.0 License 고지 해야함
- Apache 2.0 License 소스코드를 수정하였을때는 수정 내용도 고지
- Derivative Works의 소스코드 공개의무 없음
- Apache라는 상표명에 대한 침해가 되어서는 안됨

2. MIT License
- MIT에서 만든 라이센스
- Copyright, License 정보만 표기하면됨
- 매우 개방적인 라이센스
- 상업적인 배포가 가능
- 무상으로 제한없이 사용이 가능
- 문제 발생시 카피라이터가 책임지지 않고 사용자에게 모든 책임이 있음

3. GNU General Public License
- FSF(Free Software Foundation)에서 만든 라이센스
- 상업적인 배포가 가능(유료배포 가능)
- 소스코드 공개의무(내부 : closed, 외부 : open)
- 상대적으로 보수적인 라이센스

4. GNU Less General Public License
- 상대적으로 보수적인 GPL 때문에 라이브러리에 여유를 둔 라이센스
- 전반적으로 GPL과 동일하지만, 동적 정적 라이브러리에 GPL 라이센스가 적용된 경우에는 소스코드를 공개하지 않아도 됨
- LGPL 라이브러리를 사용하고있다는것만 명시 의무있음
- 그러나 LGPL 라이브러리를 수정하는경우에는 소스코드를 공개해야함

5. BSD-3 License
- Berkeley Software Distribution License
- 소스코드 공개의무가 없음
- 라이센스 정보만 명시
- 때문에 상용 소프트웨어에서 가장 많이 사용됨
- 그러나 BSD 라이센스의 소프트웨어에서 문제가 발생해도 카리라이터에게는 아무런 책임이 없음(non-endorsement clause)

6. BSD-2 License
- BSD-3 License에서 non-endorsement clause 삭제

[Adaptive AUTOSAR]

80년대 자동차 산업에서 처음 ECU가 등장하였고, 프로그램 크기와 complexity의 관점에서 ECU 내부의 소프트웨어는 간단하계 설계되었다.
현재는 자율주행의 완성도가 점점 높아지고 있으며, telematics, 인포테인먼트, IoT 장비 등등 많은것들이 차량 내부에 설치되고있다.
그러나 소프트웨어들이 많아질수록 다양한 OEM에서 다양한 규격의 소프트웨어들이 제작되었고, 제각각인 소프트웨어에 대한 표준이 필요했는데 그게 바로 AUTOSAR이다.
2002년 AUTOSAR가 처음 소개되었고, 차량 소프트웨어 개발의 관점에서의 기준 제시였다.
그러나 AUTOSAR 위에서 개발된 소프트웨어는 소프트웨어 lifecycle 내에 소프트웨어 업데이트가 이루어지지 않는다는 전제가 깔려있고, 최근에 개발되는 소프트웨어들은 빈번한 업데이트가 필요하기 때문에 Classic AUTOSAR는 맞지않다.
이는 Classic AUTOSAR가 구식이라는 이야기는 아니고, 자율주행과 같은 미래시대의 needs를 충족시키기 위한 다른 기준의 필요성 정도이다.
어쨋든 이러한 needs를 충족시키기 위해 나온 새로운 기준이 Adaptive AUTOSAR이다.

[Adaptive AUTOSAR의 필요성]

Advanced Driver Assistance System

ADAS는 자율주행의 핵심기술로 라이다, 레이더, 고성능 카메라와 같은 센서들을 기반로 동작한다.
사실상 다이나믹 통신, 유연하고 안전한 플랫폼, 빠른 데이터 전송과 프로세싱등을 제공하는 Adaptive AUTOSAR를 요구한것은 자율주행이라고 할 수 있겠다.
자율주행은 신호등, 다른 차량과 통신을 하고, 센서와 카메라를 통해 얻은 차량 외부 환경에 관련된 데이터를 가지고 핸들을 조향하고 속도를 줄이는등 차량을 조작한다.
라이다, 레이더와 같은 센서를 통해 얻은 데이터는 실시간으로 ECU에 전송되어 빠르게 처리되어야한다.
빠른 차량내부 통신을 위해서 기존의 통신 프로토콜인 CAN, LIN, Flexray 등은 충분한 속도를 내지 못하고 이더넷, SOME/IP와 같은 프로토콜이 도입되어야한다.

Vehicle Architecture

센서와 직접 연결된 기존의 ECU와 다르게, 새로운 Domain Controller Architecture는 자율주행에서 새로운 트렌드가 되고있다.
분리된 컨트롤러대신 이 컨트롤러는 Body Control, 인포테인먼트, 파워트레인 등 각각의 도메인들에 할당된다.
전기차의 경우 충전소와 차량간의 통신은 유일하고 안전해야 한다.
Classic AUTOSAR는 이러한 요구조건에 맞게 설계되지 않았다.

Firmware-Over-The-Air Update(FOTA)

OTA란 새로운 소프트웨어, 업데이트 등을 무선 네트워크를 통해 배포하는것인데 FOTA는 펌웨어를 무선으로 다운받아 업데이트 한다는 것이다.
Classic AUTOSAR는 FOTA를 제공한다.
그러나 ECU 내부 각각의 어플리케이션을 업데이트할 수는 없고, 이는 Classic AUTOSAR에서 FOTA에 대한 의존성을 약화시켰다.
flexible한 Adaptive AUTOSAR는 새로운 주안점을 가지고 소프트웨어를 업데이트하고 확장시켰다.

[Classic AUTOSAR와 Adaptive AUTOSAR의 아키텍쳐]

[두 AUTOSAR는 공존 가능한가?]

위에서도 언급했듯이 Adaptive AUTOSAR는 Classic AUTOSAR의 대체가 아니고 자동차 생태계에서 상호공존을 의미한다.
두 플랫폼 모두 각기다른 문제에 대한 솔루션이며, 이것들의 공존은 높은 가치를 창출한다.

위 사진은 두 플랫폼이 차량 내에서 공존하는 overview이다.
CAN, LIN등의 차량 내부 프로토콜을 사용하던 Classic AUTOSAR와 달리, Adaptive AUTOSAR가 가져온 가장 큰 변화는 이더넷 프로토콜이다.

그렇다면 Adaptive와 Classic ECU는 어떻게 통신할까?
첫번째 시나리오는 gateway ECU이다.
Classic ECU는 게이트웨이로써의 역할을 하고, BUS 시스템에서 Adaptive ECU가 읽을수 있는 서비스로 신호를 패킹한다.
다만 포맷에대한 변화는 필요하다.
Classic ECU는 단지 신호기반이고, 신호를 서비스로 패킹할 수 없다는 또 다른 시나리오가 있다.
여기서 Classic ECU는 신호를 UDP 프레임으로 변환하고, 이를 이더넷으로 전송한다.
Adaptive ECU는 UDP 프레임을 서비스로 변환하기위해 'signal to service'라는 맵핑 feature를 갖추고있다.

[AUTOSAR의 미래]

Classic과 Adaptive AUTOSAR는 상호 보완하고 공존이 가능하다.
Classic AUTOSAR는 소프트웨어가 깊게 embedded된 functional ECU에 특화된 플랫폼이고, 자율주행을 실현시켜주는 미래지향적인 플랫폼이 Adaptive AUTOSAR이다.
그리고 자동차 산업에서 두 플랫폼은 모두 필요하다.
언젠가 Adaptive AUTOSAR가 ECU 소프트웨어 개발에 있어서 단독 플랫폼이 될지도 모르지만 아직 그렇게 생각하기에는 이르다.

www.embitel.com/embedded-blog/adaptive-autosar-vs-classic-autosars

블로그는 정말 공부 저장용으로만 쓰고 있는데 심심해서 써본다.
후기는 처음 써보는 거라 어떻게 쓰는 건지 잘 모르겠고 그냥 서류부터 수료까지 시간순으로 기억나는 대로 써보겠다.

소마가 무엇이냐. 그냥 IT 대외활동인데 다른 대외활동에 비해 지원이 짱짱하다.
(매달 000만원 장학금, IT기기 000만원, 플젝비용 000만원, 학습비 000만원)
참고로 개발 쪽은 한이음, 멋쟁이사자처럼, 42서울 
보안 쪽은 케이쉴드, 비오비 같은 것도 있다. 
자격은 학력전공나이 무관이나 수입이 있는 사람 즉 직장인은 불가하다.

지원 절차는 서류 - 인적성 - 코딩테스트 - 면접 순이다.

[서류]
전역직후 공부 계획도 제대로 안 잡혀있었고 시간도 많아서 신경 써서 썼던 것 같다.
서류접수 기간에 사무국에서 설명회도 개최하는데 나는 안가서 어떤지 모르겠다.

[인적성]

인적성 검사는 AI를 통해 진행되는데 AI면접 처음이라 집에서 신기해하면서 대답했다.

내용이 기억이 잘 안나고 나 혼자 로봇한테 대답한 거 보고 뭔가 최첨단인데 자괴감 들었다.

[코딩테스트]
나는 ps문제를 백준에서 조금 풀어보긴 했지만 시간 안에 푸는 연습은 한 번도 안 해봐서 애좀 먹었다.

15문제 중 5~6개 정도 맞았던 거 같고 시간은 90분 줬다.

4문제 푼 사람은 떨어진 사람도 있고 붙은 사람도 있고 3문제 풀고 붙은 사람은 못 봤다. 나도 운 좋게 붙은 것 같다.
내 생각에는 15문제 다 풀라고 낸 건 절대 아닌데 ps 괴물들은 거의 다 맞추는 거 같더라.
(실제 10기 연수생들과 만남을 가진 후 5명의 괴물이 있다는 걸 알게 댐
IT 공부하면서 항상 우물 속에 있다고 느꼈는데 역시나 세상에 천재는 많드라)

ps. 강남 소재 컴퓨터학원에서 봤는데 사람이 정말 많이 왔더라. 알고 보니 역대 최고 경쟁률(8.1:1)이었다고 한다.

하지만 42서울이라는 새 대외활동이 생겼기 때문에 11기부터 다시 좀 줄어들 거라고 생각한다. 지원해보세요.

 
[면접]

취준 하면서 면접 다닐 때도 많이 안 떨었는데 이때는 왜 이렇게 떨었는지 모르겠다.

면접은 다대다 면접이다. 면접관이 6분 정도 면접자는 7명 정도 들어왔던 것 같다.

지원동기 같은 기본적인 질문들은 공통으로 한 번씩 하고,

면접자 별로 본인이 서류에 썼던 공부 했던 분야 위주로 개인 질문이 들어온다.

나 같은 경우 보안에 대한 내용을 좀 썼어서 PKI, 프로가드, 암호화와 인코딩 차이를 물어봤던 것 같다.

교통비도 준다.

[연수생 멘토 팀 매칭(가장 중요)]

3주 정도의 시간이었던 거 같다.

자유 멘토링을 통해서 팀을 구성하고 담당 멘토님을 정해야 한다.

먼저 사무국에서 그룹웨어에 본인 자기소개를 올리라고 한다.

그러면 10기 연수생, 멘토님들이 모두 자기소개를 올린다.

대충 어느분야에 관심이 있고 공부해왔는지 알 수 있다.

이때 적극적으로 연수생들 간에 네트워킹이 이루어져야 한다.

그리고 멘토님들이 자율주제로 자유 멘토링을 개설하시는데 매일 있으니 가능한 시간별로 참석하면 좋다.

본인들 소개하고 대화하며 이 사람이 어떤 생각을 가지고 있는지 알 수 있고 6개월간 함께 프로젝트할 팀원을 정하는데 큰 도움이 된다.

3명으로 팀을 구성했으면 이제 멘토님들께 연락해서 담당 멘토님이 되어주실 수 있냐고 여쭤봐야 한다.

팀당 멘토님은 4명이 붙어주신다.

이 기간에 멘토 특강도 같이한다. 여러 주제로 특강을 해주시고 그분들의 10년 20년 업계 노하우를 알려주시기도 하니 많이 참석하면 좋다.

[1차 워크샵]

리조트로 1박 2일 갔었던 거 같은데 그냥 자기소개하고 특강 몇 개 하고 레크리에이션 하고 돌아온다.

이때는 아직 팀 구성이 대부분 안되어있을 때라 자유시간에 연수생들끼리 많은 대화를 하고 팀을 구성하게 된다.

사실 일정이 매우 빡빡해서 자유시간이 많이 없다.

그래서 팀 구성을 하기 위해 잠도 포기하고 사람들을 만나고 다니는 연수생들도 있다.

[발대식]

뭐 뻔하다. 선서하고 영상 좀 보고 높으신 분들 훈화 말씀 듣고 밥 먹고 사진 찍고 끝이다.

[프로젝트 기획 심의]

팀을 구성하고 이제 어떠한 주제로 프로젝트를 진행할지를 정해야 한다.

매우 많은 고민을 했고 어려웠던 시기이다.

일단 외부에서 실제 사업하시는 분들을 심사위원으로 초빙해오기 때문에

프로젝트 주제가 단지 기술적인, 공부 목적의 자신의 실력을 발전시킬 수 있을만한 프로젝트가 아니고

사업성이 있는 프로젝트  즉 '결과물을 통해 돈을 벌 수 있는가'가 중요하다.

물론 기술적인 부분도 중요하지만 사업적인 부분을 더 본다는 것이다.

이때 멘토님들도 사업적인 부분을 강조하신다.

프로젝트 주제, 개요, 향후 일정, 기술적 요소, 기대효과 등 프로젝트 제안서 비슷하게 문서를 작성하고

심사위원분들 앞에서 발표를 한다.

첫 번째 심의에서 떨어지면 두 번째 세 번째 심의도 있다고 한다.

다행의 우리 팀은 1차 심의에서 통과돼서 바로 개발에 들어갈 수 있었다.

ps. 지정 프로젝트가 따로 있는데 3개의 팀은 멘토님들이 정한 프로젝트를 진행할 수 있다.

[2차 워크샵]

심의 끝나고 바로 2차 워크샵을 가는데 이때는 프로젝트 주제까지 모두 정해진 시기라 다들 편안한 마음으로 간다.

1차 워크샵하고 다를 건 별로 없고 50팀의 프로젝트 소개 간단하고 기억에 남는 게 없다.

선배 기수들이 몇 명 왔는데 그냥 Q & A 시간 가졌던 거 같다.

[중간평가]

8월 말쯤에 중간평가를 진행하는데 약 2달간 진행했던 프로젝트 내용을 발표한다.

우리 팀은 프로젝트 전체에서 1/3 정도 목표치를 달성해 발표했다.

[탑싯]

평가요소에 TOPCIT 점수가 들어가기 때문에 사무국에서 시험 접수를 해주고 공짜로 시험을 볼 수 있다.

10월 중순쯤에 시험을 보는데 우리 팀은 처음 팀이 구성될 때 열심히 하되 인증에 대해서 부담감을 갖지는 말자는 주의였기 때문에 프로젝트 막바지에 너무 힘들어서 나는 그냥 안 갔다. 사실 전날 밤까지 멘토링 하다가 다음날 못 일어나서 못 갔다.

어쨌든 공짜로 시험 볼 수 있기 때문에 보는 걸 추천한다.

[최종평가]

11월 말쯤에 최종평가를 진행한다.

중간평가 이후로 결원이 생겨서 부득이하게 2명에서 진행했다.

인증에 대한 부담은 없었기 때문에 멘탈이 흔들리지는 않았고 유종의 미를 거두자는 마인드로 진행했다.

웹 개발자가 없었기 때문에 마지막 1달은 처음 배우는 언어를 통해 개발을 진행해야 했고 웹 디자이너에게 외주를 맡겨가며 진행했다.

어쨌든 안 되는 건 없었고 우리 팀 프로젝트 주제가 흔치 않은 주제였기 때문에 평가 때 심사위원분들께서 고생했다고 격려를 많이 해주셨다.

[수료식]

역시 뻔하다. 선서하고 훈화 말씀 듣고 밥 먹고 사진 찍고 수료증 받고...

다만 6개월 전과 달라진 점은 모두 친해진 것

[해외연수]

팀 구성되면서 팀원들끼리 인증에 부담 갖지 말자는 마인드였기 때문에 우리 팀은 당연히 인증자가 없었지만

인증자로 선정돼 무료로 미국을 가는 연수생들에게는 축하를 보낸다. 

물론 우리 팀도 열심히 했다. 다만 인증자들은 더 열심히 했다.

센터에 그냥 상주하며 살았고 항상 있었던 사람들이다.

나도 마지막 한 달 동안 웹 개발하면서 막힐 때마다 물어보러 센터에 가면 항상 있던 사람들이었다.

받을만한 사람들이 받았던 것 같다.

내가 지원할 시기에 후기를 찾아봤을 때는 찾아도 안 나와서 매우 궁금했었는데 다음 지원자들을 위해 써줘야겠다.
휴학에 대해서 궁금할 텐데 결론적으로 우리 팀은 안 했다. 하지만 팀원들끼리 상의하에 휴학을 해도 되고 안 해도 된다.
이건 팀 구성 전에 팀원들이 소마에 어떤 마음으로 임하는지 서로 확인해야 하고 피해를 주지 않아야 하기 때문에 많은 고민을 요한다.
하면 얻어가는 건 더 많겠지만 본인의 성향 그리고 상황에 따라 해도 되고 안 해도 된다고 생각한다. 

ps. 개인적으로 휴학 추천함(남성은 재수를 안 했거나 군대가 면제라면 한 학기 휴학할만한 가치가 있다고 생각하고 여성은 4년 동안 휴학을 했거나 할 계획이 없었다면 한 학기 휴학하는 거 추천)


[경험에서 우러나온 팁] 
- 팀 꾸리기 전 최대한 많은 사람들과 많은 이야기를 해봐라.
- 팀 꾸리기 전 가능하면 소마에 임하는 태도를 확인하면 좋겠다.
- IT는 확실히 좁고 가면 분명 아는 사람 만날 것이다.

- 사무국분들은 매우 친절하고 잘 활용해라.

- 행사 때마다 유용한 굿즈를 많이 준다. 다만 전부 소마 로고가 각인되어있다.
- 9월쯤에 팀 전체가 침체기였는데 살면서 이런 거 해보는 기회 흔치 않은데 시간 날리지 말자.

- 당시에는 힘들지 몰라도 돌아보면 후회이다. 힘들어도 참고 그냥 해라.

- 소마에 시간을 많이 쓸수록 멘토님들께 배울 건 더 많아질 것이고 당연히 배우는 건 많아질 것이다.

- 소마는 90프로 자율적으로 진행된다. 본인이 노력하면 노력할수록 얻는 건 정비례한다.

- 안 하면 얻는 것도 없다.

- 새로운 것을 하는데 두려워하면 안 된다.

공교롭게도 조만간 사무국에서 11기 선발 공지를 올릴 텐데...
나도 그랬고 일부 수료생들도 내가 왜 붙었지 라는 생각을 해본 사람 많다.

나만 빼고 다들 가만 보면 붙을만해서 붙었는데 정작 본인은 왜 붙은 건지 의아해한다.
나는 안될 거라 생각하지 말고 무조건 지원해보길 바란다. 

국내 IT 대외활동에서 높은 수준의 지원과 학부생이 쉽게 경험하기 힘든 경험을 하게 될 것이다.