開発日誌(19)

開発日誌インデックスへ
前のページへ

最新へ↓

9月1日

今日は遅ればせながら夏休み。

夏場の好きなところ(といっても仕事の都合優先なのは当たり前だけど)に二日休みをもらえるシステムになっているのだけれど、ここんとこ忙しかった上に今年は帰省しなかったので休みを取れずにおりました。 いい加減に休みを取らなきゃしかられるので、今日は予定を入れないように調整してまずは1日目の休みをもらえることになりました。

せっかくの3連休なのだけど、金曜日は大阪出張でそのまま実家に泊まったからロボット的には普通の2連休。

昨日はセンサーボードの細かなところを仕上げたので、今日はラムダのメインプログラムの整理を。

2ヶ月も手を入れてなかったし、その2ヶ月前も発散気味だったので、復習の意味も込めてコードの整理をしました。 テストコードを成長させていってそのままインプリにしちゃうという開発方法なので記述方法がばらばらだったり、古い記述が残っていたりするので不要になった部分はばっさり削除、記述を出来るだけ統一する。

あ、でも不要記述を削除する前に一応バックアップを取っておいた方がいいかなと思ったのが運のつき。

外付けのUSBハードディスクにバックアップツールでバックアップしているのですが、最近なんか調子が悪くてあんまりバックアップしていない。今日もやっぱりおかしいと思うくらい遅いので色々と調べてみました。

「遅延書き込みでデータが失われたかも知れない」という恐ろしいメッセージが出るのでググってみるとアンチウィルスソフトが重いからとか、キャッシュがあふれるとかあるのだけど、マイクロソフトのサポートページでこういうのを見つけました。 修正パッチも出てるし、これがビンゴだろうと思ってインストールしたんだけど、やっぱりダメ。

結局パッチは外しました。 バックアップはラムダのソースコードはバックアップして、その他のドキュメント類はまだバックアップできてない。しかし、ファイルがコピーできないOSって使えないですね。

半日無駄に過ごしました。その上イライラさせられたし。

 

ラムダはざっくりとソースの整理が終わったので、センサーボードが壊れる前にやろうと思っていた作業に着手。 それは。。足の逆運動学計算です。(同時に順運動学計算も、だけど)

斜面に立った時の姿勢の表現方法が気に入らないので変更したいなぁと思っていたのでこの機会に修正することにしました。今まではジャイロのフィードバックを足首サーボにかけるため、足首サーボにだけ姿勢が反映するような表現方法を取っていたのだけど、その方法だと、スタンスを広げた時には広げた分だけおかしな方向にジャイロ補正がかかってしまいます。実質は問題ないのだけどちょっと気になっていたので直しました。 表現は素直になったのだけど、IK計算量はぐんと増えてしまった。

逆運動学計算は完成したけど、順運動学計算がまだ。 もう2時前だから今日は店じまい。 続きは明日だな。

9月2日

昨日の続きで足の姿勢計算式の整備。

以前は随分と苦労したけど、随分と慣れてきて、さくさくと修正できました。 こんなことならもっと早くやっときゃよかったかなー。 この変更はほとんど表には出てこない超マイナーな変更なので、好みの問題でした。

ついでに胴体の姿勢表現も股関節の軸構成に合わせて変更しようかと思ったが、コード修正の影響度が大きすぎると判断してこちらは断念。 超マイナーな好みの問題をあんまり拡大しちゃいかんですから。

これで足の姿勢計算式の修正は完了。

次はマニピュレータの操作クラスの実装をやりたいんだけど、どうしようかな。 マニピュレータって言ってもツメが開閉するだけなんだけど。。。

開閉だけじゃなくて角度を監視して、モノをつかめているかどうかを判断するって仕組みも入れる。 これはアイボ(ERS-7)でモノを咥えられるようにした時にも実装したのだけど、指示角度と現状角度の差を見て判断します。RS302CRを使ってるからトルクやコンプライアンスを調整したり、角度だけじゃなく、負荷を見てつかんでいるかどうかを漢詩することもできるはず。

 

と、思っていたのだけど、お手伝いプロジェクトを見て、思ったのは単眼での限界。 人間が操作しても単眼じゃ色々難しいんですね。 ロボットに判断させるならなおさら。 ステレオ立体視の必要性を感じました。 RPU-100じゃ両目はサポートできないのでダメなんだけど、おかげでマニピュレータでモノをつかむって処理を進めるモチベーションが下がってしまっています。 床のもの限定でのインプリを進めるべきなんだろうけどなぁ〜。(>_<)

 

あと、一つ問題が。

ニューセンサーボードの電源を投入したときにCPUがロックしてしまう現象が頻発する。 どうやら電源投入時のノイズ(もしかしてスパークか?)で誤動作してしまい、リセットしても復活しない。 ハード的な処置が必要なようです。 コンデンサ入れりゃ直るかな。

9月3日

今日は朝から大阪出張。 ヤフーで調べた電車の時間に合わせて指定席を取って、それに合わせて最寄駅から電車に乗ったのだが、携帯で調べたら間に合わないことになってる! ちょっと迷ったが、乗換駅で指定席を変更して20分ほど遅い新幹線に変更。

横浜線に乗ろうとすると、どうやら横浜線が遅れている様子。。 こりゃぁ指定を変更したのはビンゴだったなー、と思っていたら遅れていた電車がすぐに来て、元もとの新幹線に間に合ってしまった。(ぎりぎりだったけど。。) ナイス判断だったのかハズレだったのか、微妙。。。

帰りの新幹線も在来線が遅れていて、マジでぎりぎりだった。 間に合ったけど。。

 

今日は加速度センサーのレベリング。 センサーが変わったので取得値のスケールが変わっている。 静止時の胴体姿勢は加速度センサーの値から算出しているのでレベルを合わせる必要がある。以前のセンサーが75で1Gだったのに対して今回のセンサーは200で1Gなんですね。加速度センサーも、ジャイロセンサーに負けず劣らずノイズが乗ってます。 ジャイロと違って累積しないのであまり気にせずともよいのだけど。

ちなみにジャイロも変換係数が変わって、こちらは前が193だったのが、今回は100。 90度回転した時の累積値は、前は3860で、今回は2000。取得周期に依存する値です。取得周期は25msでした。

今日はこれしかできなかったなぁ。 手が変わったから起き上がりモーションに手を入れる必要があって、それも今日やる予定だったのだが。。 ちんたらしてますねぇ。

9月7日

昨日はお手伝いプロジェクトの決勝。 観に行って来ました。

川崎アゼリアのアゼリア広場でってことは地下街のオープンスペースでの開催なんですね。

