자신에 대한 고찰

아는 사람이 있을지는 모르겠지만, 구글에서 experiments with google 이란 프로젝트를 통해서 상업화하기는 어렵지만, 뭔가 신기한 프로젝트를 진행하는 게 있다. 최근에는 제목과 같이 TF Microcontroller Challenge라는 대회를 개최하고 있다. The TensorFlow Microcontroller Challenge - Experiments with Google Since 2009, coders have created thousands of amazing experiments using Chrome, Android, AI, WebVR, AR and more. We're showcasing projects here, along with helpful tools and reso..

이전 포스트에서도 계속 언급했다시피, 딥러닝 모델을 모바일이나 임베디드 환경에서 그대로 돌리기 어려운 이유는 일반 PC와 달리 메모리나 성능, 저장공간 등의 제한이 있기 때문이다. 이 때문에 해당 모델을 어떻게 최적화(Optimization)하느냐가 임베디드 환경상에서도 최적의 성능을 낼지 여부를 결정하는 요소가 된다. Tensorflow Lite도 결국은 Model deploy시 이 최적화를 해주는 기능이 포함되어 있는 것인데, 이 때 Quantization이 적용된다.치ㅑ Quantization은 간단히 말해서 Neural Network의 내부 구성이나 표현되는 형식을 줄이는 과정을 말한다. 예를 들어서 현재 구성된 Neural Network의 weight이나 activation output이 32b..

