ラベル 倒立振子 の投稿を表示しています。 すべての投稿を表示
ラベル 倒立振子 の投稿を表示しています。 すべての投稿を表示

2015年12月4日金曜日

Arduino とレゴで倒立振子(3)電源の性能

かなり前に
という記事を書きましたが,その後これに関連して学会発表をしたり特集号の記事を書いたりしてブログの更新を忘れていました.

特集号の記事は
にあります.現在は計測自動制御学会の会員でないと全文が読めませんが,一年後(2016/3)から無料で読めるようになるはずです.

また,記事の補足として実験機が動作している動画を公開しておきます.


この実験は安定化されているモバイルバッテリーを電源にしていることのメリットを示すためのもので,ギリギリ安定化できている程度の性能が悪い(=よく揺れる)制御器でも14時間程度連続して倒立しており,電源の消費によって実験の再現性が損なわれていないことを確認するものです.

制御器を完全にチューニングすれば持続時間は日単位になると思いますが,あまり意味がないわりに面倒な実験なので試していません.長時間動作させる実験では,地面の起伏とタイヤの滑りで倒立振子が予想できない方向にじわじわ動いていくために,意外と広い実験場所が必要になることと,実験を記録するためのカメラの持続時間が問題になります.もし同様の実験をされる方がいらっしゃいましたら参考にしてください.

3年間授業でこの倒立振子を使っているうちに,いくつか新しい技術が利用可能になり,改善したい点もでてきたので,そのうちまた実験機と記事をアップデートすると思います.

2014年7月27日日曜日

three.jsでブラウザ上で動くインタラクティブな倒立振子シミュレータを作る

引っ越しを機に研究室のサイトを現代的に改装することになりました.

上の倒立振子振り上げアニメーションはサイトのトップページを15年間飾っていた年代物ですが,これもその一環として現代の技術水準で更新することにしました.目標は滑らかでインタラクティブ(ユーザーが外乱を与えて制御系の反応を観察できる)なアニメーションを設置することです.
そのためには
  • ブラウザでリアルタイムに動作する倒立振子振り上げ制御器を実装する
  • ブラウザでリアルタイムに倒立振子の3Dグラフィックスを描画する
必要があります.今後改装を行うときのために,これらのポイントについてメモしておきます.
なお,完成品は以下の様な感じです.


手での操作が可能な完全版は研究室のトップページ

リアルタイム倒立振子振り上げ制御

ユーザーが与える外乱は事前に予測不可能なので,ブラウザ上でリアルタイムに動作する制御器で2本の倒立振子の振り上げを実現する必要があります.最高の効率(最小の制御動作)でこれを行うことは非常に困難な問題ですが,効率に目を瞑ればそれほど難しい問題ではありません.今回はインスピレーションで簡単な切替え制御則を設計しました.実装は
にあります.振り上げたあとの安定化は研究室内学生実験の成果を利用しています.ちなみに倒立振子のモデルは
です.基本的にはアーム部分の加速度を自由に制御できる物として運動方程式を立てただけですが,リアリティを出すためにモデルでもモーターに速度リミッターをつけています.
なお,実装において必要となる演算には Numeric.js を利用しました. Numeric.js は行列計算に加えて数値積分のルーチンまで持っているので,倒立振子シミュレータもこの機能を使って実装しています.
倒立振子のシミュレータに物理エンジンを使えば後々おもしろい拡張も可能かと思いましたが,現状では少し動作が重いようだったので割愛しました.自分のサイトでは重さを度外視して物理エンジンを使ったセグウェイライクな自走式倒立振子シミュレータを設置しているので興味があれば遊んでみてください.

ブラウザ上での倒立振子の3D描画

15年前にはブラウザ上でリアルタイムに3Dグラフィックスを描画するのはほぼ不可能でしたが,最近はブラウザ上でもWebGLという標準仕様で効率的に3Dグラフィックスを描画することができます.しかしWebGLを使って直にプログラムを書くのは大変手間らしく,three.jsというのを使うのが楽なようです.

実際 three.js を使った描画は非常に簡単で,MATLAB用の描画プログラムから特に苦労することもなく倒立振子を描画するルーチンを作成することができました.ただ,作ってから気がついたのですが
  • safari (iPhoneのブラウザ) が WebGL にデフォルトで対応するのはおそらく9月
  • Windows上ではWebGLで DirectX が描画に使われる関係で太い線を描画できない
という問題があったので,現時点では three.js の renderer として WebGLRenderer ではなく CanvasRenderer を使っています.
それほど複雑な物体を描画するわけではないので,こちらのほうが多くの環境で快適に動作するはずですが,何年かしたら WebGLRenderer に切替えてもいいかもしれません.