川崎は地元だし、11時からだし、ってことで朝からラムダの起き上がりモーション修正などをやっておりました。 逆運動学計算の関数を変更したのである種の姿勢では随分と影響を受けてしまいます。 更には腕の形状が変わったことでの差分も含めてパラメータの変更などをやってました。

そういうわけで40分ほど遅刻して現地到着。 すでにトコトコ丸やアエロブルーのファッションショーは終了していました。トコトコ丸のファッションショーを見逃したのは失敗だったようです。ロボットに早着替えをさせるなどというのはロボット的エンタメの雄、網野さんならではの演出。 ファッションショーというイベント名にうっかりとだまされてしまいました。

オープンスペースなので普段はロボットのイベントなぞ絶対見ない人たちが立ち止まり、去っていきます。周りの人たちの反応がなかなか面白かったです。

お金を握って買い物に向かったクロムキッドがうっかりお金を落としてしまったとき、(くぱぱさんは全然気付いていなかったらしいですが) 「お金を拾わないねー」「お金は拾わないんだー」とお金に執着(^_^;) 転倒から起き上がれることは「おぉぉぉ〜」と歓声が上がるのだけど、お金を落としたのに気付かないことやお金を拾わない(拾えない)ことは意外なようです。 実は技術的にはそちらの方が格段に難しいのですが。

お買い物をそつなくこなしていたな、と感じたのはトコトコ丸、ファイブ、アリモプレナ。 ファイブは現状での現実解として、頭にあるスイッチを店員に押させることで強制コミュニケーションをとる手段をとっていました。 なるほどアイディアなんだけど、現実的過ぎるかなぁとちょっと思ったりしました。

自分的には現金を握り締めて(落としちゃったけど)買い物に行き、 間違えて重い靴を選んでしまって、それを袋に入れて引きずりつつ歩いていたクロムキッドが切ないほどに良かったです。 たしか、わんだほ〜ではガルーがボトルトラクションでかごを前から引っ張って歩いてましたけど、あのモーションを使えば重い荷物を引きずって歩けたのでは?

あと、自動追尾のカートと犬じろうを引き連れて買い物に来たくまたろうが途方もなくかわいかったですよ。 いぬじろうが迷子になってしゃがみ込むモーションが発動しなかったのはとても残念です。(^。^)

足を作り直して決勝に望んだアエロブルー。 見違えるように安定した歩行で、カートを押しながら歩いていました。 カートをつかんだまま方向変換までしていたのはすごいですね。見たところ上半身は同期して動作したりはしていなかったので、それだけ左右の振幅が小さいモーションで歩いていたということです。

問題があるなと感じたのはコミュニケーション。 会話が成り立たないシーンが多過ぎ。 後半になるにつれ、店員が状況を理解して優しくなって行きました。

トコトコ丸は打ち込みで音声合成。 アエロブルーはIPで音声伝送。 その他は仕込み音声の再生。 音声伝送を使ったアエロブルーが一番スムーズかと言うと、伝送ラグが大きくて衛星中継みたいになってました。優先制御して音声ラグを最小にするなどの対処が必要のようです。 仕込み音声は用意した台詞がすぐに出てこないのとシチュエーションが予想を超えていて適した台詞が用意されていないこと。いやぁ〜、第二回までにやることいっぱいありますねー。

 天下(地下だけど)の往来にしゃがみ込んでしゃべりこむおじさんたち。 オーイ子供が見てるよぉ〜。

そろそろ決勝も終わるってころには外野の話題はロボワン大会のスロープをどうやってクリアするか、という話題になっていました。

先日、認定権をゲットしたガットを筆頭に大型ロボの多くはリンク構造を採用しています。 先ごろから話題にしているリンク構造と二関節筋の関連からも明白なようにリンク構造と斜面歩行は非常に相性が悪いはず。

何より平坦な路面とある程度の傾斜を持った路面を同じ歩容で歩くってのは無理なんじゃないかと思います。ラムダならどうやるかなぁ。 ラムダは平地を歩くのがやっと。 斜面なんかまだまだ先の話なんですが、歩行を安定化させるにはけり足の制御をどうするか、という問いから「階段をどうやって昇るか」という内部設問をして足構造や制御方法をを考えている最中なのでいくつかアイディアはあるのだけど、まだ形にならないですよ。>なぐさん

歩容の切り替えという部分では、 認知学の世界でアフォーダンスって考えがあるのだけど、その中でもテクスチャーが重要な情報になっているという話があります。 人間が歩くときも目をつぶったままで急に傾斜が変わるとつんのめってしまうので、歩く先の路面がどうなっているかを判断して傾斜に差し掛かるタイミングを図りながら歩容を切り替えています。 まだ画像処理でテクスチャーから路面の傾斜を測るってのは難しいと思うので、せめて平坦な路面と傾斜のある路面が違う色になっているとか、そういう配慮があれば何かできるかも知れないですね。 フラッシュや騒音で誤動作するようなロボットはダメだってのがロボワンスタイルなので環境を易しくしてくれってのは期待しちゃいけないのかもしれないです。 ただ、センサーを使ってロボットに何かを判断させるフェーズに差し掛かってるかと思うんですが、ある程度は環境を考えないと進歩の目を摘んでしまうのではないかなと思います。

その後、ロボワン委員会と一緒に打ち上げに行きました。 すごく色々あったんだけど、日誌書いてて休日が終わったらシャレにならんのでこの辺で。 あ、次回のおてプのテーマは今回とは変わるらしいです。そりゃそう、そりゃそうなんだけどな。

9月9日

実は7日におてプのことを日誌に書いた後から、先ほどまでどっぷりとはまっておりました。

おてプ決勝に行く日の朝にモーションの修正に着手していたのですが、7日は一日起き上がりのモーション修正などをしていました。

足の姿勢表現を変更したことでの、逆運動計算と順運動計算関数の修正は終えていたのですが、歩行以外のモーションでは欠かすことのできない(ラムダの足構造から起因しているので普通の足構造なら関係ないんですが)J1Z処理にも大きく影響することがわかりました。 とりあえず、平地でのJ1Z変換だけはすぐに対応してモーション修正を続けたのですが、お辞儀状態になると、相対的に斜面でのJ1Z変換が必要となり、これはすぐに対応できなさそう。

更には関節角度の動作域外への指示をキャンセルする処理を加えたところ、さっぱり立ち上がれなくなったりまでしました。 その後、試行錯誤の結果、立ち上がりはできたのですが、お辞儀状態でのJ1Z変換は課題となったのです。