홈페이지에는 Tensorflow Lite로 구현할 수 있는 Image Classification이나 Object detection, Question Answering 같은 예제들이 소개되어 있다. 참고로 Raspberry PI같이 Embedded 환경에서 Test해볼 수 있는 Image Classification이랑 Object Detection 같은 것만 예제로 제공되고 있다. 아무튼 전반적인 Tensorflow Lite가 어떻게 돌아가는지를 확인해볼 수 있는 예제를 살펴보고자 한다. 우선 Keras로 간단한 Linear regression을 위한 model을 한번 만들어본다. import tensorflow as tf x = [-1, 0, 1, 2, 3, 4] y = [-3, -1, 1, 3, 5, ..

보통 Deep Learning을 생각하면, 엄청 복잡한 모델, 예를 들면 Image Classification을 할 때 CNN으로 구성한다던지, 뭔가 예측을 할때 LSTM같은 특정 기능을 하는 모델을 생각할 것이다. 이런 것들을 실제 폰이나 전자 제품에 올라가있는 Microcontroller 같은데에서도 동작할까? 기본적으로 Deep Learning 모델을 학습시키는 PC를 생각하면, 일반적으로 x86 cpu를 쓰고 별도로 GPU같은 가속기를 달기도 하며, 모델을 읽어오거나 저장할 공간이 충분하고, Windows나 Linux같은 OS가 올라가 있겠지만, 폰에는 ARM cpu가 들어있고, PC에 비해서는 상대적으로 저성능이고, 심지어 Microcontroller에는 OS도 없는 환경이 대부분일 것이다. 이..

제품 개발에 있어서 가장 크게 고려되는 사항중 하나가 바로 성능 측정(Performance Measure)이다. 성능 측정을 통해서 사용하고 있는 시스템의 좋고 나쁜 정도를 정량적 수치로 얻어낼 수 있다. 보통 성능 측정이라고 하면 크게 다뤄지는 키워드가 Latency이다. Latency란 I/O 장치가 그에 맞는 동작을 할때, 아무것도 안하고 있는 시점에서 명령이 들어와 동작을 수행한 시점간의 시간 차이를 말한다. 궅이 쉬운말로 표현하면 "반응 시간"정도가 될텐데, 보통 이런 Embedded 환경에서는 하드웨어적으로 발생할 수 있는 delay(hardware delay)와 소프트웨어적으로 발생할 수 있는 delay(software delay)를 합쳐서 Latency라고 표현한다. 그런데 Latency라..

아마 임베디드 개발을 하다보면 제일 많이 나오는 통신 규격이 직렬통신(serial communication)일 것이다. 많은 핀이 필요한 병렬 통신(parallel communication)과는 다르게 serial communication은 핀 몇개만 가지고 쉽게 데이터 통신이 가능하다. 다만 큰 데이터를 전달하기에는 핀의 갯수가 부족하기 때문에 일반적으로는 큰 데이터를 정해진 크기의 패킷으로 분리해서 그 패킷들을 한꺼번에 보낸다. 보통 시간과 공간 측면에서 통신이 발생할 경우, 진행되는 과정은 크게 3가지 과정이 있다. 1. Encoding : 보내고자 하는 데이터를 암호화한다. 2. Transmission : encoding후 생성된 packet을 상대방에게 전달한다. 3. Decoding : 수신한..

아마 보드에 달려있는 IP 중 가장 기본적인 IP가 GPIO가 아닐까 생각한다. GPIO는 단어속에 내포되어 있는 뜻 그대로 General Purpose Input/Output, 일반적으로 사용할 수 있는 register를 말한다. 그리고 실제 보드를 살펴보면 수많은 점퍼핀들이 나와있는 것을 알 수 있다. 그런데 보통 각 핀의 역할이 Input이다, Output이다로 명확히 구분지어진게 아니라 이 역할을 정의해주는 register field가 있다. 보통 Datasheet을 살펴보면 Mode Register라고 하는 것이 그 것이다. (device의 종류에 따라서는 Direction Register라고 표현되어 있는 곳도 있다.) 내가 취미삼아 듣고 있는 강의에서 사용되고 있는 TI Tiva 보드에서도 ..

edX에서 진행중인 수업중에 하나인 Cyber Physics System 과제다. 주제는 obstacle Avoidance.사실 우리 주변에도 로봇 청소기 쓰는 사람이 많다. 그런데 막상 로봇이 장애물을 회피하려면 어떤 구조를 취해야 할까를 고민해보니까 생각보다 간단하지 않다.내가 간단하게 구현한건 일일이 로봇청소기가 벽에 부딛쳐본후 그 거리가 일정 거리 일상일때 그만큼 다시 사선으로 나아가는 방식으로 취해있다. 이게 가능한건 로봇청소기에 bump sensor, 즉, 충돌 감지 센서가 달려있기 때문에 가장 이상적으로 생각했던 로봇이 벽면을 쭉 훑으면서 목적지로 나아가는 건 해보고 싶었는데 할게 너무 많던지라;;아무튼 간단하게 cybersim이라는 Labview기반의 simulator에서 테스트했는데 생각..

지난번에 적외선 센서에 대한 이야기를 잠깐 했다.2014/02/23 - [About Things] - [Thing] Infrared Distance Sensor그 때 만들고 싶었던게 이거다. 이게 차지 무슨 로봇이냐 할 수도 있는데 엄연하게 운영체제(BBB 상의 Linux) 도 있고, wifi를 통해서 무선 조종도 가능한 로봇이다. 아마 인터넷상에서는 redbot이라고 검색하면 나오는 거다. 사실 gatech 강의 들을때 그쪽 학생들은 khepera 3 라고 하는 주행 로봇을 쓴다고 하는데 한대 가격이 대략 2~300만원 정도 한단다. 그래서 대안적으로 고려한게 이 redbot 이고, DIY면서 비슷한 기능을 제공하고 싸게 만들수 있게 했다. 나는 만드는데 대략 13만원 정도 들었던 것 같다. 이 로봇의..

퇴근하고 와서 삽질하다가 드디어 된 결과물이다.전에도 계속 언급했지만 edX에서 Embedded System Class를 수강중이고, TI Tiva C Launchpad를 이용해서 여러가지 프로젝트를 진행한다.위 프로젝트는 그중에서도 신호등 시스템을 구현하는 건데, 시스템 설계나 프로그래밍 작성 측면에서 여러가지 생각을 하게끔 해줬다. 보통 임베디드 시스템을 설계하는데 있어서 중요한 건 현재 state가 무엇이냐와 들어올 입력에 대해서 어떻게 반응할 것이냐다. 그래서 보통 이런 걸 Finite State Machine으로 구현한다. 우리가 흔히 알고 있는 FSM은 Moore Machine( 현재 status가 다음 status와 Output을 결정하는 방식)과 Mealy Machine(현재의 status..

지난 포스트까지 해서 Periodic Task가 들어왔을 때 대처할 수 있는 Scheduling 기법을 다뤘다. 하지만 Task가 항상 Periodic하게만 오지는 않는다. 당연히 예기치 못한 동작에 대해서도 올경우도 있을 것이고, 또는 사용자의 입출력에 따라서 나타나는 Task가 있을 것이다. 보통 그런 것들을 통틀어서 비주기적 Task, Aperiodic Task라고 한다. 이 Aperiodic Task에도 발생되는 주기에 따라서 크게 두가지로 나눠볼 수 있는데 첫번째는 Soft Aperiodic Task이다. Task의 발생빈도나 execution time이 주기적이지는 않으나 그 발생하는 정도가 어떤 distribution을 나타내는 경우가 여기에 포함된다. 그래서 사용자의 요청을 받는 경우가 S..

지금까지 계속 다룬 걸 보면 계속 Scheduling에 대한 내용에는 항상 Timing Value에 관한 것이 포함되어 있다. 우리가 이 값들을 미리 알고 해당 Task에 대한 Scheduling을 할 수 있다면 그보다 더 나은 System은 없을 것이다. 그런데 이걸 매 Timing 때마다 고려를 하자니 여기에 소모되는 Resource가 낭비된다고 생각할 수 있다. 그래서 해 볼 수 있는 생각이 한계를 정해두고 한계를 넘지 않는 한은 계속 용인하고 한계를 넘는 것에 대해서만 다른 처리를 할 수 있는 구조를 택하자는 것이고, 그 한계를 Worst Case일 때의 한계로 정해보자는 것이다. 이번 포스트에서 소개하는 Worst Case Execution Time은 말 그대로 Execution Time 중에서..

지금까지 계속 EDF와 RM의 Optimality 혹은 Schedulability를 확인하는 내용을 다뤘었다. 그런데 사실 이렇게 구한 값들이 실제 케이스상에서도 적용할 수 있는 값일까 하는 의문을 가질 수 있다. 만약 그게 가능하다면 앞으로 Task Scheduler를 설계할 때는 이미 구해놓은 utilization이나 Release Time만을 활용하면 쉽게 설계할 수 있다. 하지만 공학을 설계한 사람이라면 누구나 알다시피 이론과 실제 케이스는 너무나 큰 차이를 나타낸다. 이론에 나온 것은 단순히 실제 케이스들 중에서 제한 사항을 엄격히 설정한, 아주 특이한 케이스 인 것이다. 실제로 이전의 EDF나 RM의 Optimality를 측정할 때도 언급하지는 않았지만 우리는 무언의 제한을 두고 있던 것과 같..

지난 포스트에서 이야기 했던 것처럼 N개의 Task에 대해서 Utilization를 측정하는 것이 어렵기 때문에 이에 대안적인 방안으로 Time Demand Analysis를 쓸 수 있다고 했다. 간단히 요약하자면 각 Task의 Response Time을 측정해서 그때의 Time Supply보다 큰가 작은가를 비교하면 Schedulability 를 얻을 수 있다는 것이다. 그런데 아마 Time Demand Analysis에 대해서 기억하는 사람이 있다면 이 접근 방식의 문제를 알고 있을 것이다. 바로 모든 Case에 대해서 다 구해야 한다는 것, 매 period마다 Schedulability를 측정하기 위해서는 response time을 재야 하고 이를 위해서는 무한적으로 측정해야 한다는 답이 나온다. ..

지난 포스트를 통해서 Rate Monotonic Algorithm을 사용한 Schedule의 Minimum Utilization이 0.69 이고 이걸 LL Bound라고 했다. 이번 포스트에서는 Earliest Deadline First의 Schedulability를 보고자 한다. 아무튼 우리가 알고 있는 것은 해당 Task 들의 Schedulability를 측정하기 위해서는 각각의 Task에 대한 Utilization을 구해야 되고 그 중에서 가장 작은 Utilization Bound를 찾아야 한다. 이게 결국은 Utilization Bound Check의 간략한 진행 방법이다.그러면 Utilization 자체는 Execution Time / Period 의 합이므로 EDF의 Utilization은 다..