이전에 포스팅한 Bixler 무인기를 자동비행으로 날려보았다.

제작 과정은 다음을 참조 http://kyubot.tistory.com/79?category=566605


비행 장소는 아래 그림과 같이 암사동 광나루 드론 공원이다. 

이번에는 이륙부터 경로비행 그리고 착륙까지 완전 자동비행으로 시도해보았다.


비행전 점검


자동비행으로 비행하기 전에 반드시 수행해야 하는 절차는 각 조종면이 움직임에 대해 올바로 반응하는지 확인하는 것이다.

비행기에 전원을 넣고 Stabilzation 모드에서 기체를 회전시켜 실제 조종면이 아래 그림처럼 동작하는지 확인해야 한다.

만약 반대로 움직이게 되면 비행기는 자동모드로 넘어가자마자 곤두박질 칠 것이다.


경로점 설정하기


바람 방향을 고려하여 북쪽으로 이륙 후 2차례 홀딩 패턴 비행을 한 다음 접근 및 착륙하는 간단한 미션을 설정하였다.



언제부터인지 모르겠으나 1.8.1 버전에서는 처음 경로를 설정하였는데 착륙 진입(landing approach) 경로점과 최종 착륙지점(Landing point)까지 landing flare (최종 접근 지점에서 부드러운 착지를 위해 고개를 들어올리는 기술)를 진행하기 위한 여유 거리, 방향 및 고도가 필요하다는 경고를 준다. 이 경고를 무시하면 자동 비행 자체가 진입이 안됨.


내용 추가

고정익 항공기의 착륙


