Screen shot of opemMV IDE
I've tried to make a simple and budget local positioning system with openMV cam for the indoor flight of tiny copter. Looks not so good precision but not so bad as a Poor Man's system. A LOITER and LAND flight test with my hachidori copter …
read more小さい機体でもSLAMこそが未来だと思うもののさすがに私では手がでないので貧者的局所測位系と名付けて天井に貼り付けたOpenMV cam+魚眼レンズとフレームからの情報を合わせてフレームにのせたマーカーの水平位置を推計するというのを作っています.
魚眼レンズで得られるイメージセンサー上のマーカーの位置からcamからの方向を計算してマーカーの高さの情報をヒントにマーカーのcamを基準にした水平位置をだしてます. このセンサ上のマーカーの位置から3Dの方向を計算するところはいわゆるステレオグラフィックプロジェクション(立体射影)になっていて、三角関数や線形代数を使って計算できます.
前置きが長くなりましたがフレームの水平位置を求めるところまでをgeometric algebraを使ったらどうなるか試してみました.
auto pointO = Construct::point(0,0,0); auto pointP = Construct::point(0,0,-h); auto v = - Vec(x,y,-1) * Vec(0,0,1) / Vec(x,y,-1); auto line = pointO ^ v ^ Inf(1); auto dlp = (pointP <= Drv(0,0 …read more
Hachidori which means 'humming bird' is a remote sensor/actuator board controlled by ArduPilot running on PC. It's intended to contribute to ArduPilot, though it's still in the experimental phase. It's a tiny open project of DCoJA started by DroneWorks Inc. I was a contractor with DroneWorks mainly for porting …
read more
hachidori はPC上で走らせたArduPilotで制御する実験的なリモートセンサ/アクチュエータで, ArduPilotプロジェクトへの寄与を目的に始まったDCoJAによる小さなプロジェクトです.
私はDCoJAのメンバーであるドローンワークス社のコントラクターとしてArduPilotを同社が開発していたFCにポーティングする作業を行っていたのですがhachidoriはその中で派生したプロジェクトでした. 私とドローンワークス社とのコントラクトはすでに終了していますがオープンなプロジェクトとしてhachidoriの開発を続けています. プロジェクトの成果はDCoJAを通じてソフトウェアやプロトタイプの回路図などがオープンソースとして公開されています.
hachidoriからみるとArduPilotはセンサーデータを受け取りアクチュエータへの指示としてPWMの値を返すUDPサーバーです. このようなリモートセンサ/アクチュエータは実に古典的なアイデアですが,このスキームには大小様々な問題があります.
とりあえずトイドローンタイプのhachidoriの飛行はこんな感じです:
これはstabilizeモードです. APM(ArduPilot)はうまく姿勢を制御できているように見えます. arducopterはlaptop PCのUbuntu 4.4.0-lowlatencyカーネル上で動かしています.
250mmフレームにのせた別のhachidoriとAPMが動いているホストPCです:
実験的なhachidori用ドライバを含んだArduPilotのソースツリー等はDCoJAのgithubリポジトリ中のardupilotのhachidoriブランチにあります.
hachidoriのファームウェアはesp-idf上のapplicationになっています. テストやコンフィグレーションのためのPC上の小さなUDPサーバーがjunkyardの中にあります. b3testはセンサーデータの表示やモーターのテストのためのサーバー, b3confは設定や定数などをhachidoriに書きこむためのサーバーです.
このようなスキームでの大きな問題の一つがレイテンシです. ご存知のように私達が普通に目にするほとんど全ての無線プロトコルはレイテンシに重点を置いていません. Wi-Fiを除けばそれらはいつも低消費電力が歌い文句ですしWi-Fiはスループット優先です. これらのプロトコルには再送という操作が存在することが多くこれがレイテンシの大きな原因となっています. 物理的データを再送するとリアルタイム性を失いあまり意味がない場合があります. ドローンのIMUから得られるデータが0.2秒遅れて送られて来た場合それは制御にどの程度役立つでしょうか? このケースでは再送などせずにさっさと次のデータを送って欲しいのですがそのようなプロトコルは一般的ではなく、またWi-FiやBTのようにある程度オープンなものはありません …
read moreNordic semiconductorのトランシーバーnRF24L01+をESP32にSPI接続して実験してみました
対抗しているのはRaspiとnRF24L01+の組でそちらは
にあるライブラリやプログラムを使いました.
このトランシーバーは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
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.
KiCAD files for this board can be seen here as hardware/esp32-wslan8720 …
read moreESP32の etherボード とESP32の センサボード でESPNOWでの通信を試して挙動を調べました. 全体の構成は
でPCの上ではarducopterとテスト用のUDPサーバの両方を動かして試してみました.
結果
現在のESP32のespnowは次のような挙動をするようです.
- 近接で通信した場合latencyは2ms位で安定している
- 送信と送信の間で間隔を空けることが必要で送信のみ繰り返す場合で~2msが必要に見える
- 受信を行うとこの間隔が影響される
実際のテストではセンサボードからespnowでパケットを投げ送信終了のコールバックが終わるまで待つようにしました. 送信のみの場合~500Hzぐらいのレートで~70byteぐらいのデータが送信できていました.
100Hzのレートで~30byteほどを受信するようにすると送信側のレートは10%以上低下しました. 送受の切り替え時にデッドタイムがあることを想像させるような挙動ですが、espnowのライブラリはソースがないので確かなことはわかりません.
このセンサボードからはIMUなどのパケットが1msに40byte程度でてくるのですが受信も行いながらだとパケットが最初に期待していたようなlatencyでは送り切れない状態が発生しています. 生のlatencyや処理コスト的にespnowは魅力的なのですが、リモートセンサ/アクチュエータ方式でコプターを飛ばすのは今の所少し厳しい感じです.
read morePage 1 / 2 »
