Other articles

  1. Visual yaw estimation

    以前紹介した 室内測位システム ではフレームの姿勢をMAVLinkで貰ってるんですが室内なのとコアレスモーターがついてるせいでフレームに載せているコンパスがくるってしまい、それで得られるyawの値も酷いものなので代わりに天井のカムからみたマーカーで推定できるヘッドの方向を使っています.

    一般には斜め上からみることになるので頭と尾のマーカーがちょうど南北を向いているように見えても機体が水平でないと実際には南北を向いていません. 絵で書くとこんな感じになります

    figure

    wが機体の頭と尾のマーカーを結んだ直線の方向でカムからこれをみると方向がvであるかのように見えています. 実際は真上から見た方向v'をpitchの分だけ回転したのがwなわけです. 斜めになった緑の面Hはカムやvやwを含む平面です.

    なので問題は見かけの方向を機首の上げ下げの情報で修正する、つまり

    vとpitchからwを求める

    になります. 通常このような問題は回転行列や球面角で計算するのだと思うのですがgeometric algebraを使って求めることができます.

    Adjust yaw

    図のようにvをvとz-軸方向でできる面内でpitchだけ回転した黄色のベクトルの終点をPとしてこの点を通って水平に球上を回る円周Kを描きます. wの終点はK上にあるはずです. vとwを含む面Hはvとカムから球の中心への方向uとを含む面でもあるのでKとHの2つの交点のどちらかの表す方向がwになります. これらの操作はgeometric algebraでの簡単な操作に対応していてlibvsrだと

    auto bi = v ^ Vec(0, 0, 1);
auto rop = Gen::rot(bi*(-pitch_angle/2));
auto H = (PT(0, 0, 0) ^ v ^ u ^ Inf(1)).dual();
auto K = v.sp(rop …
    read more

  2. 貧者的局所測位系 The versorer's apprentice

    小さい機体でもSLAMこそが未来だと思うもののさすがに私では手がでないので貧者的局所測位系と名付けて天井に貼り付けたOpenMV cam+魚眼レンズとフレームからの情報を合わせてフレームにのせたマーカーの水平位置を推計するというのを作っています.

    OpenMV cam M7 + fish-eye + esp32 OpenMV ide

    魚眼レンズで得られるイメージセンサー上のマーカーの位置から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

  5. 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

links

social