착륙과 관련하여 PX4 에서 설명한 자료(https://docs.px4.io/en/flying/fixed_wing_landing.html)에 따르면 고정익 비행기의 착륙 로직은 아래 그림과 같은 2가지 단계로 이루어진다.

1. 먼저 착륙 접근 단계에서 고정익 비행기는 고정된 착륙 접근 각도(FW_LND_ANG)에 따라 진행한다.

2. 플레어 고도(FW_LND_FLALT)에 다다르면 플레어 경로(FW_LND_HVIRT에 설정된 커브)를 따라 착륙한다.


플레어 랜딩 고도는 고정익 항공기가 실제 지상으로 "간주"하는 고도에 대한 상대적인 고도이다.

착륙 모드에서 지면 고도는 알 수 없으므로 비행체는 그것을 해면고도(0m)로 사용한다. 대체로 지면이 해수면보다 높으므로 비행기는 첫번째 단계에서 착륙하게 된다(플레어 고도에 도달하기 전에 지면에 닿게 됨)


만약 비행기에 지면 거리를 측정할 수 있는 센서가 장착되어 있다면 위 그림과 같은 단계로 착륙하게 될 것이다.


착륙은 다음 파라미터에 따라 영향을 받는다.


파라미터 

설명

 FW_LND_ANG

플레어 전단계까지 적용되는 착륙 접근 각도

 FW_LND_HVIRT

 플레어 경로를 산출하기 위한 가상의 수평 라인/고도

이 값은 플레어 경로 커브가 점근적으로 사용하는 지면 고도이다.

 FW_LND_FLALT

 착륙 플레어 고도(착륙 고도에 대한 상대 고도)

 FW_LND_TLALT

 착륙 쓰로틀 제한을 적용하는 고도(착륙 고도에 대한 상대고도) 기본값 -1.0은 출력 제한을 플레어 고도의 2/3 지점에서 적용하기 시작한다.

 FW_LND_HHDIST

 착륙 헤딩을 고정하는 수평 거리

 FW_LND_USETER

 착륙 단계에서 추정된 지면 거리(GPS에서 나오는 지면 고도)를 사용한다.

이 기능은 기본적으로 Off된 상태로 경로점이나 리턴 고도(또는착륙 지점에 대한 가상의 해면 고도)가 사용된다.

FW_LND_FL_PMIN

플레어 시 최소 피치 각도. 양의 값은 FW_LND_TLALT에 도달했을 때 기수가 들림을 의미한다.

FW_LND_FL_PMAX

플레어 시 최대 피치 각도. 위와 동일

FW_LND_AIRSPD_SC

착륙중에 적용되는 최소 에어스피드 스케일 팩터 혹은 게인. 이 값을 비행기의 최소 비행속도에 곱하여 착륙 접근시에 목표 속도로 설정한다.

FW_AIRSPD_MIN x FW_LND_AIRSPD_SC



GeoFence 설정하기


안전을 위해 비행 경로 바깥으로 가상의 비행금지 구역을 설정한다.

파라미터 설정의 GF_ACTION  항목에서 Fence를 침범했을 때 경고만 줄지, 제자리에 있을지, 홈으로 돌아올지, 자폭(?)할지를 설정할 수 있다.




또한 시동걸기에서 자꾸 mag0 inconsistent 에러가 떠서 COM_ARM_MAG 파라미터를 0.15에서 0.25로 증가시켜주었다.

mag0 inconsistent 에러는 지자기 센서의 캘리브레이션 값이 나머지 mag 센서의 값과 차이를 보이는 경우를 의미하는데 gps센서에 장착된 컴파스 센서가 약간 틀어져서 나타나는 현상인듯 하다.


비행 결과


이륙은 ARM후 비행기를 이륙자세로 만들고 비행모드를 mission으로 변경한 다음 Throttle을 최대로 올리면 진행된다. 바로 모터가 돌지는 않는데 이때는 비행기를 살짝 흔들면 이륙 상태로 인식하는거 같다. 자세한 이륙 방법은 문서를 좀더 찾아봐야할듯.


추가됨

고정익 비행기의 이륙


PX4에 설명된 비행기의 이륙과정을 정리하면 다음과 같다.


비행기는 사출기/핸드런치 모드 또는 활주로 이륙 모드에서 현재 헤딩에 따라 이륙한다.

기본 모드는 사출기/핸드런치 모드이며 RWTO_TKOFF 파라미터에 따라 활주로 모드로 변경할 수 있다.

사출기/핸드런치 모드에서 비행기는 최대 출력으로 상승한다(약 2초간 RWTO_MAX_THR에 설정된 값 까지)

고도 에러가 FW_CMLBOUT_DIFF 보다 작으면 통상적인 항법으로 진행한다.

참고: 런치 디텍터(launch detector)가 특정한 조건을 만족시켜야 위에 언급한 절차가 수행될 수 있다. 사출기 런치의 경우 특정 가속도가 충족되어야 한다.

활주로 이륙 모드는 다음 단계를 따라 진행한다:

 1. Throttle ramp: 이륙 최소 속도(Minimum airspeed for takeoff = FW_AIRSPD_MIN x RWTO_AIRSPD_SCL)에 도달할 때까지 활주로에 고정(Clamp) 됨(피치, 롤, 헤딩 고정)

 2. Take off: 비행기 고도 > 항법 고도(RWTO_NAV_ALT)가 될때까지 피치를 상승시킴

 3. Climbout: 지면 고도(Altitude above gound level) > FW_CLMBOUT_DIFF 를 만족할때까지 상승. 이 단계에서 롤과 헤딩 고정 제한은 풀리게 된다.


이륙은 다음 설정 항목에 따라 영향을 받는다.


파라미터 

설명

 RWTO_TKOFF

 랜딩기어를 사용한 활주로 이륙. 기본값은 해제.

 RWTO_MAX_THR

 활주로 이륙 시 최대 출력.

 FW_CLMBOUT_DIFF

 Climbout 고도 차이.

 FW_AIRSPD_MIN

 최소 대기속도. 이보다 낮은 속도에서 TECS 제어기는 대기속도를 높이기 위해 보다 적극적으로 개입할 것이다.

 RWTO_AIRSPD_SCL

 이륙을 위한 대기속도 스케일 팩터. 대기 속도가 FW_AIRSPD_MIN x RWTO_AIRSPD_SCL 값에 도달하면 피치를 증가시키게 된다.

 WTO_NAV_ALT

 어느정도의 롤을 허용할 수 있는 지면 고도 (AGL).
RWTO_NAV_ALT 값에 도달하기 전까지 비행기는 수평(level)상태를 유지하며 러더만을 사용하여 현재 헤딩을 유지한다.(see RWTO_HDG). FW_CLMBOUT_DIFF > 0 인 경우 이 값은 반드시 FW_CLMBOUT_DIFF 보다 작아야 한다.


아래 동영상을 통해 PX4가 자동으로 착륙하는 모습을 잘 볼 수 있다.



처음에 이륙하자마자 비행기가 왼쪽으로 기우는 현상이 발생하였다. 되도록이면 다음 경로점 방향으로 던진다고 했는데 왜 이런 현상이 나타났는지는 좀더 분석이 필요할 듯.


마지막 착륙 접근에는 착륙지점에서 180m 거리에 최종 접근 지점을 설정하고 고도를 약 18미터 정도로 설정하였는데 예상보다 너무 낮은 고도였는지 착륙지점 근처의 높은 나무를 피할 수 없을꺼 같아서 아쉽지만 자동조종을 해제하고 수동으로 착륙하였다. 


사실 180미터 거리에 18미터 고도면 대략 6도 강하각이므로 그렇게 완만한 어프로치는 아닌데 다음에는 강하각을 더 크게 설정하거나 landing target을 좀더 뒤로 보내야할꺼 같다. 


비행 결과는 다음과 같다.

px4 비행로그 분석 사이트 (https://review.px4.io/upload)에 업로드한 비행 결과는 아래와 같다. 

자세한 비행 결과는 다음 링크에서 확인이 가능하다. (https://review.px4.io/plot_app?log=04d917f6-eeec-4d47-a1b2-95513b961a08)

보라색으로 표시된 선이 자동비행 경로이고 파란색 선은 manual 혹은 stabilized 모드를 의미한다.






최근에 업데이트된 px4 log 는 이렇게 입체적인 비행궤적도 표시해주고 각 해당 경로의 비행 자세와 조종기 입력도 관찰할 수 있다.



2018/12/2 최초 문서 발행됨.

2018/12/6 비행전 점검, 착륙접근에 관한 내용 추가

mac 에서 git 을 사용하기 위해 brew install 로 설치한 경우 2.19 이후 버전에서 터미널 언어가 한글로 표시되는 현상이 발생하였다.


$ git

usage: git [--version] [--help] [-C <path>] [-c <name>=<value>]

           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]

           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]

           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]

           <command> [<args>]


