開発日誌(40)
トップへ戻る
開発日誌インデックスへ
前のページへ
次のページへ
■１月４日■
あけましておめでとうございます。
この年末年始は帰省しないで、自宅での年越しになりました。
なので、年末年始にも関わらずロボット作業ができました。
まずは、ずっと作業し残していた、ラムダへのBeagleBoardの搭載。 でかいので背負います。 後ろにこけた時のバンパーを考えあぐねて作業を先送りしていたいけどもういいや。スポンジでも貼り付けることにしよう。
カメラへの配線はUSBなのですが、元のWebカメラのケーブルをちょん切って買ってきたコネクタで接続。
このコネクタプラグ、秋月で探してもなかったのですが、田中さんがイイ感じのコネクタプラグを使っていたので「あーやっぱりどっかに売ってるんだー」と思って秋葉原に探しにでかけました。（田中さんにどこで売ってるのか聞けばよかったんだけど、なぜか聞きそびれた）
田中さんが使ってたのはプラグのジャケットも付いているもので、ヒロセにありました。350円くらい。 で、この画像に写ってるのはマルツで100円。ジャケットついてないけどいいやってことで安いのにしました。
そして、昨年末から検討しているWLANモジュールの接続ですが、ショッキングなことが。
OTGポートにHUBをつないで外部電源を供給すれば使えるので、miniA−Aメスケーブルの途中から5Vを外部供給すればいいんだろうと思っていたのですが、すばらしいユニバーサルインターフェイスであるところのUSBはそういう適当なことを許してくれないようです。
OTGポートがバスパワー供給できるのは数ミリアンペアだけらしいのですが、接続されるデバイスはネゴシエーションの際に必要な電流容量を申告します。 今回使うWLANアダプタの場合は450mA。 もちろんこれはポートの供給容量をはるかに超えているのでホストは接続を拒否してしまうようです。 よくある二股ケーブルで電流容量を稼ぐデバイスは、申告は通常のUSBコネクタが供給可能な500mA以内にしておいて実はもっと容量が要るようになっているってことなんですかね。 外部供給した上で、ドライバーかコンフィグデータをいじれば接続できるはずだけど、ソフトをいじらなければHUBを介さないと使えないってことですね。
OTGホストの供給容量を500mAくらいに修正できればつながるはずなんだけど、どこいじればいいのかわからないです。
とりあえず調査を継続しながら、小型の外部電源供給可能なHUBを探すことにしよう。 HUBつけてUSBポート増やしちゃうってのもアリだけどね。
■１月９日■
生まれて初めて福袋を買いました。 ロボスポで。
年末年始の休みの間、CADで次の足構造の検討も進めておりました。 今のラムダを分解して作ってもいいんだけど、また歩かない時間が続くと今までと一緒なので今のラムダはそのままBeagleBoard＋カメラを使った自律行動のための開発を進めつつ、次バージョンの足構造を開発することにしました。
もっとも、今度の足構造だと4014だと厳しいかもしれないので6003の数を増やした方がよさそうな気配。なので、新たにサーボを買うことに。 折りしも年始の福袋の季節なのでロボスポの福袋でサーボを買うことに。 ロボスポの福袋ってKHRとかのロボットキットがメインで、サーボセットなんか無いだろうと思ってたけど全然違うんですね、知らなかった。 おかげで随分と出費が抑えられました。
次バージョン足構造は鋭意検討中。 この三連休で大体出来たけど、まだまだ煮詰まっていないのでもう少しかかるでしょう。 同時に腕構造も考えたいんだけど腕は難しい〜(>_<)
BeagleBoardにつなぐHUBの件。 セルフ給電とバスパワーのコンバータみたいなのないかなぁと探してみたけどなさそう。 あとはワンチップでUSBHUBができちゃうような便利ICないかなと探したがいまのところ見つからない。 チップを探していてUSBHUB用LSIの評価ボードが見つかった。 これは２ポートのHUBになっていてセルフパワーとバスパワーの切り替えもできるのでちょうどいいんだけど、個人に売ってくれるのか問い合わせたところ、製品開発をするときのリファレンスボードなのでどうやら１個７万円くらいはしそうだってことなので事実上ボツ。
この評価ボードの回路図もあったので作っちゃおうかとも思ったけど、HUB積んじゃったほうが後々便利かもしれないなと思い出したので、あがくのをやめてHUBを積む方向で検討中。
あれやらこれやらで、もうコケられないロボットになりつつあります。(^_^;) せっかくBeagleBoard-xMになってHUBがなくても構成できるようになったと思ったんだけどなぁ〜。
■１月１５日■
どうにも困りました。
ラムダのアタマは外装以外はできているし、プログラムもまぁ色認識くらいならなんとか動く状態。 BeagleBoardも本体に背負わせたし、あとはBeagleBoardとSEMBをつないでカメラで見た情報でラムダを歩かせるってのに進まなきゃならない。 接続するための回路も部品も揃っていてあとは組み立てるだけなんだけどどうにもそっちに手が付かない。
SEMBに、１WUARTしか空いてなくてそこにつなぐしかないんだけどそれがなんともイヤだってことを差し引いても新型足構造の検討が楽しくてそっちばっかりやっちゃってます。 実はもうほぼ設計は完了していてあとは部品を起こせばいいだけなんだけど、あろうことか次は腕も同じコンセプトで設計したいなぁ〜って思い始めてしまった。
設計しているときはまぁ楽しいからどうにも楽な方に転がってしまう弱さをそのまま露呈してしまっているわけです。 あぁなさけない。
■１月１９日■
日曜のお昼、 ご飯を食べ終わったところでふいにノドに違和感を感じ始めました。 金曜日の飲み会でカラオケ行って朝帰りだったのでそのせいかな？ でもちょっと感じが違う、これはばい菌かウィルスにやられた感じがするなーと思いながらも一日過ごし、夜遅くに微熱が出始めました。
インフルエンザの可能性を気にしながらも朝になっても７度台だったので多分風邪だろうということで二日ほど寝込んでおりました。 ただ、ちょっと普段の風邪とは熱の出方やノドの痛みが違う（ノドの痛みが軽い）ついでにオナカはなんともない。 傾向として毎晩夜になると一時３８．５度くらいまで体温が上がってその後落ち着く。 その熱にしたら体は全然辛くないんだけど？？？
水曜日の朝には熱も引いたので会社に行くことに。 いい歳して徹夜でカラオケとかするから熱だすんだ！とか上司に言われましたが、ちょっと気になったので午後から病院に行くことに。
医者 「 ノド見せて。。。 もうなおりかかってるねー。 どうする？ 検査してもいいけどこれから出す薬は普通の風邪と一緒だけど？？」
オレ 「 あ、インフルエンザの？ でもまだうつるんですよねぇ？」
医者 「 うつるよ。 。。。 じゃー検査しておこうか。」
って感じで一応検査することに。
結果はA型陽性。 事務所に戻ったらテロリスト扱いされました。(^_^;)
もう熱は下がったから二日ほど寝かせて金曜日から会社行こうと思ってたんだけど、さっきからどうも熱がある雰囲気が。。 測ると３７．５度 今週はもう安静にしとかなきゃだめだな。
ということで土曜日の練習会は残念ですが欠席します。
■１月２１日■
インフルエンザを枯れさせるための自宅待機中。 体は十分に元気なので開発作業をぼちぼちとやっておりました。
やっとこさでUbuntu（Linux)とSEMB1200Aを1WUARTでつないでトラッキングができるようになりました。
特に新しいところはなくて昔のラムダでもやっていた色重心を使ったトラッキングです。
画面上の、ある特定の色のピクセルを集計し、色がある位置の平均値と取ってその位置が画面の中心となるように首を動かしています。 中心からのずれ座標に適当な係数をかけてサーボに渡しているだけで、空間座標の特定も首関節の逆キネも使っていません。
前回と違うとすると画像取得を行っているCPUとサーボ処理を行っているCPUが違うって事くらいですかね。 カメラの取得フレーム毎にサーボを動かさないとまともにトラッキングできないことがわかりました。 結構厳しいです。
でも、ロボットが勝手に（？）動くのを見るのはやはり楽しいです。
最近は、人間も「モノ」を認識してどうこうするのは相当な表層レイヤーでの話であって、ほとんどは全体の趣きとか傾向で行動を決定しているのではないかと考えています。 「あっちでなんかが動いた！」って感じたから振り向く、 といった感じですかね。 実際の行動決定もそれに近いものの集合ではないかなと考えたりしています。
今回のラムダの目はWebカメラを縦向きに使っているので実は横の動きには少し余裕がありません。 しかし、当面の目標はカメラ画像を使ってまっすぐに歩くことなので縦方向に余裕がある方がいいでしょう。
■１月２８日■
いままでバラックで接続していたBeagleBoardとSEMB1200Aの接続インターフェイス回路をちゃんと組み込みました。
これまでテキトーにガムテで取り付けていた通信モジュール（リモコン用とSEMBのコンソール用のXBee）もちゃんと取り付けたり組み込んだり。 インターフェイスボードにはBeagleBoardのUSBとSEMBの１WUARTをつなぐためのFT232と、XBeeとSEMBのコンソールをつなぐためのMAX2331を使ったのだがどちらもSSOPでピンのピッチが0.65ミリ。 はんだづけ作業はルーペで拡大しながらの作業です。
いままで直径1ﾐﾘくらいあるはんだを使っていたのですが、今回0.3ミリ径のはんだを使って作業しました。 細いのいいですね。 細いから熱を受けやすいのか、すっと溶けてなじみやすい気がする。 量も多く盛りすぎることがないので、はんだブリッジでショートすることもなくきれいに作業できました。
もっとも、一発で動作しなかったので怪しいところにはんだを盛って修正する羽目になったのでアレなんですけど。
さて、明日は追加となったHUBをちゃんとネジ固定する工作をしよう。
■１月２９日■
あまりにも外が寒くて工作はできなかった。(^_^;)
ラムダの目が機能し始めたので、「画像を頼りに動く」ためのプログラムを作らねばならない。 今はBeagleBoardとのインターフェイスにサーボ用のポートをあてがっている。 そしてBeagleBoardからの情報受信も、サーボへのコマンド発行とリターンパケットの処理に混ぜ込んで処理している。 つまり、SEMB側がホストのような動きをしているのだ。
実はこのままではうまくない。
BeagleBoardからのヘッドトラッキング情報はBeagleBoardが画像処理をする頻度（つまり実質上のｆｐｓ）で情報を送ってこないと十分ではないことがわかっている。多分15fpsくらい。 対してSEMBのサーボへのコマンド送信頻度も20msとそれほど頻度が高いわけではない。 ｆｐｓよりは少し頻度が高い程度。 なので今はなんとか処理できている。
つまり送る側も受ける側も自分のタイミングで送信・受信しているわけで、半二重回線で双方向通信するにはとてもうまくない状況ということです。
ということで、この先のプログラムを進める前にBeagleBoardとSEMBの通信を（サーボとの通信周期ではなく）BeagleBoardをホストとした割り込み処理（または頻度が高いポーリング処理）に書き直す必要が出てきた。 全二重通信が出来るポートが余っていたらもっと簡単なんだけどなぁ。
画像は、ボールの色にトラッキングさせながらラムダを歩かせているところ。 歩いて近づいているわけじゃなくて、歩く時の上体の動きでトラッキングが外れたりしないかどうかを見ている。 とりあえず歩くことでトラッキングが外れることはないようだ。 この制御頻度は多分余裕は無いからこの先画像処理が重くなってくると、状況も変わってくる可能性はおおきいですけど。
それより、今のラムダの歩行では画面を見ながら歩かせることは、危なっかしくってできないですねー。 画像での操縦は到底無理って感じです。 更には今の頭部のチルト範囲では足元が見えません。 トラッキングで歩くときは目標物を見ながら歩くわけだけど、視界全体を見ながら歩くような時は自分の出足が見える必要があります。 そうでなければ段差や障害物を避けれない。
↑これくらいの位置関係で、 カメラにはこのように写ります。
不安定な2足歩行の移動体を使うより、車輪やクローラーを使った移動体を使った自律行動の研究の方が（問題が分離できて）良いと思った時期もあったんだけど、マイクロマウスなんかとは違った「ロボット」としての行動制御をしてみたくて2足にこだわってます。 でも、全然進まないからアプローチ変えなきゃだめかもしれないと思う今日この頃です。
とりあえず、足裏をデカくしてコケにくくするくらいのことはしとくか。 じゃなきゃさっぱり先に進めない。(>_<)
■１月３０日■
とりあえず、BeagleBoardからの通信データ取り込みを割り込み処理することは出来た。 SEMB1200AのINTCの処理をすっかり忘れていて焦った(^_^;)
でも、割り込みで処理すると、コマンドはBeagleBoardのタイミングで送ってくるわけで、SEMB側のサーボ処理とはまったく非同期。 受信してそのままトラッキングデータを処理するとSEMBのサーボ通信がおかしくなってしまう。 そんなことでおかしくなるのもおかしな話なのだが、どうもお気に召さないらしい。 乱暴に命令しないでご機嫌を伺って丁重にお願いしなければならないらしい。
それより、SEMBとBeagleBoard、それぞれの電源を単独でON/OFFできるようにせねばならない。 デバッグ中はバグのせいでおかしな具合になりやすいのだがそのたびにBeagleBoardの電源再投入はめんどくさくって危なくってやりたくない。
ところでROBO-ONEの足裏サイズ規定ってどこに載ってるんでしょう？ 見当たらない。
■２月５日■
やっと色んな荷物を背負える事ができました。 USB HUBもちゃんとネジ固定しました。 WLANドングルがUSBコネクタで取り付いているだけなのでこけたら壊れそう。ドングルについていた短い延長ケーブルでつないで干渉対策にしようかな。
ええと、次はCPU毎の電源スイッチを作らねばならない。 BeagleBoardはコネクタ抜けばいいだけだからSEMB1200Aの電源を単独でONOFFできればよいわけか。 どこにつけるかなぁ。
それと足裏をROBO-ONE規定に合わせて拡大するつもり。 ラムダの足の長さは300mmくらいかと思ったら265mm。 今のサイズが100mm×65mmなので、ROBO-ONE規定にあわせてもそれほどは大きくならないようだ。 あ、重量が3kgを超えてるかもしれない。 超えてたらROBO-ONEには出れないんだっけ？ そしたらデビューはROBOTJAPANの一発芸だな。
色認識だけで画像を使って直進するアルゴリズム（？）はなんとかなりそうなのでそれを組み込みたい。 あとはやりかけのジャイロセンサーの実装（今は動いてない。 電源容量が足りないだけだと思う）と、足裏センサーで歩調をフィードバックってのを実装したい。 間に合うか。
そういえば、BeagleBoardとSEMBが相互通信できるようになりました。 SEMB側の受信処理を割り込み処理に変更して、BBからのデータを受信完了してから送信を開始します。 送受信のタイミングはUVCのキャプチャータイミングに同期ということになります。 30fpsとして考えてもそこそこのデータ量を処理できるはずなので問題ないでしょう。。。 でも全二重回線がいいなぁ、半二重回線はなにかとめんどくさい。
あとは頭部の外装作らなくちゃな。基板むき出しのままだとまずいだろう。
■２月１２日■
昨日は関東組練習会。 武蔵溝口での開催だったので近場です。
ろくに動かないラムダを持って行くのもなんなのですが、ラムダのようにネットワークを使っていると家の環境から変わるとつながらなかったりするのでそういう部分のテストも兼ねて家の外で家でやっていることと同じことができることを確認できる機会でもありますので持って行く事に。
練習会場で色認識でのトラッキングを動かしてみたんだけど、なんせ作りこみがされていないのですぐにトラッキングが外れて首がぐりーーーんと回っちゃったりでうまくありません。
実はBeagleBoardの開発環境がどうにも落ち着かなくて、プログラムを作りこむ事に力が入っていませんでした。 BeagleBoardでXwindowを動かすこともできるんだけど、まぁ重いしあんまりやり方として正しいとも思えない。 今はRS232Cでコンソールをつなぐか、有線LANまたは無線LANでSSHでつなぐかって感じでどちらにしてもテキストベース。 なのでプログラムを書く作業はやりにくいんですね。 昔はこれでviとかNEMACSとかで開発してたわけだよねぇ。慣れればできるんだろうなぁ。
ということで今まではPCに入ってるVMPlayer上で動くUbuntuでプログラムを作り、デバッグをしてからBeagleBoradに転送していました。
そういうことを人形つかいさんに話したところ、sshfsってのがあると。 それを使うとsshでファイルシステムを共有できるらしい。 sambaを入れるしかないかなーと思ってたんだけどsshはもう動いているので簡単そう。 ということで今日は午前中からsshfsをインストールして環境を構築しておりました。 これは便利です。基本的にクライアント側もUNIXじゃないとダメっぽい（Windowsで動くsshfsもあるらしいが）けど十分です。
ということで製作意欲が沸いてきたのでBB側、SEMB側のプログラムをいじって昨日よりは「マシ」になりました。 なんか、CDTの処理抜けがあるのでBB側を本格的にチェック・デバッグせねばならなさそう。
来週の土曜日は大河原ロボットバトル。 うっかりして18日に予定を入れてしまった。 なんとか調整して観に行きたい。
■２月１９日■
昨日は大河原メカ バトルトーナメント。 予定を調整して行って来ました。 アニメに出てくるメカを再現するのはなかなか難しいので動かないロボットが続出。 初期のロボワンを思わせるようなイベントの運びだったのですが、サンライズの井上さんが言う「扮装で盛り上げてくれた方々」のおかげもあり、楽しいイベントになりました。
それにしてもトビーさんはすげぇ！ もう尊敬に値します。
参加者の多くはいつもの関東圏のメンバーだったんですが、初めてお見かけした方も居ました。 すばらしいフルスクラッチの60分の1のGMで出場されたmahiroさん。 どうやらラムダロボット研究所も見られているらしい。 懇親会で梓さんが、「しまけんさんのホームページ見て面白いって言う人珍しいよねー！」って(^_^;) 確かに珍しいかも。
面白いといってくれると素直にうれしいです。 最近はめっきり更新頻度も下がってるし、ネタもイマイチ感があって申し訳ないです。 ここは一応技術系を気取ってるので、石川さんみたいにネタの神様がもってきてくれるってのが無い(>_<) 自分で作っていくしかない！
実はカメラとBeagleBoardを積んだ状態で歩かせてみるとどうもバランスが悪い。 どうも重心がおかしいのでCADモデルを再チェックするとBeagleBoardが2枚乗ってたり、 よく見ると左右に重心がずれてる（実際にずれてるわけじゃなくて計算では重心が左右に数ミリずれているという計算結果を出す）これは腕の質点情報に入力ミスがあったのがわかって修正。 更には慣性テンソルまでチェックしたのにまだ不安定。
トリムが狂ったのかと思って再調整してみたり、さらにはマニュアルで質点情報を変更できるようにしてみたりして重心を微調整してみましたがイマイチ。
試しにBeagleBoardを外してみるとおかしな不安定さが無くなる。 あらら、本当にBeagleBoardを背負ったせいでダメになったのか〜。 でも重心を微調整してもおかしいってことは重量自体が計算間違いしている可能性が出てきた。
ということでBeagleBoardの物理データをチェックしてみると、、 あれ？？妙に軽い？？ 実物はHUB込みで実測160gあるのにデータ上は80gくらい。 あれ？あれ？ちゃんと測定してデータ入力したはずなのに(>_<) その後、頭部ユニットのデータもチェックするとサーボのモデルの物性設定がデフォルトのまま（デフォルトだと密度1g/cm^3で計算される） こちらも実測で155gあるのにデータ上は80gくらい。 合わせて100g以上も狂ってるわけかー。
で、BeagleBoardと頭部ユニットの物理データを修正して質点データを再設定。 で、歩かせてみたのが↓
ただまっすぐ歩いているだけなので見る価値ないですが、せっかく撮影したので(^_^;) そういえば、こけられないロボットになってしまったので足裏サイズをROBO-ONE規定に合わせて大きくしました。 3ミリ厚のアクリル板を仮止めしてるだけですけど。 ちなみにこいつの重量は3kgを少し超えちゃってるらしい。 あらら(^_^;)
ま、大した歩行ではないんですが、「バランスが悪い」と言ってた不具合はなくなりました。 実はデータはバッテリーを積んだ状態でのデータですが、今はバッテリーを積んでいません。 なので、データと実物には少なくとも約90gの誤差があります。100g程度の誤差なら大丈夫だけど誤差が200g（プラスその重心位置の違い）になると影響が出てくるということか。
■３月４日■
仕事の話ですが、工場のライン立ち上げの対応で山梨にカンヅメ状態。 週末と事務所での仕事がある時以外は工場に詰めておかなきゃならない状態です。
更には仕事上のデータ処理でPerlでプログラム作ってたりでロボット開発は少し置いてけぼり状態です。
そんな中、半年以上うっちゃらかしていたラムダの加速度センサーとジャイロセンサーを動かしていました。 加速度センサーは動いていたんだけど、ジャイロがうまく動かなかった（というかたまーにしか動かなかった）のでおそらくは電源容量の問題だろうと決め付けてそのうち動かそうと思って早半年。(^_^;)
買い置き部品から3.3V100mAのレギュレータを見つけ出して電源部分に挿入したらすんなりと動き始めました。
で、センサー類を使えるようにプログラムの整備を始めました。
今度は、ジャイロはいいんだけど加速度センサーがノイジーでやな感じ。
直読みだと誤判断しかねないレベルです。 2値平均でも落ち着かないので10値平均を取ることにしました。 昔はC++を使っていたのでリストとか簡単に使えたんだけど、今はC言語なのでリングバッファを作ることにしました。
以前、足裏センサーをスイッチで作った時にリングバッファを作ったんだけど、データ型汎用にしてみたらたまにバグるものができてしまったのだけどデバッグしないでほっといた（そんなのばっかりだな。(^_^;) ですので今回それを流用してデバッグもちゃんとすることに。
10値平均を取ったもの。 これならまぁ使えるかな。 はじめ寝ていたロボットを立たせて歩かせて、また寝かせたというデータです。
さて〜、明日からまた工場出張です。 ラムダを持って行ってホテルで開発しようかな、とも考えたんだけど荷物が多いので諦め。 PCだけは持っていこうかな。 次はモーション再生とCPGの実装に取り掛かるつもり。
■３月１０日■
最近ゴルフを始めることになってゴルフ練習場で練習を続けてました。
年末にオフィスの身近な連中がコンペをすることになったんだけど、まだ練習を始めたばかりでどうにもこうにも形になっていなかったのと、元々左利きなのに道具の関係もあって右打ちで練習してたせいか、スイングすると肩甲骨のあたりに激痛が走るという状態だったのでコンペは不参加。
続いては年が明けて2月の下旬にラウンドすることになっていたんだけど、メンバーの都合で2月18日になってしまい、やっぱり不参加。
そしてとうとう3月9日（金曜日ですが）にコースデビューということになりました。 ところが来週が本番というところで、練習が楽しくてついやりすぎてしまって今度はわき腹を痛めてしまった。 でもまぁここ数ヶ月、練習してどこかを痛めてはそれをいなして練習を続けていたのでまぁ1週間もすればラウンドできるくらいには回復するだろうと思ってました。
一方、仕事の方では工場のラインの立ち上げのため、おおわらわになっていまして私も工場に詰めて問題対応に努めるという状況で金曜に休みをとってゴルフに行くなんぞ到底無理だなと思ってました。 天気も雨っぽいし、まだわき腹も痛いし、仕事も忙しいしという状況なので申し訳ないがまたキャンセルかなーと。。 オレはついにはゴルフとは縁がないのかな、とか(^_^;) 思ったり。
ところが、うちの上司が大のゴルフ好きで部下がゴルフ始めるのは大歓迎ってことで、「その日はオレが工場に詰めるから行って来い。」 「少しくらいの雨なら大丈夫」 ってなことで、もうどんな大雨でも中止にできないような状況になってしまったので腹を括ってラウンドすることにしました。
で、昨日がその当日でした。 雨を避けて早い順番に変更し、こちらを４時に出発したけど結局未明から雨。 まぁ小ぶりだし風はないしなんとかなるかなーと。
そしてラウンド前にウォーミングアップのため練習場へ。 そこでまぁ今までの練習の成果を同僚に披露したのだけど
「おぉ、なかなかやるじゃないですか。」
「これは○○さんには勝てるかも！」
という評価で胸を撫で下ろしていたのですが、実はこのときすでに爆弾の導火線には火が点いてしまっていました。
すぐに出発の時間になってラウンドスタート。
第１ホールのティーショット。 とりあえずお約束の空振りをやってから(^_^;) 気を取り直して打ち直すと。。
パシッ！
「おお！」 「ナイショッ！」
だったそうです。 朝もやと、最近めっきり弱くなった視力のため自分で球の行方はわからんかったのですが(^_^;)
しかし、もう導火線は燃え尽きてしまいました。 癒えていなかったわき腹が取り返しのつかない状態に。 まぁほぼギックリ腰状態です。
雨の中、スイングするたびに走る激痛と戦いながら、痛いからまともに打てないのでもう泣きたくなるほど何度も何度も。。。
死ぬ思いで前半を終了して、もう後半はリタイヤしようと心に誓いつつ昼飯を食べました。
でもまぁ飯食って落ち着くと後半も何とかなるんじゃないかなとか思ってしまうんですね。 一緒に回った同僚が腰痛持ちでコルセットを常備していたのでそれを借りて、まだ使い物にならない５番アイアンを封じて、アイアンは一番練習している７番限定。 一番激痛が伴うダフりを避けて少しでも１打で進む量を増やす作戦で乗り切ることにしました。
後半になると、どういう姿勢になると痛みが走るかも大体わかってきたのでそれを避けつつスイングでは腰を固定して手首だけの手打ちでなんとか最後まで回りました。 最後のホールで集中力が切れてしまってグリーン周りで随分打数を稼ぎましたが、一応初ラウンドは終了。
意気込んでいたわりに情けないスコアでしょっぱいデビュー戦が終わりました。(>_<)
先週は１週間工場に詰めていて、ずっとホテル住まいでした。 PCも持っていたんだけど結局ほとんど電源さえ入れず仕舞い。 CPGの実装のための下調べくらいしかできませんでした。
が、その下調べのおかげでCPGの実装がさっくりとできました。 まだ単独で動いているだけですけど。
グラフの赤と青のサインカーブみたいな信号がCPGの出力です。一般的なCPGの出力ではなくセルの表層電位というのを出力に使っています。 そしてあとの２本が足裏の圧力センサーから作った同期用信号。 歩に合わせて振動します。 足裏の圧力センサーの出力だと、足が上がっているときは一定値になり、交流を半波整流したような信号になってしまうのですが、CPGの同期信号にするためには歪が大きい（高周波成分が多すぎる）のではないかと思って簡単なフィルターを通して信号を丸めてみました。
CPGが同期信号に引き込まれているのがわかります。 ずれ（この場合位相のずれが大きい）が大きすぎるせいか、同期までに随分と時間がかかっています。 ← （追記）どうも同期が完了する前に同期信号が途絶えているらしい。
このCPGの出力を使って歩行データを生成したいのだけど今実装しているオフライン歩行生成ではマッチングが悪くてオンライン歩行生成にすべきなのですが、オンライン歩行生成がよくわからんのでそちらに行くのもちょっと躊躇。 ココから先の実装はこれから考えます。
検討メモ
赤：X0（表層電位0） 青：X1（表層電位1） 緑：S0（外部入力0） 黒：S1（外部入力1）
赤と緑、青と黒がセット。 ちょうど位相が逆転して入力されている。 外部入力が終わる間際くらいが同期が完了したところ。（それぞれのセットの同期があっている。） その後、外部入力がなくなるとともに元の波形に戻っている。 位相は引き込まれたものを引き継ぐ。
上の画像では同期が完了する前に同期信号が途絶えているらしい。 同期すると振幅が元に戻る？ 引き込みに際しての位相ずれ方向は決まっている？
いや待て。 事前検討した時にはたしか位相までリンクしなかった覚えが。 更には振幅が入力信号に合わせて小さくなるようなこともなかったはず。
と思ってソースを見直したら、内部状態に表層電位を入力する部分で制限関数を入れるのを忘れていた。 ↓これが正しい引き込みの様子。
■３月１１日■
今日は震災からちょうど1年。 お亡くなりになられた方々のご冥福をお祈り致します。
昨日に引き続きCPG。
CPGの周期を測定する処理を追加してみました。
昨日はなかったピンク色の矩形波があるのですが、これが周期を測っている様子です。
CPGの振動は、今は動きには関係なくフリーランニングしていて、歩くことで発生する外部入力に同調するようになっています。 この測定の時にはたまたま逆位相でスタートしているのですが、こうなるとあからさまな引き込み（同調作業）を経由して同調が完了する様子が見えます。
どうも文献によると位相も同期するみたいで、これでもCPGは同期しているつもりのようです。 入力波形が元のCPGの波形に近ければはっきりするみたいです。
つまり、これを歩行に使う場合、通常からフリーランニングしているCPGのタイミングをつかんで歩き始めるか、普段はCPGは止まっていて、歩き始めることに対してCPGが動作し始めるか、どちらかの仕組みを考える必要がありそうです。静止状態から歩行状態に移行するには歩行周期よりも時間をかけているため、CPGの周期の位相が解明できないと初期値をどのようにおいてよいかわからないのでどちらも同じ問題を持っています。 試行錯誤でタイミングを見つけるしかないかなー。
右足から歩き始めるか、左足から歩き始めるかでも初期値が変わってくるのでめんどうです。
今日は練習会。 そしてロボワン1週間前。
実は今回のロボワンはエントリーするつもりでいたのだけど、2月末から仕事に火がついて、残業どころか家に帰れない日が続いたため、早々に出場は諦めました。 出場の目的は「画像処理でまっすぐに歩行する」というものでした。 「画像処理でまっすぐに歩く」部分は多分頑張れば出来たと思うのだけど、日ごろから実験しかやっていないラムダをイベント出場まで仕上げるには時間が無さすぎでした。 いや、CPGの実装とかやってなきゃできたかも(^_^;)
というわけでロボワン1週間前で大変だ！ってこともないのでロボットは持って行かず、アクオストークを持って行って遊ぶことにしました。
アクオストークの存在はよく知らなかったのですが、UARTなどのインターフェイス越しにテキストを流し込めば合成音声で発話してくれるという便利なLSIです。人形つかいさんに教えてもらいました。 にこにこなどで合成音声でしゃべっているのはアクオストークのフリー版で作成した音声だとか。。。
LSI化されたものが先日のMAKEで売り出されたのですが、ものすごい早さで売り切れたそうです。 そのLSIが再販になったので購入したという次第。
ブレッドボード上で組み立ててターミナルソフトでテキストを流し込むと、かーんたんにしゃべり始めました。LSIの中身はマイコンをモディファイしたものだというので音声データの生成処理にかかる時間が心配でしたが、すばらしく即時にしゃべり出します。 これ、使えそうだなー。 音声はGalatea Talkを使おうと思っていたのですが、あっちの方が処理にもたつく感じがあったくらいです。