その他

ワイヤーフレームでの四角形面の描画について

three.jsは,あるバージョンから四角形面を描画する機能が省かれた(3角形2つに分割される)ようです.通常の描画であれば全く問題ありませんが,ワイヤーフレームで描画した場合線が増えて鬱陶しいので,やや古いバージョン(r59)を使っています.最近もバージョンアップで描画性能が向上しているようなので,状況が変われば three.js のバージョンを上げるべきかも知れません.

背景の写真との整合について

背景の写真と倒立振子でパースが狂っていると気持ち悪いので実物の倒立振子が写真に写っていた場合と同じ見え方になるように計算しています.
といってもthree.jsのカメラ設定時に写真撮影時と同じ情報を指定するだけです.
なおthree.jsに指定する画角は画面の縦幅に対応する画角なので,$d$をレンズ焦点距離,$h$をカメラのセンサーの縦幅として
\[
2\tan^{-1}\left(\frac{h}{2d}\right)
\]
で計算される角度にすれば良いと思います.

safariでテクスチャが歪む問題について

three.js の CanvasRenderer と safari (iPhone iPad 等の mobile safari 含む)の組み合わせでテクスチャが正しく表示されない問題がありました.
safariのバグらしいのでそのうち直るかもしれませんが,とりあえずgithubのこのコメントにしたがって
texture.wrapS = texture.wrapT = THREE.RepeatWrapping;
texture.repeat.set( 1, 1 );
とすると正常に表示されます.


2013年8月17日土曜日

Android タブレットで倒立振子

突然ですが,諸般の事情で Android タブレット(Nexus 7)を制御器としたセグウェイっぽい自走式倒立振子を作りました.忘れないうちに製作の要点をメモしておきます.後日気が向いたときに詳細な記事を書くかもしれません.
Android タブレットは内蔵するジャイロセンサで角速度を計測し,モータに印加する制御入力の計算を行います.腕のように見えるのはレゴブロックで作られたバンパーで転倒時と机からの落下時に液晶画面を守ります.

IOIO-OTG と HUB-ee Wheel による製作容易なハードウェア

ハードウェア的に特に重要な部品は IOIO-OTG と HUB-ee Wheel です.


上の写真が IOIO-OTG で,これを介して Android からモータを駆動することができます. いわゆる ADK と似たような機能を持ちますが小型であることをはじめとして,様々な面で扱いやすいと思います.


上の写真は HUB-ee Wheel で,一見タイヤに見えますが中にモータ・モータドライバ・エンコーダを内蔵している便利部品です.エンコーダがかなり粗く(4逓倍で128カウント/回転)カウンタを内蔵していない点が少し残念ですが,レゴブロックと簡単に結合でき,ハードウェアの製作を飛躍的に簡単にしてくれます.

また,今回は適当な Nexus 7 専用ケースに両面テープで電池などの部品とレゴブロック2本を接着し,あとはレゴブロックを嵌め合わせることで HUB-ee Wheels を固定し,バンパーなどを構築しています.


制御器の連続時間実装

ソフトウェア,つまり制御理論の面でやや特殊なのは制御器の連続時間実装を行っている点です.というのも,Android は非リアルタイムOSで一定周期でのジャイロセンサによる計測や制御入力の更新が困難だからです.実際 IOIOLib Application Framework で何も考えずに制御ループを回したときの実行間隔は以下のようになります.


概ね 5 ms 程度の間隔でループが回っているものの 20 ms 以上の間隔になることもしばしばあり,離散時間システムとしての実装には多少無理があることがわかります.

倒立振子のモデリングと制御器の設計は特に特殊なところはありません.

今後の課題

現状では IOIO-OTG がエンコーダのカウントをサポートしておらず,Androidのソフトウェアによる計数を行っているので,高速に移動したり制御周期が長くなったりするとエンコーダの取りこぼしが発生してしまいます.

本来なら Android 端末を使った自走式倒立振子のメリットとして,カメラやネットワークを簡単に利用できることが挙げられるべきですが,この問題のために制御周期への影響が大きいと考えられるこれらの機能が使いにくいのが残念なところです.

本格的に遊ぶためにはエンコーダ用のカウンタ回路を IOIO-OTG の外部に設けるべきであると考えられます.


2012年4月30日月曜日

Arduino とレゴで倒立振子(2)モータドライバの設計

前後の記事は
です.