다음은 여러가지 상황에서 자주 사용하는 깃 명령입니다:


작업 공간 시작 (참고: git help tutorial)

   clone      저장소를 복제해 새 디렉터리로 가져옵니다

   init       빈 깃 저장소를 만들거나 기존 저장소를 다시 초기화합니다


변경 사항에 대한 작업 (참고: git help everyday)

   add        파일 내용을 인덱스에 추가합니다

   mv         파일, 디렉터리, 심볼릭 링크를 옮기거나 이름을 바꿉니다

   reset      현재 HEAD를 지정한 상태로 재설정화합니다

   rm         파일을 작업 폴더에서 제거하고 인덱스에서도 제거합니다


처음 보는 현상이라 당황스러운데 인터넷을 검색해보니 git 에서 gettext 라는 명령어로 인해 시스템의 언어를 감지해서 번역하는 기능이 추가되어 발생하는 현상이었다.

https://stackoverflow.com/questions/52430949/git-in-spanish-after-upgrade


이 문제를 해결하기위해서는 gettext 기능 없이 설치하는 방법이 있는데 

brew git install --without-gettext 는 인식하지 않는거 같다. 

그래서 아래 문서를 참조하여 직접 brew git 설치 명령어를 변경해야한다.

https://stackoverflow.com/questions/52426922/git-cli-in-russian-after-brew-upgrade/52592260#52592260


일단 기존에 설치된 git 을 삭제한다. 기존에 사용중인 git repository가 있는경우 의존성이 있으므로 아래 옵션을 추가하여 제거.


$ brew uninstall --ignore-dependencies git


설치 옵션을 변경하기 위해 다음을 입력한다.


$ brew edit git

이제 다음 부분을 찾아서 수정한다.



<<<
- depends_on "gettext"
+ depends_on "gettext" =>:optional
<<<
- args = %W[
+ ENV["NO_GETTEXT"] = "1" if build.without? "gettext"
+
+ args = %W[
<<<
:wq

이제 아래와 같이 입력하여 git 을 빌드하여 설치한다.


$ brew install -s git

다시 정상적으로 언어가 영어로 표시된다.


$ git

usage: git [--version] [--help] [-C <path>] [-c <name>=<value>]

           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]

           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]

           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]

           <command> [<args>]


These are common Git commands used in various situations:


start a working area (see also: git help tutorial)

   clone      Clone a repository into a new directory

   init       Create an empty Git repository or reinitialize an existing one


work on the current change (see also: git help everyday)


'Computer > mac' 카테고리의 다른 글

OSX 에서 아이튠즈 IOS백업 위치 변경  (0) 2018.05.31
Mac 에서 arm toolchain 설정하기  (1) 2017.04.26

아래의 최신 드론 FPV 영상을 보니 이제는 짐벌따위가 없어도 정말 깔끔한 영상이 나오는구나 하는 생각이 들었다.



드론에서 진동은 피할 수 없는 문제인데 이정도로 진동을 억제하기 위해서는 모터/변속기의 빠른 응답성능이 필수적이다.

그래서 최신의 변속기 동향을 살펴보니 400Hz 주기의 일반 PWM에서 Oneshot125등을 지나 Dshot이 대세로 자리잡은 듯 하다.

