ROS2 Design
http://design.ros2.org/
2019년 8월 9일 금요일
2019년 8월 8일 목요일
2019년 8월 4일 일요일
linux preempt_rt 성능 테스트
기억용.....보관용...
https://m.blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=221170259817&proxyReferer=https%3A%2F%2Fwww.google.com%2F
3. RT 벤치마크 사용하기
3.1 cyclictest 설치
RT 벤치마크는 참 여러가지 종류가 있다. 가장 많이 쓰이는 벤치마크는 cyclictest10 라는 프로그램인 듯 하여 본 포스트에서는 cyclictest를 사용할 것이다. 그러나 벤치마크가 cyclictest만 있는것도 아니니, 흥미가 있는 사람은 레퍼런스에 있는 벤치마크를 알아보기 바란다. 물론 난 전부 다 써보진 않았다111213. 그 중에는 한국인이 만든 벤치마크도 있다!14 (이분은 지금 삼성에서 일하고 계신 듯 하다. 심지어 내가 살고있는 곳 바로 옆에 살고계신다.. 영통...)
어쨌든, cyclictest 벤치마크를 내려받아 사용해보자. 참 쉽게 사용할 수 있다.
1
2
3
4
5
|
git clone git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
cd rt-tests
git checkout stable/v1.0
make all
make install
| cs |
3.2 cyclictest 실행 및 결과 분석
cyclictest는 수만번, 수십만번의 벤치마크 루프를 돌면서 성능을 측정한다. 자세한 내용까지 들여다 보지는 않았지만, 쓰레드가 잠잤다가(sleep) 일어났을 때(wake)의 시간 차를 측정해 보여주는 걸로 추측된다. 그리고 그 도중, 시간 차가 일정 threshold를 넘으면 overflow로 간주해 결과로써 표시해주는 것 같다.
곧바로 벤치마크를 실행해보자.
1
|
./cyclictest -l100000 -m -n -a0 -t1 -p99 -i400 -h400
| cs |
-l 옵션은 루프의 회수, -t 옵션은 실행될 쓰레드의 개수, -p는 쓰레드의 우선순위(RT 기준) 을 나타낸다. cyclictest 프로세스는 -t 옵션에 명시된 개수만큼의 LWP(Light Weight Process)를 생성하며, 이 쓰레드(프로세스?) 는 SCHED_FIFO로 139의 Priority를 갖는다.15
결과는 아래와 같으며, 각각 차례대로 (1) RT 패치가 되지 않은 라즈비안, (2) emild RT 라즈비안, (3) 일반 커널에 RT를 패치한 경우이다.
Max Latency는 수십만번의 벤치마크 루프 중 가장 Latency가 컸을 때를 의미하고, Min Latency는 가장 짧았던 Latency, Avg는 평균을 의미한다. Total은 총 루프 회수를 뜻하니... 위에서는 1000000번의 루프를 수행한 것이다.16 Histogram Overflow at cycle number는 몇 번째 쓰레드에서 Overflow가 났는지를 뜻하며, 많으면 많을수록 성능이 안좋은 것이다. (따라서 첫 번째 실행 결과가 가장 Worst 하다)
Max Latency (us)
|
Min Latency (us)
|
Avg Latency (us)
| |
일반 커널
|
514
|
14
|
20
|
emlid RT 라즈비안 커널
|
67
|
10
|
12
|
일반 커널 RT 패치
|
91
|
11
|
18
|
꽤 흥미로운 결과가 나왔다. 일반 커널의 Max Latency는 500을 뛰어넘었지만 emild RT 라즈비안은 67에 불과하고, 일반 커널에 RT를 패치한 경우는 91가 나왔다. emild RT 라즈비안 커널이 다른 두 개에 비해서 벤치마크 성능이 월등히 높게 나온다. 일반 커널보다 Latency가 낮은건 이해하겠는데 일반 커널 RT 패치보다 성능이 좋다(......) 직접 벤치마크를 해봤다면 알겠지만, 실행 중 출력에서 나오는 Latency 값도 emild는 10~12를 오가는 반면 일반커널 RT 패치는 15~18을 넘나든다.
왜 두 개의 성능이 다른지는 아직도 잘 이해하지 못하겠다. emild가 소스코드를 특별히 수정한게 있나보다.. 하고 추측만 할 뿐이다.
3.3 시스템 부하를 인위적으로 가해 벤치마크 수행하기
사실 Real-time이라는 건 시스템 부하가 없는 상황에서는 크게 의미가 없다고 볼 수 있다. 왜냐하면 CPU가 Idle 한 상태에서는 무엇을 처리해도 빨리빨리 수행할 것이고, 이러한 상황에서는 RT 리눅스가 의도하는 바인 Pre-emptive의 효과는 크게 두드러지지 않을 것이기 때문이다. 따라서 각 테스트 케이스에서 RT 벤치마크 결과의 차이점을 뚜렷하게 확인하기 위해서는 시스템에 의도적인 부하를 가해야 할 필요가 있다.
부하를 인위적으로 주는 방법은 여러가지가 있겠지만, 내가 이 포스트를 작성하며 사용한 방법은 크게 2가지이다. 첫 번째는 hackbench 라는 툴을 사용해 시스템에 부하를 주는 것이고17, 다른 하나는 cyclictest의 쓰레드 개수를 늘리는 것이다. 이거 말고도 위에서 한국인이 만들었다는 Worst Case Latency Scenario 라는것도 있지만 여기서는 굳이 다루지 않기로 했다.
먼저 hackbench에 대해서 설명하자면, hackbench 는 cyclictest github에 포함되어 있기 때문에 cyclictest를 사용했다면 동 디렉터리 내에 hackbench 파일이 존재할 것이다. hackbench는 두 개의 쓰레드를 생성하고, 서로가 메시지를 엄청나게 많이 주고받음으로써 부하를 일으킨다고 한다. 사용 방법은 매우 쉽다.
1
|
hackbench -l 1000000
| cs |
-l 옵션은 부하 시도 횟수... 로 추측된다. 위 명령어를 실행하면 곧바로 시스템 부하가 시작되며, hackbench를 실행한 상태로 cyclictest를 실행하면 된다.
다른 하나는 cyclictest의 쓰레드 개수를 늘리는 것이다. 직관적으로 생각해 볼 때, 벤치마크가 동시에 여러 개가 실행되면 벤치마크의 성능은 더욱 나빠질 것이다. 따라서 여러 개의 cyclictest를 구동하는 것은 매우 간단하면서도 효과적인 부하 발생 방법이라고 볼 수 있다. 그렇지만 터미널을 여러개 켜고 cyclictest 명령어를 각각 입력할 필요는 없고... cyclictest에서 -t 옵션에 쓰레드의 개수를 지정해주면 된다. 일반적으로 CPU의 개수만큼 쓰레드를 생성해 테스트한다. 또한, -a 옵션을 통해 CPU Affinity를 고정해 주는 것이 일반적이다.18
1
2
3
4
5
6
7
8
9
|
root@rt-linux-rpi-4:/home/pi/rt-tests ./cyclictest -l100000 -m -n -a -t4 -p99 -i400 -h400
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.04 0.05 0.00 1/166 1042
T: 0 ( 1039) P:99 I:400 C: 13914 Min: 11 Act: 17 Avg: 13 Max: 75
T: 1 ( 1040) P:99 I:400 C: 13808 Min: 11 Act: 18 Avg: 13 Max: 61
T: 2 ( 1041) P:99 I:400 C: 13704 Min: 11 Act: 17 Avg: 13 Max: 58
T: 3 ( 1042) P:99 I:400 C: 13598 Min: 11 Act: 30 Avg: 13 Max: 44
| cs |
어쨌든, RT 패치된 커널에서 부하를 가한 뒤 cyclictest를 실행하면 CPU가 자주 뻗어 죽어버리므로 재부팅해야 한다는 단점이 있다.
주의해서 사용하도록 하자.
끝.
1. 라즈베리파이 3를 쓰지 않은 이유는 아래에서 설명할 emild의 RT 라즈비안이 라즈베리파이 3를 지원하지 않기 때문이다. 라즈베리파이 3에서 사용하는 방법은 https://autostatic.com/2017/06/27/rpi-3-and-the-real-time-kernel/ 를 참고.
2. github 주소 : https://github.com/emlid/linux-rt-rpi
3. emild 사이트 주소 : https://emlid.com/raspberry-pi-real-time-kernel/
4. 혹시 모르니
CONFIG_PREEMPT_RT_FULL: Kernel Features → Preemption Model (Fully Preemptible Kernel (RT)) → Fully Preemptible Kernel (RT)
Enable HIGH_RES_TIMERS: General setup → Timers subsystem → High Resolution Timer Support (Actually, this should already be enabled in the standard configuration.)
를 설정한다.
5. RT 라즈비안 설치 방법 잘 설명해 놓음 : http://www.frank-durr.de/?p=203
6. 똑같은 내용이지만, 잘 설명해 놓음 : http://artteknika.hatenablog.com/entry/2016/08/23/142820
7. 라즈비안 RT 패치 공식 문서 : https://www.raspberrypi.org/documentation/linux/kernel/patching.md
8. 리눅스 재단(Linux Foundation) RT 패치 공식 문서 :
https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/preemptrt_setup
9. RT Patch Config 확인방법, 개념 및 다양한 내용 :
https://raspberrypi.stackexchange.com/questions/8970/default-kernel-preemption-vs-real-time-patch
10. https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest
11. https://www.osadl.org/Latency-generator.latency-generator.0.html
12. https://www.osadl.org/Driver-to-Program-Signal-Tester.driver-to-program-signal-tester.0.html
13. https://wiki.archlinux.org/index.php/Realtime_kernel
14. https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/worstcaselatency
15. 궁금하면 cyclictest 를 실행한 뒤 ps -cLe | grep cyclictest 를 사용해보자.
16. Cyclictest 결과 분석 및 예제 소스코드 한국어 포스트. 매우 잘 써놨음 : https://blog.naver.com/indy9052/120123664718
17. https://man.cx/hackbench(8)
18. Cyclictest 옵션 설명 및 결과 분석하기 :
https://events.static.linuxfound.org/sites/events/files/slides/cyclictest.pdf
2013년 4월 16일 화요일
제어란 ??? Control is ......... what ?
제어란 학문은 참 매력적이긴 한데, 범재인 나에게 점점 괴로움을 안겨주기도 한다.
무엇보다 나이는 먹어가고, 돈은 없고, 현대 사회에서 의식주가 해결 안되면 신선 놀음도 사치다~~~ 먹고 사는 게 해결되야 꿈이던 취미던 부담어없이 즐길 수 있지 않을까~~
제어는 재밌지만, 현실은 선택을 강요한다. 먹고 사는 것 걱정없이 제어 연구만 할 수 있으면 좋겠다 ㅎㅎㅎ;
제어는 짬뽕이다.
제어를 하기 위해 필요한 지식 들을 정리해보면, ( 책에도 가끔 언급은 되어있지만, 대부분의 제어 책은 그냥 이론뿐, 문제는 그것만으로는 제어를 할 수 없다는게 넌센스 ㅡㅡ^)
( 내 맘대로 쓰는 글이니, 틀려도 책임 못진다 ㅎㅎㅎㅎ)
What skills are required to do control ????? (It is a just my opinion!!!)
모델링 센스 (modeling sense) : 주어진 시스템을 수학적(?)으로 모델링을 할 수 있어야 한다. 즉, 제어 이론을 알기 이전에 제어할 대상을 자~~알 알아야 한다. (ㅡㅡ;; )
이게 골 때리는게 로봇 제어할려고 하면, 일단 로봇에 대해 자세히 알아야 한다. kinematics 라던지, 동역학이라던지....
즉, 제어 대상에 대해 먼저 세세히 파악을 해 놔야 한다. 제어 이론과는 무관하게 ㅡㅡ;;
뭐 솔직히 그냥 대충할거면, pid 써서, 대충 튜닝만 하면 흠 왠만하면 대충~~은 동작할 껄~~~~ 이렇게 할거면, 솔직히 아래의 수많은 학문을 알 필요 없다. ㅋㅋㅋㅋㅋㅋ
뭐 판단은 알아서... 자기 하고 싶은 만큼만 하자... 아 피곤한 인생이여~~~~
수학 수학 수학 수학 수학 (mathematics) : 제어 이론은 결국 수학이다. ㅡㅡㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
System identification : 모델링과도 연관이 있고, 이게 없으면 솔직히 제어 이론이 무용지물이다. 시스템 식별을 통해서 model structure 가 타당한지, 실험적으로 검증하는 데 사용할 수 있다.
제어 책은 허구헌 날 모델과 numerical value 를 제공하는데, 이건 솔직히 단순 문제 풀이 밖에 안된다. 그러나 불행히도, 현실 세계에서 과연 누가 그 시스템에 대한 numerical value 를 제공해 줄까? ㅎㅎㅎㅎ;; 거의 없다. 자기의 일은 스스로 하듯이 스스로 찾아야 한다. ㅡㅡ^
numerical value 모르면, 무슨 수로 제어기를 설계한단 말인가 ~~~ ㅎㅎㅎ;;
시스템 식별 실험은 numerical value 를 추정하는데에도 쓰이는 학문이다.
( 아 ~~~ 줸장, 제어 이론보다 먼저 이걸 마스터 했어야 했어... 근데 이거 교과 과정으로 있는 곳이 있나? 거의 없는 거 같은데,,
시스템 식별에 대해 자세하게 다룬 수업을 들어본적이 없다. 결국 스스로 깨닫고 맨 땅에 헤딩을 해야 할 상황....
문제는 이 쪽 학문에 익숙해지기에는 내 두뇌가 평범해서 괴롭다 ㅠ.ㅠ)
adaptive filtering ? signal processing ? : 시스템 식별 학문을 할려면, 결국 신호 처리 무조건 들어간다.
adaptive filtering 책을 이것 저것 뒤적여 봤는데, system identification 이 adaptive filtering 내용에 있더라 ㅡㅡ;; 하긴 뭐 결국 optimization problem 과도 일맥 상통하지.. least square 라던지, 기타 등등
linear control (theory) : 전체 제어 이론에서 선형 제어는 뭐 그냥 껌 수준 ?. 기본이다 기본....
근데 웃긴건, 대부분의 논문 등이 선형 제어 위주로 다룬다는 거,,, 왜냐면 쉽거든 ㅡㅡ;;;
나도 이해해... 비선형은 내게 너무나 먼 그대여~~~~~나도 선형 모델에서 벗어나지 못하고 있어 ㅜ.ㅜ
결국 stability 와 performance 가 전부~~~~~ stability 란 무엇인가에 대해 깨달아라 그러면 길이 열리리라~~~~
nonlinear control : 제어 이론의 꽃이라고 본다. 사랑해요 비선형~~~ 그러나 내 두뇌는 비선형을 이해하기엔 부족하다 ㅠ.ㅠ
비선형 시스템을 이해하면 선형 제어를 그냥 씹어먹는다. 비선형 제어는 선형 제어를 포함하니까 ㅎㅎㅎㅎㅎ
robust control : 선형 제어든 비선형 제어든 그냥 uncertainty 추가한 것 밖에 없다. 내가 보기엔.... 나두 잘은 모른다. 자세히 익혀보고 싶지만, 시간도 없고, 맨 땅에 헤딩에는 한계가 있는 법~~~~
adaptive control : fixed controller 에 반대 개념.... 그냥 제어 게인이라던지 다른거라던지 뭔가가 changeable 하면서 adaptive 하면 adaptive control 이라고 부르는 것 같다.
이것도 indirect, direct 이렇게 나눠지는 거 같은데, 구현해 본적이 없어서 나두 잘은 모른다. 몇번 책을 보다가 중단중이다. 왜 이리 책은 어렵게 써놓았는지...
적응 제어 잘 할려면, estimation 이라던지, system identification 이라던지 여러 스킬들을 더 요구한다.
뭐 제어의 궁극은 인공지능이라고 스스로 생각하지만, 뭐 인공지능도 결국 adaptive control 이니, 적응 제어가 궁극점이라고 할 수 있다. 그러니까 적응 제어는 어렵다.!!!!!
optimal control : 뭐 이런 것도 있다던데, LQR 뭐 이런거 말하는거 같은데, 그냥 제어기 설계를 어떻게 최적화 할거냐 문제인듯..
뭐 결국 object funcation 이 관건이겠지.. 최적화는 뭐 다 거기서 거기더라... concept 만 보면..
stochastic system : 뭐 이 바닥 굴러먹으니 뭔놈의 확률 통계가 안 끼어드는데가 없냐... 아~~ 확률 통계 잘 못하는데...
뭔놈의 앙상블이라던지 (넌 뭐하는 놈이냐~~) 아무튼 이놈의 확률, 통계 개념은 단골 손님이더라......
제어 응용 관련해서~~~~~ related to applications of the control
----- mainly robot control application -----
tracking control : 대부분의 제어가 tracking contol 에 속하겠지.. 죄다 reference signal following 하는 것을 주로 다루니깐..
interaction control : 흠, 그냥 contact 이 있는 task 에 해당... hybrid force/position control 이라던지, impedance control 이라던지 이 2개가 active compliance control 의 대표 방법론이다.
갑자기 블로그를 만들어서 혼자 주저리 주저리 떠드는 이 상황... 이 짓도 몇일이나 갈련지 모르겠네........
앞으로 같이 로봇 제어를 함께 할 수 있는 사람이 있었으면 하는 바람이 있긴 하다.
취미로 라던지, 뭐 인터넷이 발달했으니 online 상에서 서로 discussion 이라고 주고 받을 수 있는 상대가 있으면 좋겠다고 생각은 하는데, 인생이 바쁘니 얼마나 관계가 지속될지 의문이다.
제어에 대해 주저리 주저리 떠들었는데, 뭐 빠진 것도 있겠지만.... 내가 봤을 땐 다 필요없어~~~~~
신소재 분야에서 신소재 만들어 내고 (새로운 actuator 라던지, new sensor 라던지~~~)
그냥 인공지능 하나만 제대로 나오면 제어는 끝이야 끝~~~~ 이미 기본적인 제어 이론은 다 성립되어 있잖아~~~~
현재 문제는 그걸 움직일 두뇌가 없다는 게 문제일 뿐이니....
굳이 나누자면, actuator 를 제어하는 low level 의 제어는 현재 이론만으로도 충분하다고 봄.
command 를 줄 수 있는 두뇌 역할을 하는 high level 의 제어 즉, 인공 지능만 있으면 제어에 대 격변이 일어날거야...
더 이상 제어 이론을 더 할 필요가 없어질지도....ㅎㅎㅎ 인공지능이 최적화 라던지, 적응 제어라던지 알아서 척척 처리하겠지 ... 사람이 더 이상 끙끙대면서 제어 파라메터 설계할 필요가 없겠지 ㅡㅡ;;
아~~ 말은 많았는데, 나이는 먹어가는데 내 실력은 아직 여전히 부족하다는 데에 한숨만 나온다.
이론 지식과 실기 지식 (구현 지식) 을 동시에 갖추고 싶은데, 휴~~ 이론 지식도 아직 형편 없고, 구현 스킬 등의 경험을 쌓기에는 여러 어려움이 너무 많구나~~~
내가 하고 싶은 것을 하고 싶으나, 현실은 녹록치 않은 듯~~~~~~ 졸업 후에 (내가 원하는) 로봇 제어를 계속 할 수 있을지도 모르겠다~~~~~~ㅎㅎㅎㅎㅎ;;; (로봇도 너무 분야가 넓고,,,, 아직은 돈이 안되니깐~~~~ㅠ.ㅠ)
Machine Learning ~~~
아~~~ Machine learning 이 인공지능에의 출발점일 줄 알았어~~~~~
나의 이쪽 분야 지식은 미천하지만, ( 결국 또 시간날 때 맨 땅에 헤딩하며 잠깐 관련 책을 독서한 수준이니 ㅡㅡ;;)
현재까지로는 Machine learning 은 AI 가 아니더라~~~
그냥 뭐 좀 더 정교한 계산 알고리즘 수준 ???
지능 제어라고 이름이 붙었지만, 스스로 생각하는 혹은 창조하는 기능이 없는 걸 지능이라고 말하기엔 어폐가 있다..
지능 제어는 결국 또 하나의 제어 접근법으로 밖에 안 보이는데~~~
뭐 그래도 fuzzy 나 neural network 나 다 가치가 있으니 학문으로 자리 잡았고, 상황에 따라 확실히 강력한 알고리즘의 기능을 보여주는 것 같다. (뭐 그래봤자 전혀 인공 지능으로는 보이지 않는다 ㅡㅡ;;)
내가 죽기 전에 정말 스스로 생각 및 창조하는 인공 지능을 볼 수 있을까????? 죽기 전에 보고 싶다~~~
역시 제어는 짬뽕 학문이다. 범재인 내 두뇌로는 괴로움만 커진다 ㅡㅡ;;;; 전통적인 제어 이론을 다루다가 지능 제어를 접하게 되면, 이건 뭐 그냥 거의 완전 새로운 분야다 ㅡㅡ;; 에휴~~~
그래도 역시 불행하지만 현실이 이러니 맨땅에 헤딩하면서 지능 제어를 한번 구현해 볼까 한다...
조만간 퍼지 제어에 도전해 볼 생각이다. Mamdani 은 쪼까 감이 오는데, sugeno 는 모르겠네, 뭐 이래봤자 수박에 겉핥기 수준으로 그냥 개념이 드디어 약간 보인다고 해야 하나...
부디 무사히 구현이 될 수 있도록 비나이다 비나이다~~~ (C/C++ 로 어떻게 구현하지 ㅠ.ㅠ 기본 소스 코드가 있었으면,,, 프로그래밍은 어렵다 ㅠ.ㅠ)
피드 구독하기:
글 (Atom)