少しずつ書いている実験用倒立振子製作メモですが,今回はモータドライバの設計について説明します.前回述べたようにモータの電流制御を行う必要があることと電源がUSBであることを踏まえると,モータドライバには
  • モータ電圧5V,ロジック電圧5Vで動作
  • 電流容量1A以上
  • 31kHz程度で電圧をON/OFFすることが可能
といった性能が求められます.電圧・電流に関する条件はUSBバスパワーの仕様から直接生じるものですが,最後の条件は電流制御に必要とされるPWMキャリア周波数によるものです.

2012年4月22日日曜日

Arduino とレゴで倒立振子(1) 設計意図

続きの記事は
  • Arduino とレゴで倒立振子(2)モータドライバの設計
  • Arduino とレゴで倒立振子(3)電源の性能
  • です

    4コマ(6時間)で制御工学を履修していない学生さんに倒立振子を制御してもらうという大変責任重大な学生実験の担当を拝命しました.

    引き継いだ実験装置もあったのですが,20年前のPC-9801で動いており,たまにエラーが出る状況だったので,学生実験に最適化したシステムに入れ替えようと思い立ち,マイコンは Arduino,機械部分はレゴというちょっと変わった構成で倒立振子を製作しました.

    実験装置の外観


    予備機製作の際のマニュアルも必要ですし,製作に必要な情報を徐々にブログにまとめていこうかと思います.第一回はこの実験装置の設計で特徴的なところをまとめ,大雑把な設計意図について説明します.

    2008年7月31日木曜日

    LQGによる倒立振り子の制御実験

    久しぶりにロボット的なものを作りたくなったので
    どうせなら制御理論の検証ができるものを…
    というわけで、Segway的な倒立振り子を作ってみた。

    全体図



    機械部分は入手性がよくて組み立て簡単な田宮模型の部品で固めました。
    本体はユニバーサルプレートで、たまたま手に入った透明プラスチックバージョンを使ってます。
    車輪はナロータイヤセット、ギアはハイパワーギアボックスHEだったと思います。
    もうちょっとギア比が低いハイスピードギアボックスの方がベターかもしれません。

    電池ボックスは熱に強い金属のやつを買ってきました。
    一度熱で端子付近のプラスチックが溶けたことがあるので…

    回路を実装する基板はSunhayatoのICB-88

    電池ボックスも基板もいい感じにユニバーサルプレートにくっつきます。

    回路


    回路も今後の補修のために部品の入手性がいいやつで…

    右の緑色の基板はトランジスタ技術の付録についてたR8C/Tinyの基板です。
    これはSunhayatoからも互換性のあるものが出てますね。

    真ん中の青色はSunhayatoの加速度センサーモジュールMM-2860

    左の青い基板は同じくSunhayatoのモータードライバモジュールMM-531です。
    電流容量0.7Aは心もとないので、2回路をパラレルにして使っています。
    同じチップなら特性もわりとそろっているので問題ないと思いますが
    あんまり誉められたもんじゃないですね。

    左下のディスクリート部品的な部分で2.4Vの電源から3.3Vの電源を作ってます。
    モーターの電源は電池直結です。

    右端のコネクターはE8aエミュレータを接続するためのもので
    上の3線は角速度ジャイロ(KRG-3)
    下の2線はデバッグ用のブザー
    左の4線は電池とモーターです。

    側面




    機械部分にあんまりこりたくないのでユニバーサルプレートと
    ねじとスペーサーでしのいでいます。
    基板を固定するビスがかなり長いのは転倒時に基板が地面に当たるのを防ぐためです。

    モーター



    モーターについてるセラミックコンデンサはブラシで発生するノイズを
    吸収するためのものです。
    マイコンと一緒にDCモーターを使う場合には必須らしいです。
    たしかに昔PICマイコンを使ってたときにはこれで誤作動しなくなりましたが
    最近のマイコンでも必要なのだろうか…

    ちなみにエンコーダはついてないので
    車輪の回転角は制御していません。角速度のみの制御です。

    制御



    最初は適当にPID的な制御でも立つかなーと思っていたのですが
    意外とチューニングに苦戦したので
    おとなしくモデルを構築してLQGを使ってみました。
    制御器が不安定システムになるようなので
    まぁなるべく極が左の方に来るように調節しています。
    制御器は3次のシステムで制御周期は10msです。
    R8Cでこの制御周期だと5次くらいまでなら何とかなるかな〜という感じでしょうか。

    やっぱりモーター周りのモデルが怪しいのですが、
    ロバスト制御の代名詞であるH∞制御とかだとこの手の怪しさは扱いにくいですね。
    そのあたりを扱える理論が必要なのだろうか…