Dshot 에 대한 자세한 설명은 https://oscarliang.com/dshot/ 이곳의 글을 참고하면 된다.


About Dshot


Dshot에 관해 간단히 정리하면 다음과 같다.

PWM이나 Oneshot125,  Oneshot42 그리고 Multishot 과 같은 프로토콜은 펄스의 폭을 변조하고 FC에서 이 펄스를 읽는 방식을 사용한다. 

 이 방식은 간단하긴 하지만 전기적으로 Spike 가 발생할 수 있으며 펄스의 주기를 쪼개서 펄스의 최소 폭을 만들어야 하므로 짧게 만드는데 한계가 있다. 

 Dshot 은 이러한 한계를 극복하기 위해 FC에서 설정한 Throttle 값을 11bit의 0과1의 조합으로 패킷을 만들어서 직접 변속기에 데이트를 쓰는 방식을 채택했다. 데이터 무결성을 확보하기 위해 패킷에 4bit의 CRC를 추가하였다. 나머지 1 bit는 Telemetry Request용으로 할당.

이렇게 하면 0과 1을 만들 수 있는 최소 단위까지 패킷 을 전송할 수 있으므로 DShot600의 경우에는 600,000/16 = 37500Hz = 37.5KHz 의 주파수로 데이터를 전달할 수 있게 된다. 

이것은 최소 26.7uS 마다 Throttle값을 업데이트할 수 있음을 의미한다.


각 프로토콜별로 최소 업데이트 주기는 다음과 같다.


  • Oneshot125 – 250 uS
  • DShot150 – 106.7 uS
  • Oneshot42 – 84 uS
  • DShot300 – 53.3 uS
  • DShot600 – 26.7 uS
  • Multishot – 25 uS

수치상으로는 Multishot이 더 빠른데 25uS나 26.7uS 모두 FC의 제어 Loop 보다 빠르므로 큰 의미는 없다.


지원하는 ESC


이 프로토콜을 지원하는 변속기들은 다음과 같다.

BLHeli_S ESC : Cicada, Racerstar V2, Aikon SEFM, TBS 25A, Lumenier 30A, DYS XS30A

KISS ESC: KISS 24A ESC

이번 드론 제작을 위해서 http://rctimer.com/?product-1744.html 에 있는 

BeeRotor BS20A ESC를 구매하였다.


지원하는 FC


이 글을 작성하는 현재(18/11/05) Dshot 프로토콜을 지원하는 FC는 F3와 F4 계열이다. 

나는 아래 링크에서 Beerotor F4 보드를 구매하였다.

http://rctimer.com/?product-1730.html


모터는 기존에 구매했던 제품을 그대로 사용하기로 했다.

Rctimer FR1806-2300KV High Power FPV Racing Edition Motor

http://rctimer.com/?product-1570.html



드론 프레임


조립의 편의성을 위해서 PDB가 포함된 제품으로 구매하였다. PDB가 없으면 납땜이 많아져서 시간을 많이 잡아먹는데 이 제품은 위에서 구매한 FC에 커넥터로 연결되고 ESC 전원단에 AL 캐패시터가 포함되어 안정적인 전원공급이 가능하다.

BeeRotor Thunderbolt 190 4mm FPV Racing Quadcopter with PDB

http://rctimer.com/?product-1705.html



드론 조립하기


드론 조립은 RCGroup에 나온 제작 과정을 참조하였다.  https://www.rcgroups.com/forums/showthread.php?2797008-BeeRotor-Thunderbolt-190-FPV-Racing-Quad-5-Prop-Build-and-Discussion 


이 키트는 모든 배선들이 납땜만 하면 조립할 수 있도록 준비되어있어 매우 편리하다.

불과 몇년전만 하더라도 전선을 일일이 자르고 납땜해서 연결해야했는데 격세지감이 느껴진다.


납땜을 깔끔하게 하기 위해서는 스트리퍼로 노출한 전선 가닥을 페이스트에 묻히고 먼저 1차로 납을 녹인 다음 보드에 납땜하는것이 좋다. 아래 그림 참조.


순서는 다음과 같다.

1-2

3-4


조립 결과는 아래 사진과 같다.



깔끔하게 잘 마무리 되었다.






드론 커버 및 카메라 마운트 장착 (추가 2. 3D file 추가)


아무래도 이런 조립식 드론은 회로가 외부에 노출되어 있다보니 외부의 먼지라든지 이물질의 유입으로 인한 물리적 손상이나 쇼트가 발생할 수 있다. 그래서 3D프린터로 간단히 커버를 만들어 보았다.