日曜日は半徹夜で試行錯誤し、(考えすぎて頭が興奮しちゃって。。(^^ゞ ) 月曜日はアイディアを整理して再度トライしたが撃沈。。。 そして火曜日の今日、さきほどやっと任意斜面でのJ1Z変換の実装ができました。

   これができないと床のモノが拾えないんですよ。

今回の足の姿勢表現の変更は、斜面への対応を足首だけで表現していたのですが、実はナンチャッテIKになっておりました。

でも、そのお陰で(誤差は少しあるものの)斜面に対応するのも足首とその他の姿勢を分離して計算できていました。スタンスを大きくとると誤差が大きくなったんですけど、実用上はまぁ問題ない。

そのままでも構わないっちゃぁ構わなかったんだけど、ずーっと気になってたから思い切って今回直してしまったというものです。

ですが、J1Z変換では足部の姿勢角度、特にチルトとロール(ピッチとヨーの方が伝わるか)が関連しているのが問題で、計算方法がわかりませんでした。

今回はなんとか解決したけど、なんだかもう大変ですね。 この足構造にこだわるつもりはないんですが、メカの見直しをして開発が後退するのがイヤで踏んばってしまいました。 問題も解決したし、そろそろこの足構造もやめちゃった方がいいかも知れません。

IKで動かすロボットの足構造は大腿ロールは採用すべきじゃないですね。

さて、忘れないうちにメモを書いておかなきゃ。。

9月10日

J1Z変換は完了していませんでした。

昨夜、日誌を書いた後、立ち上がりモーションへの折込を行ったところ、おかしい挙動が発覚。 或る姿勢で足首がそっくり返ることが判りました。

いろいろいろいろ調べた結果、基本となる逆運動計算で、角度に補正をかけている部分が悪影響していることと、足裏の斜面から関節角度を算出する部分で±90degまでしか考慮していないことが問題であることがわかりました。

逆運動学計算の補正というのは、適当に補正しているわけではなく、 股関節の姿勢を三つのサーボで表現しているのだけど、或る姿勢を表現する角度の組み合わせは2つあります。 この2つの組み合わせのうち、サーボの動作範囲に収まる方を採用する必要があるのですが、単純に計算したら、サーボの動作範囲を超えた計算結果を出すことがあり、これをこちらの都合のいいほうに切り替えるための補正です。

ところが、幾何的にはこの2つの組み合わせは違うものらしく、補正をかけた角度列では順運動計算と逆運動計算で相互変換が出来なくなってしまうことがあるようです。

このため、J1Z変換の中で行っている逆運動計算と順運動計算でこの不整合が起こり、結果として足首のサーボにそのしわ寄せが来て足首がそっくり返るということらしいです。

でも、逆運動学計算での補正は必須で、補正をかけないとろくに動けなくなります。 仕方が無いので関数内に補正スイッチを持ち、J1Z変換内で逆運動計算が呼び出される場合は補正スイッチを切るようにしました。

また、斜面の傾きが±90degを超える場合の処理ですが、J1Z変換上の斜面は胴体姿勢が垂直な状態に変換して足首姿勢を計算しているので、垂直を超える床面を考える必要は無いように思えるのですが、計算対象は床面と脛の関係なので、しゃがみ込んだ場合などに超えてしまう場合がありました。 これも関数をatan( )からatan2( )に変更することで解決。

これでやっと見えている不具合は解消しました。

それにしても逆運動学は難しいです。 ラムダの足なんか、すべて直交にしていて、解析解が得やすい構造になっているのに、斜面に対応する計算をサポートするだけでこの騒ぎです。 大腿部にロール軸(ヨー軸)を入れたことが、問題をややこしくしているのですが、この構造に落ち着いたときはナイスな軸構成だと思って納得していたんですけどね。 関節構造を研究しているならまだしも、総合的にロボットを進めたいわりに意地になって正しい解析解にこだわったりするのはほめられたものじゃないです。

自己批判はさておき、冗長自由度が無く、関節が直交しているラムダの足でさえこんな大変なのだから、幾何学計算での関節操作はやめていかないといかんですね。

お手伝いプロジェクトを見ていたとき、ロボットが机に近づいていくと腕が机に干渉してうまくモーションが働かなかったり、そのせいでロボットが動いてしまって位置がずれてしまったりしていました。 あれじゃダメで、能動関節も、状況により受動関節になるような制御方法の重要性を感じました。 ざっくりしたイメージとしては、動作時の関節負荷をフィードバックし、負荷の少ない動作を選択しつつ、手先座標は画像データからフィードバックし、自前でヤコビ行列相当の相関関数(関数の形である必要はないですが、便宜上「関数」)を生成するような制御システムとなるのではないかと思います。

足姿勢表現の変更によるごたごたは恐らく終了です。 やっと「アプローチ」まで戻ってきました。

9月12日

今日はJ1Z変換の完了記念にちょっと寄り道を。

買ったまんまになっているSEMB1200Aの開発環境のインストールをしました。

インストールと言ってもいちから構築するわけじゃなくて、sugi3 の趣味のページでダウンロードできるバイナリーパッケージを展開するだけです。 一番大変だったのはCygWinのインストールだったりして。。

テストプログラムをコンパイルして転送して動かしたりしていたのですが、こないだつけた放熱板は触れるか触れないかギリギリくらいまで熱くなります。CPUがいってしまったらシャレにならんので即席でヒートシンクにファンを取り付けました。

ファンをヒートシンクの上に置いてあるだけなんですけど、これでファンは随分と冷えます。 薄いヒートシンク+ファンの方がいいのか、でっかいヒートシンクの方がいいのか、ファンは小さくても十分なので、ロボットに積むことを考えるとファンを積んだ方がいいのかもしれないです。 でもファンが止まったりしたら心配だな。ファンアラームを付けてファンが止まったら電源を切るようにするとかの処置が必要かも知れないです。。

SEMBの方もぼちぼちと進めねば。次はSEMBのたくさんあるCOMポート全てをRS485にする予定です。(COM1を除く) それができたらシグマに積んで関節情報を取得しながら歩行するってのをやってみる。 10日の日誌に書いた能動+受動関節ってのをどうやったら実現できるかっての少し考えてみたのだがSEMBならテストくらいはできるかもしれない。 でも、SEMBでやると結局はフィードバック周期はサーボのコマンド条件で決まってしまう。 フィードバック周期10ms程度じゃちょっと無理かな。。(^^ゞ

9月13日

なんだか肉体的に疲れているようでどうにもウダウダ気分。 朝はそこそこ早く起き出して朝食を食べるのだけど、その後に二度寝しちゃったりして。。 午後も少し出かけたあと帰ってからは昼寝してました。 でも、疲れているときは寝るのが一番。

モーションがどうも安定しないので試行錯誤を繰り返しています。 どうも腕を動かした時の安定性が悪すぎる。。 あ、、、、そういえば、マニピュレータを付けてサーボが追加になったのに部位毎の重心データを更新していなかった。 更には肩にオフセットをつけたこともデータに反映していない。 腕が長くなった上に末端重量が増えたのだから影響は大きいだろう。

3DCADを使って重心と質量を計算。 データに反映しました。 足裏をエラストマに変えたのが影響しているのか、まだJ1Z変換の切り替わりタイミングでの不安定さを残しているが、腕を前に出した時の不安定さはなくなった。 手を出した時のお尻の突き出し方がちょっと違う。

 前屈〜。 地面に手が届いた。 床に落ちているモノは、なんとか拾えそうです。

関節制御のヒントをもらうために本を買おうかと思い物色。 有本 卓博士の“巧みさ”とロボットの力学 これって、知能科学―ロボットの“知”と“巧みさ” とどれくらい内容が違うんだろう。(^^ゞ 後者は持ってるからなぁ。 どっかで立ち読みするか。

そのうち買おうと思っていた OpenCV プログラミングブック も一緒に買おうとしたらアマゾンに売ってない。 なんだかどこにも売ってない様子。マーケットプレイスの中古が定価より高くなっているし、何があったのか???

9月14日

今回の一連の見直しに際して、姿勢移行動作のほとんどの場面で各関節の可動域のチェックを行うようにし、一ヶ所でも動作域を超える場合はそのフレームを実行しないという処理にした。 そうしたところ、立ち上がりモーションなどがほとんどうまくいかなくなりました。

いままで「立ち上がれる」と思っていたのが偶然というか場当たり的なものであったのが暴露された。 プログラムを修正したり、モーションを工夫したりしてなんとか立ち上がれるようにはなった。 なったにはなったのだが、本来はモーションを生成させたいと思っているのに、この微妙な調整をプログラムで生成させるってのはなかなかに難しい。 動作制御については計算だけじゃないものが必要だなぁと感じることが多くなった今日この頃です。 試行錯誤の仕組みを真剣に考えてみようかな。

 

ふいに思い立ったので、SEMB1200AのCOMポートにRS485インターフェイスをつけて通信させてみようとしたのだが、SEMBのCOMポートは3.3V出力らしい。 MAX485は5Vのチップなのでレベルコンバータが必要。 レベル変換については浅草ギ研にこんなページがあって詳しく説明されてます。 3.3V→5V 5V→3.3V 3.3V←→5V それぞれの変換が出来る部品を注文しました。 SEMBにはいっぱいRS485をつけて同時に通信をするってのをやってみるつもりなのでRS485も足りない分を買い足しました。って言っても手持ち合わせて8個だけど。 部品が来たらとりあえず1回路だけ組んでテストプログラムを走らせてみよう。

 

ラムダにもどって、、、 一応は立ち上がれるようになったので、アプローチの練習をしようかとも思ったのだが、そういやラムダが壊れる前にやろうと思っていた「大きさが判っているモノをカメラに写った大きさで距離を目算する」というのをやることに。

ま、単なる比の計算なのでなんてことないのだが、トラッキングさせてカメラの中央にある状態なら大体いい感じの答えが出るようだ。超広角レンズなので収差が大きくて画面の端だとひずんでしまうんですね。

 ボールを見つめるラムダ

 カメラに写ったボール ボールを囲う四角の大きさから距離を計算する。

 d:ってのがボールまでの距離 単位はmm

光の加減もあるのでたまにへんな数字を出してますが、大体170mmくらい

距離も座標もわかったからこれでつかめるはずなんだけど、このボールは大きすぎてラムダの手ではつかめない。 つかめるものを用意しなきゃ実験できないな。(^_^;)

9月15日

関東組ロボット練習会に参加するため、ろぼとまに行って来ました。

フル装備で参加するのに、だべって帰ってくるだけで開発はさっぱり進まないのがいつもの練習会参加なのだが、今日はひたすらプログラムとデバッグ。

なので、あんまりみんなにからまなかったなー。 いや、練習後に食事に行った先では色んな話で相当盛り上がりましたが。

 マルイチまだ読んでないんだよね。

練習会会場でプログラムしていたのは、グリップ。 ただモノをつかむだけじゃなくて、指定した強さで掴みます。対象の大きさは(掴めれば)関係なく、自動調整(ってほどじゃないけど)します。 なので、無理やりツメを開こうとすると、徐々に開きますが、手を離すとすい〜っとツメを閉じます。 コンプライアンススロープ設定と、サーボ角度の取得を使って行います。

あと、センサーボードを作った時にSPI通信で無線コントローラをつないだので、ラムダをコントローラで操作できるようになりました。 あくまで自律を目指しているので操縦型ロボットにするつもりはないのですが、コントローラで腕を操作できるようにしたりして遊んでました。

 ラムダはアヒルちゃんを見てるわけじゃありません。 たまたまです。

この画像を撮影するためだけに練習会から帰ってラムダを立ち上げました。(^_^;)

あ、そういえばOpenCVプログラミングの本を売ってる通販サイトを見つけました。在庫1冊です。 でも、溝口の書店にあるという話も聞いたのでそっちを先に見てこようかな。あちらこちらの書評を見ると、Webで見れるリファレンスがメインってなってるのでちょっと躊躇中。目を通してから買った方がよさそう。

9月16日

ラムダは線形倒立振子の軌道を使って歩容を生成しています。

ですが、上体を残して、いわゆるモンローウォークのように歩かせると計算値では全然合わなくて横にすっとんでしまいます。 色々試行錯誤した結果、股関節を固定して、支持点を中心に左右に揺れるようにすれば補正値を加えるだけでそこそこ歩けるようにはなりました。 ですが、考えると前後動作は股関節を境に上体は固定して足だけが動いている状態です。 それに歩けるとはいっても計算値どおりではなく補正値を大きく加えているわけでさっぱりダメなわけです。 補正値が必要な理由としては一点質量ではなく、分布質量であるから、質点は静止重心ではなく、相当単振子で算出される位置になるとか、前進の剛性が低いからだとか色々と考えておりました。

その中でも、ロボットは倒立振子ではなく、二重倒立振子で計算すべきだということがあります。足が一つの振子で、股関節から上は別の振子が逆に揺れているというイメージです。足の振れを相殺するように逆に振れば上半身が回転しないように見えるということです。

それで倒立振子と二重倒立振子を比べてみました。↓

パラメータが適当なのでまだわかりません。 補正値を入れていない計算結果で比べています。

二重倒立振子の方が振れ幅が若干小さいのですが、これでもまだすっ飛びそうな感じだな。どちらも重心位置は静止重心を想定しているので、これを相当単振子で計算すれば更に結果はいい方向に変化するはず。二重振子の方は上半身を振ることで下半身の振れ幅を押さえる事も可能です。 上の図では上半身は振れないようにしています。

計算式はこちらを参考にさせていただきました。「Reseach」の中の資料に詳しく書かれています。

 

今日の帰りに「OpenCVプログラミングブック」を探しに本屋めぐりをしてきました。 が、結果は無収穫。 どこにも売ってませんでした。 昨日見つけた通販も帰ってから見ると「売り切れ」。 まいったなーと思ったんですが、本の目次をよくよく見ると、解説されている画像処理関連の内容って結構基礎的な事しか取り上げられていません。それくらいなら我が家にある蔵書群でカバーできそうです。 リファレンスとサンプルソースはネットから落とせるので、本を買う必要はないですね。 ちなみにJBOOKなら在庫ありそうです。要は出版社と直結のネット通販は全滅なんですが、本屋さんは在庫として持っているので、あるところにはあるんですね。 在庫がありそうなのは文教堂だけでしたけど。

 ラムダに掴まれるものたち

黄色のアヒルちゃんはラムダの目には合わなくて、ラベリングしにくそうなので、ラムダに見えそうでつかめそうなものを取り揃えてみました。 ピックアップされてくれ〜。

9月17日

二重倒立振子の続き。

相等単振り子の腕の長さを計算するには慣性モーメントを計算せねばなりません。 慣性モーメントの算出関数は以前に作っていたのですが、どうやら胴体姿勢を考慮していない記述になっているらしい。 自分で書いたプログラムが理解できなかったりして、あれ?もしかしてこれ計算むちゃくちゃだったのでは?とか思いましたが、確認した結果どうやら正しいらしい。 そして何度かの勘違いの末に準備できたのでいざ計算!

 オレンジの丸が静止重心、 緑の丸が相等単振子の質点

まず、Y軸周りでの計算結果は、足の重量は605g 静止重心位置は下から100o  これに対して相等単振子では下から169mm

次に足以外(左足も含む) 重量は2365g 静止重心位置は下から227mm jこれに対して相等単振子では下からなんと、946mm 画像に入りませんでした。

ほんとかなーと思うんですが、股関節を固定した歩行での試行錯誤の補正値は+200mmくらいだったので、重心位置450mmくらいで動かしていました。それを考えるとあながち外していないかも。

 

次にX軸まわり

 オレンジの丸が静止重心、 緑の丸が相等単振子の質点

足の重量は605g 静止重心位置は下から100o もちろんさっきと同じ。  これに対して相等単振子では下から148mm 

足以外の相等単振子では下から724mm

慣性モーメントが変わるので相等単振子の腕の長さも変わります。 重心を上にした方がいいだろうということで手を腰辺りに構えているのだが、これが慣性モーメントを大きくする結果となっているようだ。 X軸周りでは股関節付近に手が或る個トンなるので慣性モーメントを大きくする働きは無いので相等単振子の腕の長さもその分短くなっているということだろう。

この結果を倒立二重振子の計算に適用すると、

昨日、適当にパラメータを入れた場合より更にふり幅が小さくなっている。 なんだかこれは期待できそうだなー。

ちなみに、パラメータはY軸周りの結果を使っています。X軸周りのグラフはほとんど直線なので、この程度の数値差だとグラフに差はでませんので。。

9月18日

二重倒立振子軌道での歩行。

昨日の計算結果ではいい感じの答えが出たので、歩行させてみるべく軌道計算をラムダに組み込む。

参考にした論文では上半身を左右に振ることで腰の振幅を抑えるということをやっているのだが、この考慮を入れている関数は、足のスタンスを変えられない。 姿勢を変更する際にすり足ではなく、足を上げてスタンスを変えるという動作を行いたいのでスタンスを変えられないのはちょっとイヤ。

結局、上半身を左右に振る実装は諦めて、前後方向の二重倒立振子の関数を左右にも適用することでスタンスも変えられることとした。

歩かせてみたところ、補正などはなくても歩ける感じ。 パラメータ調整などをしてみないと安定度は判らないが、倒立振子を使った歩行よりは歩幅が大きく取れそうな予感だ。

二重倒立振子と相等単振子。 この組み合わせに答えがあったのか〜。 うれし〜。

いままでは出来なかった遷移時間0.6秒とかでも歩けそう。これでもっと大股であるければすごく嬉しいのだが。

パラメータを色々変えて歩かせていたら、なんだか起き上がりがまたできなくなってる。なんでだ??? と見てみると、腕の金具がちぎれてる。 ラムダが動き始めてちょうど3年。スピーシーズロボットキットを買ってからはもう3年半くらいになる。 色々ガタが出てもおかしくない年頃なんだな〜。

腕の金具、土曜日に直します。

9月19日

歩行パラメータの調整をやりたいところだが、腕が壊れているので今日はできない。 代わりに、受動関節の実験をやってみた。

二足歩行ロボットが不整地を歩くとき、遊脚が接地したときに地面に倣わなければならない。この、倣う関節が受動関節なのだが、二足歩行ロボットなので足首がくたくただと立てない。 そのため、同じ関節で受動関節と能動関節を切り替えられなければならない。

簡単には出来そうにないのだが、サーボを操作する周期をはやーーーくすればできるんじゃないかと思えてきたのでちょっと実験することにしました。 まずは受動関節の実験。ただ単に路面に倣って関節が動くだけならばサーボを切っておけばいいんだけど、能動関節に切り替える際に路面に倣ったままの状態になるようにするには関節角度を常に把握しておく必要があります。

ラムダのプログラムはシグナルを使った割り込みで動いているので、あまり周期を早くすることができません。1つのサーボに対して角度の取得と角度の設定をバシバシとやるので最速だと2msくらいの周期での動作が可能なはずだ。 そのためには割り込みなぞ使わずにwhile( )ループで命令を実行し、usleep( )の時間を調整して同じ周期で命令が実行できるようにします。

試したところ、コンプライアンススロープをうまく使えば受動関節っぽくはなるんだけど、ちょっと速度が遅い。トルクを抜いて、角度だけ監視した方がいいのか、ちょっと迷うところ。 ただし、トルクを抜くと跳ね返りが出てしまって良くない。 制御周期は2msでも動作するんだけど、10msくらいまでは感覚的には差が無い。15msになるとちょっとゴツゴツする感触がある。もう少し検討する必要があるが、歩く速度に比べると反応速度が遅すぎる感じ。 もっと反応を早くする工夫が必要だ。

9月20日

今日は朝から本当に張り切って作業を開始。 まずは昨日の受動関節の続き。

路面に倣いながらもトルクを与えたいってことで、コンプライアンススロープを使って外力に反応するようにしているのだが、実関節角度に従って設定角度を変えてもスロープ設定のお陰で反応が鈍いのでは、 という前提で動作させたい方向にはスロープが急な立ち上がりになるようにプログラム。

幾分かはスムーズに動くようになったのだが、まだまだ重い。

パンチ設定なんかも動員して色々試したのだが、際立った成果はなし。

 

日も随分高くなったところで、一昨日ちぎれた腕の部品の製作に取り掛かる。 ラムダのフレームは全体的に強度に機を使った設計をしたつもりだが、ちぎれた部品は目立って弱そう。 ちょっとやそっとじゃちぎれない形状にしてみた。 その分曲げるのが難しくなったのだが。

腕も治ったので起き上がりモーションをさせてみたら起き上がれない?あれあれ??と思って何度もやってると起き上がれるようになってきた。 サーボがへたらないとだめなんだな。 (^^ゞ 情けないモーションだ。(^_^;)

 

さて次は、SEMBのインターフェイスボードを作ろうかと思っていたのだが、ちょっとわきみちに逸れてC7ボードのLinuxを立ち上げてみたりした。 そろそろOpenCVをインストールして画像認識をさせてみたり、音声認識をさせたりするってのをやり始めようと思っているのだ。

そういや、、 CFカードにインストールした手順ってすっかり忘れてしまったな。どっかにメモってないかなーと思って探したのだが ない 。。 ううむ。。また同じ苦労しなきゃならないのかなー。 それより、HDDにインストールした方のDebianLinuxはXもインストールされているのだが、C7用に買った中古の液晶ディスプレイだと解像度が合わない。

インストールしたときはメインPCのディスプレイを使ったのだが、これに合わせたコンフィグレーションになってしまっている。 これを修正しようとしたのだが、やり方がわからなくて、、 それよりルートのパスワードを忘れてしまっている。 ん〜、大体いつも同じようなパスワードにしてるから当たるはずなんだけど、わからない。 気持ちが悪くなるくらい試したところで諦めてCFから立ち上げてパスワードを無理やり消すことにした。早くそうすりゃよかったんだけど。。。 そしてログインしようとしたところ、やっぱりできない。。 そしてその後にgdmのグラフィカルログインの設定はrootではログインできないようになっていたのでした。がっくり。。

その上結局Xの再設定はうまくいかず、情けないことにOSから再インストールすることにしました。

Linuxで開発環境を構築したいんだけど、必要なツールと設定がさくっとインストールできるパッケージってないんですかね? Linux使ったことないんでわからんです。

 二重倒立振子で歩くラムダの姿。 撮影時は止まってたんだけどね。

歩行パラメータの調整。

ちょっと歩かせるとすぐに膝が熱で落ちてしまうので、放熱板をつけてみた。 

 かっこわりー

かっこ悪いけど、効果は十分。 でもこけるとすぐに外れてしまいます。 膝の裏側に取り付けるように考えてみよう。

 画像中央が作り直した金具。 曲げるのに苦労しました。

 

明日はSEMBからスタートの予定。

9月21日

今日はSEMBからスタートのはずだったが、歩行安定化のために足裏の改良からスタート。 朝、布団の中でやってみようと思い立ったのだ。思い立ったが吉日。

  つま先側はエラストマー、かかと側はプラバン

足裏をグリップさせて安定歩行させるにはまだ色々足りない。かかとをスリップ足にしてつま先上げ気味で遊脚復帰させてみる。 プログラムはまだ。

次に手がけたのはC7の電源ケーブルの配線修正。 C7もいつまでも基板むき出しだといつか事故が起こるからケースに入れたい。 C7用に買ってきた超小型ATX電源のケーブルをC7の電源ケーブルに直付け。 電源込みの大きさがケースの大きさになる予定。 コネクタ配線にするつもりが、作業中にコネクタのピンが折れてしまい、やむなく直付けに。

ストレージ用の電源コネクタも、普段は必要ないので切り離せるようにした。

次にSEMBのペリフェラルボードに取り掛かったのだが、まず部品情報を整理して、ノートに回路図を書く。 必要なコネクタとコネクタの配置を決めて、部品を配置していく。

3.3V系と5V系が混在しているのでこんがらがりそう。まだ実験段階なので3.3VはSEMBからもらってくることにしました。容量足りないってことはないよね?きっと。

そして、調べ物したり、はんだ付けしたりしながらLinuxカーネルの再構築をやってみる。 ディストリビューションのカーネルは全部入りなんででかいし立ち上がるのに時間がかかる。もうちょっとブート時間を短くしたいので必要ないものをそぎ落としたいのだ。

 これが、カーネルのコンフィギュレーション画面。 xconfig

何が削れるのか削れないのかわからん。(^_^;)  ちなみに開発環境はapt-getってコマンドでびしばしインストールしとります。 まだ、HDDでお試し構築なのでなんでもアリで。

そして、これがSEMBにペリフェラルボードをつけたところ。 無駄にスペースが余っているように見えるが、まだ、最終的に6個搭載する予定のMAX485とそれ用のコネクタが1個ずつしか乗ってない。 そのほか、3軸加速度センサーとちっこいマイコンも搭載する予定。CSIはコントローラ用として、マイコンとSEMBの通信はCOMを使えばいいかな。(SPIとCOMを持ってるマイコンを使えばSEMBのCSIが空くね。そっちの方がいいかな。 まぁ、後日考えよう)

 やっぱり電源投入はびびる。壊れなくてよかった(>_<)

でも、これはまだ電源回路しか配線が完了してません。続きは明日。

9月22日

今日は平日なのだが、自由取得の夏休み2日目としたので4連休♪(^・^)

昨日の日誌を書いたあと、足裏を変更したラムダを(プログラムを変更しないで)歩かせてみたのだが、歩かないことこの上ない。 足裏の後半分(以下)をスリップにしたことでけり足が利かなくなってしまった。 その場で足踏みを続けている感じ。逆に、こないだまでうまく歩けなかった後退歩行ができるようになりました。(^^ゞ

つまり、恐らくつま先側をスリップにしてかかと側をグリップにすれば歩けるようになる気がするのだけれど、それじゃ意味が無い。 人間の場合けり足はつま先部で蹴っているが、通常のロボットはかかとも着いているので事情が違うんだな。 歩き始めにつま先部に重心を移すようにしてグリップしやすくしてみよう。

遷移時間が短いとそのような状況なのだが、遷移時間を0.6秒くらいに長くするとこれでも歩く。 速度が遅いとグリップできるって事ですね。

それでも一応はグリップ足なので、ずっと歩かせると左右動作の同期がずれてきてそのうち横に吹っ飛ぶ。振子なのだからその振子に対する振子周期が決まっているはずで、その周期で歩かせようとするならば、それに応じた相等単振子になるように姿勢を変更しなければならないし、 姿勢が決まっていればその姿勢に適した周期で歩かねばならないはずだ。 一眼レフカメラのシャッター速度優先と絞り優先みたいな感じ? ここんとこももう少し仕組みがいりそうだ。

今日は午前中からSEMBのペリフェラルボードの配線。

1回路だけ組んで、その後にケーブル配線も1回路分だけ終わらせました。 以前に紹介した小さいコンタクト用の圧着工具株式会社ENGINEERの精密圧着ペンチPA-09でSEMBのコネクタコンタクトの圧着できました。ZH型コネクタよりフィットしている感じです。 でも、小さくて作業は大変。 自分が、「手先が器用な人」に分類されると思っている人ならなんとか作業できるでしょう。

さて、回路もテストする分は組めたし通電試験してみましょう。。 ・・・何かおかしい。3.3V出ているはずの端子に2.5Vしか出ていない。 SEMBへの供給電圧5Vも2.5Vになっている。あれれ?ショートしたか? と思ったが、5Vのレギュレータがとてつもなく熱くなっている。 どうも過剰供給で電圧降下を起こしているらしい。 SEMBのドキュメントを調べるとSEMBの消費電流は7V時に600mAらしいので5Vだと1Aくらい。 ぎりぎり間にあうはずだけど、、、 まぁいいや、SEMBへの供給電圧を9Vまで上げました。 そのため、ペリフェラルボードに必要な5Vを別途作ることになってしまった。 多電源のボードは良くないなぁ。 

今日は夕方から出かけることになっていたので作業はここまで。SEMBの続きは明日へ。 ハード作製はやたらと手間がかかるから一気に作り上げてしまいたいなー。

9月23日

歩行の検討をやりたいところだが、ぐっと我慢してSEMBペリフェラルボードを進める。

RS485が1回路完成したところで、プログラムを作って動作を確認します。 といってもSEMBでプログラムを作るのは初めて。 こういう類のペリフェラルLSIを操作するものってATMEGAもそうだけど、レジスタ操作が面倒でなかなかプログラムが進まない。(わかってしまうと簡単なんだけど。。) とっぱしから引っかかるのはいやなのでLEDを点滅させることから始める。 実はこのLEDを搭載するのに一苦労して、 LEDの極性が間違えた〜⇒LED付け替えたけど光らない?⇒アースがイモはんだになってた⇒Hレベルで光るんじゃなくてLレベルで光らさなきゃ⇒ぎゃーIOポートは3.3V系だった(LEDに5V供給してた)⇒3.3Vなら抵抗もっと小さくしたほうがいいか? というとっちらかった状態から始まったのだけど、 ・・・LEDが光らないんです。(>_<) ⇒ 案の定レジスタ設定を一つ忘れてました。 ってな感じで暗雲立ち込めるスタートとなりました。

一番簡単なはずのIOポートの操作が一番手間取って、RS485の方は比較的すんなりと進行しました。

RS485は半二重通信なので、SEMBの持っている1wiredUARTで十分なはず。SEMBは32ポートあるPWMサーボ制御線のうち8本をUARTとして使えます。それも、8本を 1wireUART×8 か 2wireUART×4 どちらでも選べます。(1wireと2wireの複合設定もできます) 今回は6本を1wireUARTにしてサーボとの通信に、2本をセットで2wireUARTにしてマイコンとの通信に当てようと思ってます。

今日はRS485とする1wireUARTの動作確認。

今のラムダのCPUであるRPU-100を対向装置にしてRS485通信のテストをしたところ、それらしい通信は出来てる感じ。 ただ、ちゃんと届かないのはプログラムのせいか? どうも受信がおかしくて、1byteでも受信したら、いくら受信レジスタを読み出してもFIFOがカラにならない。 おかしいな〜??? という状態が長ーく続いたのですが、もしかして、UARTが1wireのモードになっても送受信の排他処理をしていないのでは? だとすると、送信時には受信ポートはHi-Z状態となっているので、それをFFとかFEと読み取ってもおかしくないかも?? この考えが正解かどうかわからないのだが、半二重通信、それも相手はスレーブなので前触れなしにデータを送ってくることは無いという前提でプログラムを組んで、なんとか正しく送受信できるようになりました。

でもでも、せっかくの高速CPUなのに割り込みファンクションが少ないので、UARTの送信完了を待って送受信を切り替えたりしなきゃならない。ATMEGAのUSARTだとFIFOエンプティーだけじゃなく、送信完了で割り込みがかけられたので待つ必要がなかったんだけどな。 せっかくFIFOが63byteもあるのに意味ないじゃん。外部回路でなんとかしたい。

 RS485通信デバッグの様子

RS485が完成したので残りの5回路の作製にとりかかろうかとも思ったが、CSI を先にやることにする。 作ればいいだけってのは後回し。

CSI はATMEGAでSPIで試行錯誤したところなので比較的やりやすかった。 SEMBのPS2デュアルショックコントローラとの通信プログラムが岡田さんのHPからダウンロードできるので、これを参考に最小限必要なプログラムを作成。 これも初期設定を一つもらしてうごかねーなぁーって時間が少しあったけど、さっさと動きました。 ふぃ〜 はまらなくてよかった。

 CSI通信デバッグの様子

あとは残りのRS485部分を作製すればペリフェラルボードいったん完成です。 早くシグマを不整地歩行させたい。

9月25日

一昨日の日誌を書いた後、更にがんばって残りのRS485部分のはんだ付け作業をやってました。 ですが終わらず、昨日も仕事から帰って配線作業をやりまして、やっと配線を終了させました。

配線チェックも一通りやって、さぁ通電試験。 6チャンネルあるRS485をひとつずつチェックしていったのだけど、1chから3chまでは問題なし。 この調子だと全てOKだなーと思ったところが 4chから6chは反応なし。 あれぇ〜?? 配線チェックを再度やっても問題見つからず。 通電チェックをやりだした時点で既に深夜だったので、すぐに思いつく問題、 ケーブル、電源ライン、はんだブリッジなどをチェックして怪しいはんだ付けを再度はんだし直したりしたのだが、ダメ。 次の日も仕事だしその晩は諦めていったん終了。

一夜明けて、送受信切り替え制御のラインのドライブ能力が問題か?とか考えてデータシートを確認したのだがまったく問題なし。

会社で「動作確率2分の1だよぉ〜」とか話してたら「電源チェックしましたか?」と基本的なこと言われて「まっさきにやったよ!」といったものの、アース端子と電源ピンで測ったなぁと、、電源ピンとグランドピンで測ってないということに気がついた。

こりゃ、4chから6chのグランドラインの根元がテンプラはんだで決まりだなぁと思って帰ってチェックしたら、3つのうち1つは電源ピンにはんだ不良を発見。(>_<) グランドラインは問題なし。 こりゃ他のチャンネルも、ICのはんだ付け不良っぽいってことで一見はんだ付けできていそうだけど怪しい端子を再はんだ付け。  昨日チェックしたときは配線側のはんだチェックしかしていなかったのだ。

そして先ほど6チャンネルのRS485ポート全ての動作を確認しました。(^_^;) 目視はんだ付けチェックは念入りに。 テスターでチェックする場合はピンの根元でチェックしましょう。 IMDで作ってた時は気にしたこと無かったんだけど、SMDだとこういう問題があるんですね。 気がつきませんでした。

   意外と配線量が多かった。

バッファチップが3つも乗ってるけど、二つで間に合いました。 まぁ、拡張すること考えたらそのうち使うこともあるでしょう。

これでSEMB用ペリフェラルボードの第一段階は完成。あとは加速度センサーと、それの読み取り用マイコンを搭載するつもりだけど、普通にシグマを動かすだけなら加速度センサーまでは要らないので後々搭載することにします。

このままSEMBのプログラムに突入したいところなのだが、ラムダの歩行が気になって仕方が無い。 あと少しで結構安定して歩けるようになる予感なのだ。受動関節はシグマの悪路歩行で取り込んで、可能であればラムダにも応用したいと考えているのでシグマが動き出してから、って感じかなー。

行動生成をやりたいのに思いつくアイテムは動作制御ばっかりです。(>_<)

9月28日

土曜日は二日酔いでぐだぐだであったのだが、なんとかラムダの歩行に修正を加える作業をやってました。 転倒回避歩行を実装するために足の姿勢を、つま先立ちやかかと立ちの定義をして、その状態からでも倒立振子歩行の歩容を生成できるように、ということを記述していたのだけど、受動関節を考えている今、その方法は適正ではないとか、かかとをスリップにした場合の影響とか、色々ありまして、その辺りのコードをすっぱり削除してしまいました。

で、つま先のグリップ面がつんのめらないように遊脚を前に出す時はかかとを上げ気味でもってくるという遊脚の動作を折り込んでみました。

結果は、、う〜〜〜ん。。。 あんまり効果ないかなー??

かかとスリップにしたままだと歩けないと書いていたんだけど、遷移時間0.3秒だとだめだけど、0.4秒だと歩けます。0.3秒でも歩ける方法があると思うのでかかとスリップでもう少し工夫してみましょう。

 

そして、この休みの本編は先日完成したSEMBのペリフェラルボードを使ってシグマを動かすこと。 RS485は動きだしたのだが、送受信切り替えをウェイトで待っていてはせっかくのハイパワーCPUがもったいない。 そこで、送信データ長からデータ送信時間を算出して、タイマー割り込みで送受信切り替えタイミングに割り込みをかけるということでウェイトしないで済むようにしようと思います。

そのタイマーなのだが、SEMBの割り込みは割り込みコントローラがあって、それが管理しているんだけど、イマイチ使い方がわからない。

マニュアル類と、ぐ〜たらパパ岡田さんのHPやHOSのソースから色々類推してみるがわからないこと満載です。数時間調べて行き詰ったところで岡田さんに教えてメールすることにしました。(^^ゞ

そして、そのまま昨日封切の「アイアンマン」をレイトショーで観に行ってきました。 助手のハンドロボットがイカすという噂だったのだけど、、、何の変哲も無い産業用ロボット的な風貌はナイスだったのだけど、プリティーさでは期待よりは下回るかな。 でも「不器用」って呼ばれてるのがなんかいいです。英語だとなんて言ってるんだろ?

 

そしてアイアンマンから帰ってから、3時過ぎまでマニュアルやらサンプルソースやらを眺めてはうなり、うなっては眺め。 段々と判ってきました。

でもさすがにトライするには時間が遅すぎる。コーディングやテストは日曜に持ち越しです。

 

朝になったら岡田さんからメールが届いてました。 メールによると昨日の勉強の結果はなかなか正解だったようで一安心。 早速タイマー割り込みを使ったサンプルプログラムを作ってみることにしました。

タイマーの操作や割り込みは早々に出来たので、目的のRS485受信切り替えに取り掛かります。 これがものすごく難航。 どう考えてもおかしな具合に陥ってしまい、もんもんとしましたが、割り込みを考慮したコーディングになっていなかったのが原因。 プログラムの記述手順を変えてうまく行きました。

 6チャンネルのRS485にシグマの6本の足がつながってます。

6チャンネルを並列に操作するってことで結構制限が多いのだけど、サーボにコマンドを送ってサーボから情報を吸い上げるところまできました。 ここまで来たらもう大丈夫でしょう。 コマンドを送ってサーボを動かすのはそれほど苦労しないはず。 もうすぐシグマが逆キネで動きます。 更には1ラインにサーボが3個しかついていない贅沢な構成なので、各関節の角度取得もほぼ同時に、うまくいけば3ms周期くらいで取得できるはず。 地面を探りながら歩くという制御をさせたいと思います。

そろそろSEMBをシグマに取り付けられるようにしなきゃな。

9月29日

ではでは、そろそろシグマのサーボに動作コマンドを送り込んでみましょう。 と思ったのですが、昨日までの状態でシグマがガシューンと動き出したらケーブルでぶら下がっているSEMBがどんな辛い目に会うかわかりません。 どっかとショートしてそのままお亡くなりになる可能性もある。

なので、今日はシグマへのSEMBの取り付けをしました。 アルミ部品を作るのは大変なので、プラ板で仮固定。 そして、長さの足りないケーブルをいい感じに延長します。

 こんな感じ

暫定的にファンも取り付けています。 ファン付きのヒートシンクを注文しているんだけど、入荷する気配がない。。 12Vのファンを取り付けているけど結構うるさいので抵抗入れて回転速度を落としてます。CPUが壊れることはないでしょう。 あと、レギュレータを変更した方がよさそう。リポだとうまく動きません。9Vに変換しているのだけど、低ドロップ型だから問題ないはずなんだけどな。 なーんかおかしいなー。

定電圧電源だとちゃんと動くので、早速動かしてみようかと思ったんだけど、もうこんな時間!(午前1時) 昨日までのSEMBとの戦いと、今日の仕事での頭脳労働でなんかとてつもなく眠い。 明日は飲み会で帰るのは遅くなりそうだし、シグマが動くのはもうちょっとかかることになりそう。(>_<)

このページの先頭へ