1. A tiny c/c++ example of MAVLINK library howto

    MAVLink をc/c++プログラムから使う簡単な例です. MAVLinkの基本的なインストールや使い方については mavlink github のREADME.mdにある通りですなのですがc/c++プログラムから使う場合にはheaderだけでできている c_library_v2 を使うのがお手軽です.

    • STEP.1 git clone https://github.com/mavlink/c_library_v2.git
    • STEP.2 cloneしたc_library_v2をどこかに置いてそれがc/c++プログラムのincludeパスに入るようにします. これで準備はokです.

    基本的には

    #include <common/mavlink.h>
    

    でいろいろなMAVLinkのライブラリ関数が使えるのですが場合によってはそれだけではダメな時があります. 例えばtcpなどでMAVLimkのパケットをやり取りしたいときは上のREADME.mdに書いてあるようにMAVLINK_USE_CONVENIENCE_FUNCTIONSを定義するのですがこの場合には補助的な宣言が少しだけ必要です.

    arduinoのWiFiClientというtcp clientのライブラリクラスといっしょに使った時の例です.

    #undef F
    #include <mavlink_types.h>
    #define MAVLINK_USE_CONVENIENCE_FUNCTIONS 1
    #define MAVLINK_SEND_UART_BYTES send_tcp_bytes …
    read more
  2. hachidori - APM on PC with remote sensor/actuators

    hachidori

    hachidori はPC上で走らせたArduPilotで制御する実験的なリモートセンサ/アクチュエータで, ArduPilotプロジェクトへの寄与を目的に始まったDCoJAによる小さなプロジェクトです.

    私はDCoJAのメンバーであるドローンワークス社のコントラクターとしてArduPilotを同社が開発していたFCにポーティングする作業を行っていたのですがhachidoriはその中で派生したプロジェクトでした. 私とドローンワークス社とのコントラクトはすでに終了していますがオープンなプロジェクトとしてhachidoriの開発を続けています. プロジェクトの成果はDCoJAを通じてソフトウェアやプロトタイプの回路図などがオープンソースとして公開されています.

    scheme

    hachidoriからみるとArduPilotはセンサーデータを受け取りアクチュエータへの指示としてPWMの値を返すUDPサーバーです. このようなリモートセンサ/アクチュエータは実に古典的なアイデアですが,このスキームには大小様々な問題があります.

    とりあえずトイドローンタイプのhachidoriの飛行はこんな感じです:

    test flight

    これはstabilizeモードです. APM(ArduPilot)はうまく姿勢を制御できているように見えます. arducopterはlaptop PCのUbuntu 4.4.0-lowlatencyカーネル上で動かしています.

    250mmフレームにのせた別のhachidoriとAPMが動いているホストPCです:

    250frame 250 and PC

    実験的なhachidori用ドライバを含んだArduPilotのソースツリー等はDCoJAのgithubリポジトリ中のardupilotのhachidoriブランチにあります.

    hachidoriのファームウェアはesp-idf上のapplicationになっています. テストやコンフィグレーションのためのPC上の小さなUDPサーバーがjunkyardの中にあります. b3testはセンサーデータの表示やモーターのテストのためのサーバー, b3confは設定や定数などをhachidoriに書きこむためのサーバーです.

    レイテンシ latency

    このようなスキームでの大きな問題の一つがレイテンシです. ご存知のように私達が普通に目にするほとんど全ての無線プロトコルはレイテンシに重点を置いていません. Wi-Fiを除けばそれらはいつも低消費電力が歌い文句ですしWi-Fiはスループット優先です. これらのプロトコルには再送という操作が存在することが多くこれがレイテンシの大きな原因となっています. 物理的データを再送するとリアルタイム性を失いあまり意味がない場合があります. ドローンのIMUから得られるデータが0.2秒遅れて送られて来た場合それは制御にどの程度役立つでしょうか? このケースでは再送などせずにさっさと次のデータを送って欲しいのですがそのようなプロトコルは一般的ではなく、またWi-FiやBTのようにある程度オープンなものはありません …

    read more
  3. nRF24L01+ and ESP32

    Nordic semiconductorのトランシーバーnRF24L01+をESP32にSPI接続して実験してみました

    nrf24 spiclock to cs hold

    対抗しているのはRaspiとnRF24L01+の組でそちらは

    http://tmrh20.github.io/RF24/

    にあるライブラリやプログラムを使いました.

    このトランシーバーはBTやWiFiではなくShockburstという形式で通信します. コンフィグでACKを必要としないたれ流しができそうなのでレイテンシが減らせるか試そうと思っています. リアルタイムのIMUデータとかなんども再送されてもあまりうれしくないしというのがもともとの動機です.

    SPIでつなぐこと自体は簡単でGPIOの番号を

    #define PIN_NUM_MISO 19
    #define PIN_NUM_MOSI 23
    #define PIN_NUM_CLK  18
    #define PIN_NUM_CS    5
    

    としています. SPI以外にnRF24L01+のRFトランシーバーをイネーブルするCEと割り込みの/INTを

    #define GPIO_NRF24_INT  GPIO_NUM_22
    #define GPIO_NRF24_CE   GPIO_NUM_21
    

    につなぎました. SPIのコンフィグは

    spi_bus_config_t buscfg={
        .miso_io_num=PIN_NUM_MISO,
        .mosi_io_num=PIN_NUM_MOSI,
        .sclk_io_num=PIN_NUM_CLK,
        .quadwp_io_num=-1,
        .quadhd_io_num …
    read more
  4. ESP32 PHY board 2

    I'm trying another simple board for esp32 with ethernet. This is a board to mount ESP32 DevKit-C and Waveshare LAN8720 PHY module with a few extra parts. It can also use ESP-WROOM-32 chip directly instead of DevKit-C module.

    esp32-wslan8720 test esp32-wslan8720 board

    KiCAD files for this board can be seen here as hardware/esp32-wslan8720 …

    read more
  5. Madgwick filter 自分用メモ

    Madgwick filter(sensor fusion)のペーパーmadgwick_internal_report.pdfを再読してのメモ. 完全に自己流の理解です. madgwick_internal_reportは

    Open source IMU and AHRS algorithms

    にあります.

    Quaternionについてはわかりやすい解説がたくさんあるので詳しいことはパス.

    ただ次のことに注意:

    絶対値1のQuaternion q, q'を3次元球面上の点だと思うとq'=-qでない限り

    (t q + (1-t) q')/|t q + (1-t) q'|

    where 0 <= t <= 1 が球面上q,q'間の最短コース(測地線)になる. 2次元球面上の大円と同じ感じ.

    で、ノイズのこととかいったん忘れて

    • ジャイロで角速度がわかるので微小時間をかけると微小角変位つまり微小回転がわかる
    • それを現在までの回転に続けると微小時間後の回転q'が推定できる
    • 一方初期の方向から回転で得られた方向と加速度計やコンパスでわかる現在の方向の差が最小になるような回転qを勾配降下法で探す
    • これらの回転の推計(あまり変わらないに違いない)をQuaternionで表しておいてそれらを結ぶ(短い)測地線上に最良の答えがあるはずだと考える
    • t q …
    read more
  6. Testing ESPNOW

    ESP32の etherボード とESP32の センサボード でESPNOWでの通信を試して挙動を調べました. 全体の構成は

    esp32 ether-espnow brigde

    でPCの上ではarducopterとテスト用のUDPサーバの両方を動かして試してみました.

    結果

    現在のESP32のespnowは次のような挙動をするようです.

    • 近接で通信した場合latencyは2ms位で安定している
    • 送信と送信の間で間隔を空けることが必要で送信のみ繰り返す場合で~2msが必要に見える
    • 受信を行うとこの間隔が影響される

    実際のテストではセンサボードからespnowでパケットを投げ送信終了のコールバックが終わるまで待つようにしました. 送信のみの場合~500Hzぐらいのレートで~70byteぐらいのデータが送信できていました.

    100Hzのレートで~30byteほどを受信するようにすると送信側のレートは10%以上低下しました. 送受の切り替え時にデッドタイムがあることを想像させるような挙動ですが、espnowのライブラリはソースがないので確かなことはわかりません.

    このセンサボードからはIMUなどのパケットが1msに40byte程度でてくるのですが受信も行いながらだとパケットが最初に期待していたようなlatencyでは送り切れない状態が発生しています. 生のlatencyや処理コスト的にespnowは魅力的なのですが、リモートセンサ/アクチュエータ方式でコプターを飛ばすのは今の所少し厳しい感じです.

    read more
  7. ESP32 0.5ms tick

    You know that the maximal tick rate in ESP-IDF is 1000Hz.

    esp-idf menuconfig 1000Hz

    This is ok for almost applications and if you require sub-milli time precision, the extra timer or interrupt would be your friend. But why can't be 2000Hz tick rate set on 240Mz CPU? Here is a famous LED blinker …

    read more
  8. ESP32 PHY board

    I'm making a simple esp32 board with ethernet. ESP32 has MAC and esp-idf supports PHYs like LAN87x0 and TLK110 already. Here is the schematic with KiCAD:

    esp32-tlk110 schematic

    I'll create a git repository for that hardware if it works.

    Update 2017-10-21

    Now it works!

    esp32-tlk110 works

    Revised KiCAD files for this board can be …

    read more

« Page 2 / 3 »

links

social