모델링은 도면이 없으므로 실제 기체를 실측하여 제작하였다. 만들다보니 완벽주의 버릇이 도져서 세번이나 출력한 끝에 아래와 같은 모습으로 만들 수 있었다. 세로로 긴 홈은 상부의 카본 마운트가 꽂히는 공간이다. 이게 없으면 커버에서 들뜨게 된다.


드론 회로 보호용 커버의 장착 모습


아래는 FPV용 카메라를 장착하기 위한 마운트를 3d 프린트하고 장착한 모습이다. 



위 커버의 디자인 파일은 Thingivers 사이트에서 다운로드 받아서 3d프린터로 출력할 수 있다.




Betaflight 설정하기


설치하기

betaflight 는 FC를 설정하기 위한 프로그램이다. 이 프로그램이 있어야 FC에서 사용하는 ESC에 맞는 프로토콜을 설정할 수 있다.

Chrome 브라우저에서 좌측 상단의 Apps를 선택하고 betaflight를 검색하면 설치할 수 있다.


Firmware 업데이트하기


설정을 진행하기 전에 펌웨어의 버전을 확인하고 최신 버전으로 업데이트할 필요가 있다.

이 글을 작성하는 현재 BeerotorF4의 최신 버전은 3.5.2를 지원한다.


VCP 드라이버 설치


BeerotorF4의 펌웨어를 업데이트하기 위해선 STM32 마이크로 프로세서에 내장된 DFU 모드를 통해 내부 Flash에 프로그램을 업로드해야 한다. 이 방식을 사용하기 위해서는 STM VCP 드라이버가 설치되어야한다.

ST의 해당 사이트(https://www.st.com/en/development-tools/stsw-stm32102.html)로 이동하여 하단의 GET SOFTWARE 항목의 STSW-STM32102 을 다운로드한다.

압축을 풀고 설치된 OS에 맞는 드라이버 버전을 설치한다. 

Windows10 64비트의 경우 VCP_V1.5.0_Setup_W8_x64_64bits.exe 파일을 실행


DFU 드라이버 업데이트


Windows에서 설치하는 경우 DFU드라이버를 사용하기 위해서 zadig를 설치한다.

1. 다음 링크(http://zadig.akeo.ie/)에서 Zadig를 다운로드한다.

2. FC를 DFU모드로 부팅하기 위해 아래 그림의 버튼을 누른 상태로 Micro USB커넥터를 PC에 연결한다.


3. 다운로드한 Zadig를 실행한다.

4. Option > List All Devices 선택



5. Dropdown 메뉴에서 STM32 BOOTLOADER 를 선택한다.

6. 녹색 화살표 오른쪽의 box에서 WinUSB (v6.1.7600.16385) 항목을 선택한다.

7. Install driver 버튼을 눌러 드라이버를 설치한다.

8. 설치가 완료되면 FC에 USB커넥터가 꽂혀있는 상태로 재부팅을 한다.


Firmware 설치하기


재부팅이 완료되면 Chrome실행 후 Apps 에서 Betaflight를 선택하여 실행한다. 

1. 먼저 우측 상단의 Device가 DFU로 선택되었는지 확인한다.

2. FC에 맞는 펌웨어 버전을 선택한다. (다른 버전을 선택하면 벽돌이 될 수 있으므로 주의)


3. 아래로 내려가서 Load Firmware를 눌러 펌웨어를 다운로드한다.


4. Flash Firmware를 선택하여 펌웨어를 업데이트한다.



BETAFLIGHT 설정하기


이제 FC를 재부팅하여 설정을 진행한다.

USB를 연결하고 우측 상단의 Connect 버튼을 누르면 연결이 완료된다.


좌측 메뉴에서 톱니바퀴모양 Configuration 버튼을 선택

  • ESC/Motor Features 에서 DSHOT600을 선택한다.
  • MOTOR_STOP을 선택하면 Arming되었을때 모터가 회전하지 않는다. (착륙 후 완전히 멈추었는지 확인하기 위해서는 해제하는것이 좋다.)


  • Receiver 항목에서 SBUS로 설정되었는지 확인한다.

Save and Reboot을 누르면 저장하고 다시 시작한다.


이제 좌측 메뉴에서 Modes 로 이동

조종기의 ARM 스위치 설정

비행 모드 설정을 진행한다. 


여기까지 완료하면 비행준비가 완료된 것이다.


2018/11/7 일부 내용 추가됨

2018/11/14 드론 커버, FPV카메라 마운트 추가됨

2019/1/30 드론 커버 디자인 파일 공유



+ Recent posts