開発日誌(34)
■３月１日■
今年はできるだけ月ごとに改ページしよう。
この先どうやって歩行の安定化を進めようか。 強化学習の方法は？？？ と考えあぐねていたのだが、なんにせよフィードバックするためのセンサーが必要なことに気がついた。
とりあえずZMPの測定とジャイロは必要だろう。 ということでごそごそと倉庫を探して出てきたのが、
秋月のジャイロと感圧センサー
感圧センサーは8個いるので、これが使えそうだったら買ってこよう。 取り込みをどうするか。ジャイロが2チャンネル、感圧センサーは8チャンネルのADCが必要。 テストはCoronでやるとしてラムダに組み込む時は10チャンネル測定できるようにせねばならない。
ジャイロは評判のよくないやっすーい秋月ジャイロなのだが、積分値を取らなきゃ温度ドリフトは関係ないわけだからこれでもいいんじゃないかと。足裏センサーと併用するならば角度まで知る必要ないんじゃないかと思ってみたり。
センサーはぼちぼち準備するとして、物理シミュレーションをどのように利用するかを考えていた。 Goシミュレーションってサーボ特性って入力できるんでしたっけか。
ZMP規範で計算した歩行モーションだと、理想的なサーボを使えばもちろん歩けるはず。 悪路だとだめだけど。。 でも、27日の実験のように、歩行速度を上げたり歩幅を広げたりするところでサーボの能力の限界を超えると再生精度が落ちる。 そこんとこをシミュレーションできないとモーションのテストにはならんなぁと。
ここからはGoシミュレーション！がサーボの特性を反映できないとしてのことなのだけど、（Webで見る限りできないような気がしているので）
サーボモーターがどのような系で表現できるのかなぁとちょっと調べてみたのだが、ずばりコレというが見つからない。伝達関数でいえば１次遅れ系らしいのだけど、Goシミュで動かすのは動作点での話なので伝達関数については触れないでよいかと。 それよりも負荷特性の方が問題です。
負荷特性は短時間で見ればDCモーターの動きなわけだから、単純に速度-トルク特性を適用すればよい、 と思う。
4014の負荷特性
そして、この特性カーブのどのポイントを使えばよいかは、関節負荷計算の結果を適用し、その時の速度限界値を利用する。 そうすれば負荷が大きくなってサーボがついていけない様子を計算することができるはずです。 ・・・おもしろそうだからやってみようかな。。
そうして求めた関節角度がサーボモーターの負荷特性を反映したモーションデータということになる。でも、その時のZMPくらいまでは計算できちゃうんだよな。 物理シミュレーションやる意味なかったりして（笑。
ちなみにフィードバック系とか外乱とかを加えた時の振る舞いを確認することはできるはずなので意味無くは無いです。
■３月２日■
昨夜は日誌をアップしてからジャイロに通電して動作確認などしておりました。CoronのCPUはADCを3本持っているらしいのだけど、端子に出ているのは5本。 1本のADCを複数のポートでスキャンできる仕組みらしい。
なのでSTM32ならば両足の圧力センサーとジャイロとか加速度センサーとかなんでも組み込めそう。
Coronはでかいのでストロベリーリナックスで売ってるSTM32のちっこいCPUボードを使おうかな。
今日は早速サーボの遅れの計算をしてみようかと思ったのだけど、時間的には足りなさそうだったので、UVCカメラから画像データを取り出すコードの調査。 UVCカメラを使ったアプリのソースを眺めていました。
デバイスの設定だけやればあとはどんどんとデータを取り出せる感じらしい。 uvc-streamerなんかはカメラがモーションJPEGに対応していることが前提なので、カメラの設定して、データストリーム作ってデータを投げ続けているだけでした。
カメラから画像を取り出してJPEGファイルに格納するプログラムの方がコードが長かったりする。
初代ラムダの時の画像処理プログラムはYUVフォーマット前提で書いてたので、今回も手っ取り早くYUVでやりたい。 すると動作確認のクライアント側のプログラムの方が面倒かもしれないな。
視覚化処理はなにかと面倒なんだけど、デバッグの効率考えると大事だしなぁ。 UVCの前にクライアントプログラムをVisual C++ 2010EEに移植せねば。
プロジェクトのインポートってできないのかな？ それ以前に当時のプロジェクトがそのまま使えたらいいんだけどな。
■３月４日■
サーボの負荷特性を反映してサーボモータの遅れやオーバーシュートを計算してみようかと思ったが、検討した結果、手抜き計算であってもそこそこ大変であることがわかった。
歩行モーションから関節負荷の計算はできるのだが、負荷を計算するには空間速度・空間加速度が必要で、それには関節の角速度・角加速度が必要。
つまりモーションが確定していないとならないわけだから卵が先か鶏が先かって話になる。
一度今までの計算で関節負荷を計算したあと、その関節負荷を使ってモーションからの遅れ・ずれを計算し、またその結果から関節負荷を計算すると、差分がなくなったのが結果ってことですね。
うまくいけばいままでよりも効果的な補正モーションを計算できる。 GOシミュレーション！がバージョンアップするまでにやってみよう。
Visual C++2010EEで、古いVC++のプロジェクトを開くと自動的に変換をかけてくれたのだけど、まったく使い物にならなかった。 やはりこつこつと移植せねばならないか。 以前にVB6からVC++にトランスレートかけたときもひどい有様だったのだけど、マイクロソフトはまじめに変換ツールを提供しているつもりなのかな？
■３月５日■
失敗です。
サーボモータの負荷特性をモーションに反映する試みですが、まだ考慮が足りないようです。
もっとも大きなずれが起こっている股関節ロール軸のサーボの、負荷を加味した限界速度を算出してみたら、
青が速度で赤が限界速度。 ぜんぜん余裕があります。
股関節ロールはオーバーシュートなのだけど、アンダーシュートとなるピッチ軸でみると、
限界オーバーするところが見えました。 アンダーはこれでいいけど、オーバーはまだ要素があるんですね。アンダーはついていってないから速度でいいけど、オーバーってのは変化についていけないのだから加速度なんだろうな。モーターの負荷特性だけじゃなくて負荷変動特性が必要ってことかな。
これはちょっと置いておいて、ZMP測定とそれを使ったフィードバック歩行と、Beagleboardでの画像処理に軸足を移していこう。
■３月６日■
金曜日に出張先から注文したCPUボードが届いたので早速立ち上げを。
買ったのはストロベリーリナックスのSTBee-mini。 Coronと同じSTM32のCPUボードなのだが、Coronに比べて小ぶり。
クロック72MHz、フラッシュ128kBでRAMが20kBあるので大抵は大丈夫かと。シグマもこれで動かせるんじゃないかな。
ADCは10ch、UART×１とI2C×１、 上位との通信にSPIを使いたかったのだけど、ADCとかぶっているのでUARTでなんとかするしかないか。
プログラムの書き込み方法はCoronと同じで、DFUってので書くのだけど、ストロベリーリナックスが提供しているDFUWってのが便利。 コマンドラインから起動してHEXファイルを指定すればDFUに変換してCPUに書き込むところまで一気にやってくれます。 Coronもこういうの提供して欲しかったですね。 ま、これでCoronも書き込めるはずだけど。
シグマのプログラムから不要な部分を削除するような形でUART、ADC、タイマー、DMAくらいの主要な部分は動き出しました。 一緒に買ったI2Cでつながるジャイロ＆加速度センサーの接続まではできなかった。
これ、パワーはあるし、ペリフェラルも充実しているし、大きさもまぁ小さい。さらには2000円弱という安さ。 開発環境（というかソース）を統一するという意味でもこいつは使えそうです。 Coronの立ち上げの際には苦労したけどわかってしまえばペリフェラルの設定は簡単だし。
SEMB1200Aのセンサー部として買ったけど、これでシグマ動かせば軽くなるなぁ、重さじゃなくて物量的に。 ２つ買っとけばよかった。
■３月１３日■
やっと石巻に住んでる友達の安否が確認できた。 家は流されたけど友人夫婦は無事でした。 よかったー。
明日からの計画停電の町ごとのグループ分けです。 東京電力のHPはつながらないので。。
栃木
http://www.tepco.co.jp/imags/tochigi.pdf
茨城
http://www.tepco.co.jp/images/ibaraki.pdf
群馬
http://www.tepco.co.jp/images/gunma.pdf
千葉
http://www.tepco.co.jp/images/chiba.pdf
神奈川
http://www.tepco.co.jp/images/kanagawa.pdf
東京
http://www.tepco.co.jp/images/tokyo.pdf
埼玉
http://www.tepco.co.jp/images/saitama.pdf
山梨
http://www.tepco.co.jp/images/yamanashi.pdf
静岡
http://www.tepco.co.jp/images/numazu.pdf
なお、停電時間は表中の数字（グループ）をご覧ください。
第１グループ 6:20〜10:00 16:50〜20:30
第２グループ 9:20〜13:00 18:20〜22:00
第３グループ 12:20〜16:00
第４グループ 13:50〜17:30
第５グループ 15:20〜19:00
■３月１６日■
地震におびえ、原発に戦々恐々としながら過ごしてます。
東電にはとにかく頑張ってもらわないとならないのだけど、冷却装置が故障とか予備発電機の燃料切れとか、勘弁して欲しいなぁと正直思います。
同僚の家族も友人の家族もどうやら無事で、石巻在住の友人夫妻も無事だったので自分的な被災者の安否確認は完了しました。 連日被災者の切実なSOSが放送されているんだけど、あのインタビューとか電話とかFAXとかはどのように処理されるんだろうか。 まさか放送されて終了なんでしょうかね。
放送した責任上、あの町にガソリン、食料届きました、くらいのフォローまでして欲しいです。
保存食料とか電池の買占めしてる人、なにパニクってるんだろう？ アホだなぁとか思ってたんですが、どんどん地震が近づいてきてとうとう追い抜かされちゃった感じだったので、カ、カンパンくらいは買っといた方がよかったのか？ とか思いましたがもうどこにも売ってないらしいのでそれは諦めて、こないだSTM32ボードと一緒に買ったジャイロ・加速度モジュールの動作確認を進めることにしました。
I2Cでデジタル値で出力するタイプなのですが、I2Cはまだ使ったことがないのでサンプルプログラムとデバイスのデータシートを見てテストプログラムを作りました。
加速度センサーは間もなくレジスタが読めるようになったのだけどジャイロセンサーはさっぱり反応しない。 I2Cは初めてなのでなにか思い違いがあるのではないかと二日ほどがんばったのだけど、結論は「動作不良」。 初めて使うインターフェイスでハズレ引くと辛いです。 良し悪しの判断ができない。
購入して10日も経ってしまったのだけど、ストロベリーリナックスに「不良だと思う」と連絡すると直ぐに「多忙のため代品送ります」といまいちわけのわからないが心強い返事が。 もっと早く諦めときゃよかったかな。
加速度センサーだけは動くのでとりあえず設定してセンサー値を読み取れることまで確認範囲を広げておきました。
ジャイロがホントにこわれているのかどうかはわからんのだけど。
■３月１７日■
打ち合わせしていたら、大規模停電が発生する恐れがあるから今すぐ帰れと。
なんだかんだで、11日の大地震の時を除いて停電を経験していないで、今日もおそらくは停電にはならないだろうなぁと思ったのだが、まぁ指示に従って帰ることに。 ところが、南武線の下りは近隣の会社が一斉に退社勧告したらしくものすごい人であふれていて入場制限をしています。 それはそれは長ーい列の後ろに並んで待つのはいやなのでぐるーっと迂回して私鉄で帰ってみることにしました。
武蔵小杉から渋谷に出て、井の頭線で下北沢に行き、小田急線に乗り換えれば登戸に出れるなぁと。 東横線上りはそれほど混雑していなかったのだけど、渋谷駅は武蔵小杉なんか比べ物にならないほどの人であふれていました。
京王線はそれほどじゃなくってすんなりと井の頭線に乗れたのだけど、下北沢では小田急線がやっぱり入場制限しているとか。 じゃぁ、京王線で明大前経由で稲田堤に行ってみよう。 こちらはやっぱりあんまり混んでませんでした。 急行も走ってたし。
というわけで入場制限を避けて帰ったのだけど、稲田堤に着く頃には南武線はするする走ってました。 多分待ってた方がよほど早く帰れたんでしょうね。（笑
さすがにまだ代品のセンサーモジュールは届かないだろうから今日はUVCで取り込んだ画像データを操作してみようと思っていたのだけど、なんともう代品が届いてました。 被災地にもコレくらいスピーディーに物資が届けば良いのですが。 早速CPUボードに取り付けて動作確認すると、、 なんとかかんとか動きました。
「なんとかかんとか」というのは、なんだか安定しないんですね。加速度センサーは安定して動くのにジャイロは動いたり動かなかったり。 ノイズに弱いのか電流が足りないのか、アース電位がふらついているのか、なんかそんな感じだけど動く時はまともに動いているようなのでなんとかなるでしょう。
次は圧力センサー。 ドライブ回路が要りそう。
■３月２１日■
三連休、休みが取れる状況になったのにほとんどなんにも進められませんでした。 どうも地震関連情報を見ていたらテレビから離れられません。 原発の状況もそれほど深刻にハラハラしているわけじゃないんだけど、どういうのか、自分は何もできないのだけれど現地で頑張っている人を見守っておかねばならないという風な気持ちになっていて、ちょっとおかしな雰囲気です。
なにか片付かない気持ちが大きいのか、大きくロボット開発に没頭できないで終わってしまいました。
圧力センサーを使ってZMPセンサーを作るにしても、圧力センサーがひとつしかないし、コネクタやらオペアンプやらも欲しいので秋葉原に買い出しに行きました。 秋葉原でも乾電池は売り切れてましたね。 発電式のLEDライトを買おうと思ってたのに買い忘れたな。
ロボット関連部品以外では防災関連アイテムじゃなくて、携帯を置き忘れるとバイブで知らせてくれるブレスレット？的なアイテムを買ってきました。 実はこの地震騒ぎで私の上司が満員電車にもみくちゃにされた勢いでポケットに入れていた携帯電話を落とすという事件がありました。 その直前に自分もびっくり寿司に財布を忘れるというびっくり事件があったりしたので、財布には何のフォローにもならないけど携帯だけは落としたり忘れたりしないように体制強化です。
で、色々と買って帰ってきたのだけど、はんだ付けする元気がどうにもできなくて結局何もせず。 う〜。
やる気がいまいち出ないのだけどなんかやらねばならないなと思い、UVCで画像を取得する方法などを調べていました。 やってることが簡単そうなmjpeg-streamerを調べてみたのだが、これは入力部と出力部がプラグインで読み込めるようになっているため、処理が見えにくくてさらにマルチスレッドプログラムになってるみたいでよくわからん。 どうも、ストリーミングデータを流すタイプだとフレームごとに取り込んで画像処理をするプログラムの参考にはなりにくいのかと考えて静止画を取得するプログラムを解析することにしました。
少し前にUVCを調べてみた時にためしたfswebcamというのを調査。 これも当時からはバージョンが進んでLogicoolのカメラだと安定して動作するようになりました。（Logicoolなら前から安定していたかもしれませんが） これを解析。 こちらも相当単純な処理しかやっていないのだけど、きちんと作ってあるプログラムはエラー処理とかコマンド解析とかの部分がほとんどなんですね。 なかなかUVCドライブの本体にたどりつきませんでした。
もう一息でデバイス設定と画像取り込み部分に至ります。
↓ＡＣの穴埋めCMのひとつ「手で伝える」編 3人目に出てくるちびっこがかわいい〜 何度観てもかわいいですね。 オシムはもういいですか。 いいえウサギも。
■３月２４日■
STBee-miniの実装方法が決まらないのではんだ付けするのに躊躇していたのですが、端子にピンを差し込んだだけでは接触不良のために実験がうまく進みません。 あ、そうだブレッドボードってのが有ったんだ。 と、思ったんだけどうちにあるミニブレッドボードだと寸足らずでSTBee-miniが取り付けられません。 たしか、大きなのがひとつだけ有ったと思ったんだけど探したけど出てこない。
仕方ないのでスイッチサイエンスでSTBee-miniが乗るサイズのブレッドボードを買ったりしてました。1個250円
スイッチサイエンスは送料180円で送ってくれるのでうれしいですね。 支払いもPaypal使えば送金料はあちらもち。
そして圧力センサーのドライブ回路を組んでみました。
うーん、ストロークが小さいなぁ。 指でちょっとつまんだら振り切れてしまう。 1キロくらいまでをリニアに測れればよいのだが、 測定装置作らないとカーブがとれないな。 一応、デバイスのドキュメントに載ってた電流電圧変換回路で加重に対してそこそこリニアに出力するようになっているはず。
動いたので回路組んでみるかー。 圧力センサーを組み込んだ足裏も設計しないとな。
■３月２７日■
昨日は練習会。 ラムダが動いてから練習会に行ってないのだけど、まだフィードバック制御ができてないのでただ歩くだけってのじゃあんまりなぁ〜、いやでも。。
ってことで極めて消極的にラムダを持っていきました。 結局、ロボトマでラムダは電源さえ入れなかったんですけどね。
無事小学校を卒業したおさる君のロボワン出場予定機体「オサル４号」 ものすごく安定して歩きますね。驚きました。 でもイガアさんに「モーションが悪い」って言われてた。キビシーなぁ。
打ち上げはろぼとまの近くの中華料理屋。 一番安いコースを頼んだのにおなか一杯になりました。 打ち上げでの話題はやっぱり地震。 主に原発の問題がネタだったかな。 なんかゲラゲラ笑ってたような気がするんだけど気のせいかなー。
ZMPセンサーの実験基板もできたので、負荷カーブをプロットしようかと思ったのだけど、今後ZMPを出力するようになっていく時にビジュアルモニターが欲しいなと思いまして、Visual C++ 2010expressでcomポートからのデータをグラフ表示するプログラムを作ろうと。
Visual C++はVersion6以来なんだけど、流儀が全然変わってる。 判れば簡単だけど、めんどくさいっていうか、調べるきっかけが少ないんですよね。 この巨大な開発環境を、参考書をあたまから勉強するわけにも行かないので、サンプルプログラムを参考にgoogleで調べたりMicrosoftのサイトで調べたり。 とりあえず受信して表示できました。 グラフ描かなきゃ。 もっとお手軽ツールにならないのかなぁ。
■３月２９日■
VC++2010でグラフを描くプログラム。
リサイズしてリドロウしたいのだけど、イベントの処理がいまいちわからん。 以前のVC++はIDEが過保護なほどになんだかんだと勝手に教えてくれたのに、無料だからかわからんが、VC++2010expressはずいぶんと不親切。
ペイントイベントでピクチャーボックスにグラフを描きたいのだが、ウィンドウをリサイズしたときに発生するペイントイベントだけじゃうまくいかない。 なぜ？？？
グラフィック領域をクリアしても、フィルレクトアングルで塗りつぶしても、リサイズしたときにはこんなふうに描画が乱れる。 最小化してから復元したらちゃんと描くんだけどね。
ウィンドウズプログラムの勉強したいわけじゃないからここで悩みたくないんだけどなー。 あー、イライラする。
コントロールにはアンカーというのがあって、これを設定することでフォームの中に配置したコントロールたちの再配置やリサイズを自動的にやってくれる。 以前だと再配置もすべてコードで書かなければならなかったので便利になったのだが、どうも仕組みがわからんのでなじめない。
最初に自力で再配置やリサイズをやろうとして、pictureBox1->Size.Height=this->Size.Height-100;などとしたら、ちゃんと動かない。調べてみるとサイズを変更する場合はpictureBox1->ClientSize=System::Drawing::Size( pictureBox1->Size.Width, this->Size.Height - 100 );てな感じで書かなきゃならないらしい。 わかりにくくするための策略としか思えないぞ。 本くらい買えってことかなー。
気持ち悪くて先に進めないぞ。
って書いてからもうちょっと探したらリフレッシュというメンバー関数を見つけた。これが必要らしい。
■４月４日■
４月になったのだけど、改ページしないで継続。
やっとグラフが描けるようになってきた。 確かにMFCよりも.NETは記述が美しいのかもしれんが、仕様書全部読まなきゃプログラム書けないんじゃないかって思います。 なんか、ここ一週間くらい、調べて調べて、でもよーわからんから適当に書いてカットアンドトライ状態でした。
STM32もとっかかりが悪かったけど、こっちも相当だなー。 プログラムのプロにすればこれはとっつきやすいのであろうか。
ADコンバータの出力を監視するつもりでグラフ表示プログラムを用意したのだが、ADコンバータ10チャンネル動作のプログラムは見事に間違えておりました。 数字の羅列で見てるときは問題ないように見えていたからグラフプログラムを先に作ったのは正解でした。
圧力センサーをつないでテスト。 とりあえず指でセンサーをつまんで徐々に力を強くしていったら、感覚的にではあるけれど、リニアになってる感じがしないでもない。 問題は親指のハラだとうまくいくのだけど堅い物で抑えるとダイナミックレンジが極端に小さくなる。指のハラのようなもので圧力をかけるのが必須なのか。
■４月１１日■
余震がおさまらないですね。 今日も相当大きな余震がありました。 先週木曜に有った大きな余震は、飲みに行った帰り道で気づかなかったのだけど、今日は仕事中だったので気づきました。 というか、携帯がプワンプワン大合唱だったので気づかないわけにいかないです。
日曜日はROBOT JAPAN １ｓｔの観戦に行ってきました。 オサル君優勝おめでとう！ 前の夜にモーション飛ばしたとは思えない安定した動きでした。 すごいなぁ。
谷川俊太郎先生が審査員に来ると聞いてたので、なんでだろう？と思っていたのだけど、「鉄腕アトム」の作詞者だったとは知らなかった。
土曜日は先週からしかかりの足裏センサーのテストを継続。 とうとう足裏っぽくなってきました。
この間にセンサーが挟まっていて、中身はこんなふうになっています。↓
親指のハラで押さえる感覚を機械的に再現するためにゴムシートを切り抜いて、厚み調整のために衝撃吸収シートをはさんでみました。
ゴムシートの切り抜きは、会社にあったポンチを借りてきました。 いろんな直径があったのでいくつか借りてきたけど、直径の違いで差はない様子。
さぁ、今度はこのセンサーから取得した値でZMPを計算して画面に表示してみます。
■４月１３日■
ZMP表示がやっとできましたー。
足裏を指で押さえているイメージで観てください。 ZMP表示の方はトップビュー（上から見た絵）です。
真ん中を押さえると↓
手前の少し左側（足の裏なので左右が逆です）を押さえると、表示では少し上の左側に↓
そして、少し後ろ側を押さえると、表示の方もそちらに移動↓
なかなかよい感じです。 では、両足分作ってロボットに取り付けてみなければなりません。 これ、データ取り込みはSTBee-MINIでやっているのでSEMBにZMPデータを引き渡して制御することになります。 制御って重心位置を補正かければよいのかな。 どうも自分がどうやってバランスとっているのかと内観してみると足の指先や踵に力を入れているように感じる。これをロボットでやるとなると、ZMPが偏っている方向に足裏を押し付けるような制御になるのか。 逆位相の制御になるので普通に制御ループ回すと発散しそうな気配。遅れ要素の制御ってどうやるのかな？
■４月１７日■
昨日はバーベキュー、今日はロボでサバゲ なのだけどどちらも参加せず。 土曜日のバーベキューには参加したかったのだけど、ウィークデーに飲む機会が多かったので毒が抜けずに土曜日はごろごろと本当の休暇。 バーベキューに行くか行くまいか迷っていたもうひとつの理由にサバゲがあったのだけど、土曜日休んでしまったのでサバゲにも行けず。
家でUST見たりしていました。 ロボットジャパンチームがロボゲームスに参加していて、USTで様子を見たりできたのですが、なんつーか、見ていてテンション上がりました。インターネットってすごいなぁーと改めて思ったり。 来年はROBOJAPANでMVPとってROBOGAMESに参加したいですねぇ〜。
そういうわけで、今日は久しぶりにシグマを引っ張り出して動かしてみようかと。 思えばシグマにテンショナーをつけてからまだ動かしてなかったんですね。
で、せっかくだからそのうち配線が切れるだろうと思っていたRS485のコネクタ部分をちゃんとしたコネクタに付け直して動作確認。。。。。 うごかねー（泣）
どうもモニターへのコマンドの受付もおかしいのでもしかしたらコマンドラインエディターとかコントローラコマンドのデコーダ部分を改造・レベルあわせしたのが影響しているか、いや、圧力センサーのテストやったときに色々とパラメータを変更してみたなとか思い当たるところは多々あるので、旧バージョンにグレードダウン。
すると、コマンド入力は素直になり、サーボも動き出したのだけど、サーボのコマンド受付がどうにもノイズィー（焦） ラムダと違ってシグマはRS485なのでレベルがなんちゃらという話はないはずなので多分プログラムの問題の、ように思うのだけどこれでサバゲに出たことあるんだけどあの時はこんなに不安定じゃなかったよなぁ（泣）
とかなんとかやっていたんだけど、よく考えるとゴールデンウィークが過ぎたらすぐにわんだほ〜だよなぁ。 どう考えても画像認識をBeagleBoardでさせるところまで行き着くようには思えない。 いかんなぁ〜、いかんいかん。
■４月２４日■
昨日は練習会。 ラムダを持っていって動かそうと思ったのだけど、コントローラの受信機を忘れてしまった。 そういえばシグマを動かしてみようとして外したのをすっかり忘れていた。 急遽キーボードから動かせるようにして、受信機からの信号を無視するようにしたのだけど、プログラムの修正が不完全だったらしくて、コマンド送らないでも勝手に歩き出したり止まったり、 自律で動き出したらあんなふうになるのかな。
今月の練習会は、学生がたくさん来ていてわいわいがやがやしておりました。 TDUのメンバーが、4014で身長1メートルのロボットを作るといって計算書を持ってきました。 計算によるとダブルにすればトルクが足りるとか。
うーん、それは静止トルクで考えちゃダメなんだよな。 このページの最初の方にちょっこりそこに触れているので少し読んでみて。
雨が激しく降っていたので車移動での参加だったのだけど、車だと打ち上げでアルコール飲めないからやっぱり寂しいですね。 移動が楽なんですけどねー。
今日は、先週のウィークデーになんとかしたかったZMPセンサー付き足裏の製作。 でも、片足しか完成しませんでした。
圧力センサーの端子に合うコネクタが足りなくて家捜ししたけどない。 どうすっかなー、秋葉原行きたくないからセンサーの端子を加工して手持ちの部品で間に合うようにするか。
今日中にセンサーつけて歩かせて、ZMPがどんな感じなのかを確認するつもりだったけど未達成。 しょぼん。
■４月２６日■
がんばってウィークデーのうちに足裏を完成させる予定。 この週末から連休なので、連休突入までに完成させたい。
そうしなければ、連休使って「足裏完成まで」というふうになりかねない。
ということで、日曜は3時くらいまで、月曜も同じくらいまでがんばりました。 おかげで今日の会社帰りは、南武線で武蔵溝ノ口から座った途端に終点の登戸まで熟睡するくらい眠かった。 そして、今日もがんばってやっとZMP足裏を取り付けた上体でラムダを歩かせるとこまできました。
ロボット用の電源をSTBeeMiniに使っているのでロボットはバッテリー動作です。そして一歩だけ歩かせた時のZMP軌跡がこれ。
左側の軌跡がおかしい。。 どうやら昨夜、基板がサーボと干渉することがわかったので部品の取り付けを背が低くなるように直した時に配線がおかしくなったらしい。 がくり。
でも、立っている状態でロボットを手で押したりすると、傾いた方向にZMPが移動するのがわかります。足裏センサーはちゃんと機能しているらしい。
これから基板の配線修理をやっていると明日の仕事に差し支えそうなので、今夜は閉店です。 明日あさってと飲み会なので次に作業できるのは金曜日。 連休突入です。
連休は画像取り込みをやりたかったんだけどなー。 もうちょっとZMPフィードバックをがんばることにしよう。
■４月２９日■
今日から連休。 昨夜は美味しい料理とお酒をご馳走になったのだが、なれない日本酒を結構な量飲んだのだが、いいお酒だと二日酔いしない。 いい夜だったー。
今日はロボスポで、BeagleBoardで無線カメラを構築するってことでノボリサカ講師による「Belagleでサバゲ」が開催された。 うちのBeagleBoardはカメラのインストールは完了しているのだが様子を見に出かけてみた。
カメラを接続するまでの設定は数時間では完了しない（慣れない人だと特に）ので、田中さんのパソコンにVMWare上のUbuntuが動き出したのと、BeagleBoardにUbuntuのインストールが完了したところまでで終了。 あと、802.11aの無線LANアダプタの買占めをしたりしてました。（アウトレット品だけど） 次のサバゲでは複数台の機体で11aでの無線カメラが動くことに期待。
帰ってZMPセンサーの続き。 はんだ不良を直して動作確認。 そして歩行させてのZMP軌跡を記録してみました。
このときのZMP軌跡は、（と言っても実は別撮りなんだけど）
ちょっと表示がさかさまになってまして、左側のボックスがロボットの右足で、ボックスの下側がロボットの足ではつま先側。ボックスの左側が足の右側になってしまっています。
ボックス内でうごめく四角形があるのがZMPです。最新10サンプルを表示していまして、最近のデータほど四角形が大きく表示されています。 動画を再生すると、ZMPが中心になる瞬間が交互に訪れるのですが、これは接地した状態ではなく足が浮いている状態です。圧力センサーの合計値を考慮すれば足が浮いているかどうかの判定もできるので色で表示したりすればよいのだけどまだそこまでできてません。
止まっている時から右足のZMPが中心に来ていないのはきっとトリムがずれているからでしょう。
さあ、次はこれをSEMBに取り込んでフィードバックをかけることを考える。
今日で4月もおしまいです。 明日からは新しいページに切り替えましょう。
昨日掲載したZMP軌跡は、上下や左右がさかさまだし、足が浮いているのか接地しているのかわからなかったので、その辺りを修正しました。
VC++2010expressで作っているのですが、なんだかんだ四苦八苦です。 いつの間にか出てきた「ハンドル」という概念がポインターとどのように違うのかわかりません。
Pen^ pen = gcnew Pen(Color::FromArgb(255,0,0,0));
で作ったペンの色を変えようと思って
pen->Color.FromArgb(a,r,g,b); // a,r,g,bは変更したい色のデータ
としても変わりません。 ハンドルに割り当てた領域は変更不可なのかな？ わからんので、いちいち delete してから gcnew して割り当てなおしてます。 なんか無駄なオーバーヘッドとしか思えないが。
そうして取り直したZMP軌跡がこれ。 今日の版は、上が前で下が後ろ、足の左右は画面の見たままです。ZMPのマークが濃いほど接地圧が高いことを示しています。
正直ようわからんが、コマ送りで見るとそこそこ情報がありそうな感じ。 この画面の動画キャプチャーはCamStudioというフリーソフトでキャプチャーしたのですが、同梱のプレイヤーを使うと、スライドバーで表示をマウス操作で前後に動かしてみることができます。もし興味がある方は見てみてください。
フィードバックをかける前にトリムを取り直して改善の様子を見るべきか。 この状態からフィードバックをかけてみて改善を期待するべきか。。。
生のAVIファイルはこちら