なんかモチベーションが下がっています

なんだかモチベーションが下がっています。

言い訳をするのは好きではないのですが、盆明けから本業が忙しくてロボワン情報すらろくにチェックできていません。この間も座談会で長井の次は後楽園って初めて知ったし・・・（本当かどうかすらチェックできていません）

あと、モーション作成ってあんまり好きじゃないんだと思います。コツがつかめればいいんでしょうけど。でも実装すべきモーションってピックアップしてみたら最低20くらいはあるんですよね。つくづくロボット自作作るのって大変だしやっぱりキットって安いんだなあと思うこのごろです。

そういうわけで今月中に歩行ができるといった垣根の低そうな目標も達成できるかどうか怪しい雲行きです・・・・

軸配置を考慮したシミュレーション

軸配置を考慮したシミュレーションを行ってみました。足をそろえるときに状態が大きく動く結果になったのですがこれであっているのかな？と思いつつ実装してみたいと思います。軸配置が非直交軸、非同一リンク長であっても計算できることがわかりましたがやや面倒くさいです。

STK-7125とかVS-RC003とか

ロボコンマガジンNo.47を読んでいてVS-RC003にLPC2148が使われていることも知りました。それによりますと

★IXBUS拡張基板が接続可能です。拡張基板のラインナップとして、ジャイロ/加速度センサ基板、LED基板、アナログ入力基板、デジタル入出力基板などの販売を予定しています

とのこと。ということはEZ-SERVO（mini EZ-ARM7）でもこれらの拡張基板が使えるということなのでしょうか。なんか得した気分ですが、詳細はまだ調べていないので取らぬ狸の皮算用かもしれません。おそらくI2Cの拡張規格だと思われます。

この間までARMなんて全然使われていないなあと思っていたくせに、時代はLPC21xxを使ったARM7か？とか思ってみたり。D/Aを使って音声再生とかも今後やってみてもいいなあ。とりあえずは内蔵ROMに埋め込める分だけで。この調子でいくと通常の歩行制御やモーション再生のプログラムだけではROMは絶対に使い切らないと思われます。

いしかわきょーすけさんのページで紹介されていたアルファプロジェクトのSH/TinyボードSTK-7125もとっても気になりますがここはぐっと我慢します。

プラリペア

プラリペアっていうなんかよさげなもの見つけたんですがどなたか使われたことがあるかたいますか？あんまり高くないので買ってみようかなあ。材料よりもデザイン決めなきゃいけないんですけどね・・・

（8/22　23:27　追記）
あんまり高くないと思ったのは「型取くん」の方で「プラリペア」は結構いい値段しますね。

歩行モーションの問題点（その2）

歩行モーションにとりかかっているのですが、計算はあっているはずなのに足が全然上がりません。パラメータを相当大きくするとあがりますがなんかとても気持ちが悪いです。モーションを各ポーズごとにとめてみてみても足があまりあがっていません。

よくよく考えてみると今の軸構成を考慮したモーションになっていなかったのが原因ではないかということに思い当たりました。

今のロボットはホームポジションでまっすぐ立っているように見えますが実は膝が足と足首に対して奥まっています。これを何も考えずに前に踏み出そうとすると図のように床に対して押し付けるように動いてしまうのです。だめやん・・・（泣）。しかも足-膝間の軸間（73mm）と膝-足首間の軸間（82mm）一緒じゃないし・・・。一緒だと思っていました・・・今頃気がつくなよって感じです。

 

というわけで軸構成をちゃんと反映したモデルでシミュレーションしないといけないようです。直行軸や軸構成が計算歩行に重要な意味を持っていることを身をもって思い知らされています。

デカルトの密室

かみさんの実家に帰っている間に瀬名秀明さんのデカルトの密室を読みました。（楽天アフェリエイトのリンクになっています。）

ずいぶん前からもってはいたのですがようやく読むことができました。私的には面白かったのですが一般の人はかなり読むのに苦労しただろうなあっていうくらいに専門用語が連発されていて、ロボットやAIや哲学や心理学がよっぽど好きでないと専門用語に圧倒されて読みきるのが大変だと思います。

幸い私はAI以外は興味があったので内容的には非常に面白く読むことができました。ホビーロボットをやっている人よりも研究や仕事でロボットをやっている人が読むべきものなのかもしれません。たくさんのテーマがこの本の中で流れていると思いますが、今のロボット研究のいろんな考えを瀬名秀明さんなりに物語にしてみたといった感じでした。

私が生きている間にはこんなことにはならないだろうと思いますが、ケンイチくんみたいなロボットが研究段階でも出てきたら面白そうですね。

OptimizeでEZ-SERVOのキットが購入できるようになっているようです

OptimizeにてEZ-SERVOのキットの購入ができるようになっています。とりあえず予備がほしかったので１個ポチッとな。mini EZ-USBもついでにもう1個買いました。

EZ-SERVOにフラッシュを書き込むとPWMのレジスタが中途半端な値になるときがあるのか書き込み途中でロボットの姿勢がちょっとヤバイ状態になることがあります。書き込み時間が短い間はまだいいのですがソフトの容量が増えるにつれ書き込み時間も延びるのでだんだん見逃せなくなってきました。この辺はjtag_flash.exe経由でPWMが暴走しないようにレジスタ設定を事前にして欲しいところです。現状では足だけはサーボの電源を切ることで対処していますがあまり使い勝手はよくありません。

CPUやCPLDの電源とサーボの電源を分離してサーボの電源のみOFFするように改造するのが現状ではよいのですがどうしたものか・・・。それとも何か使い方を間違っているのでしょうか・・・？この辺は人柱になっているだけに厳しいところですね。

ホームページを3ヶ月ぶりに更新しました

ホームページを3ヶ月ぶりに更新しました。この3ヶ月の内容で役に立ちそうなものをピックアップしてまとめました。解説とかできるほどのことはあまりしていないので取り上げられるようなものはあまりありませんでした。

とりあえず復活

モータ交換をして動作確認をして組み立ててとりあえず復活しました。

ばらして再組み立てというのはあまり気乗りしない作業ですが、いいこともひとつありました。実は問題の左足のP軸の可動範囲が右足に比べて後ろ側に振れにくくなっていました。これもモータが逝ってしまった理由のひとつなのかもしれません。

しかし歩けない一番の原因はモーションルーチンが正しく作れていなかったことだろうと思います。今日になって冷静に考えてみて以前にシミュレーションした計算が全然反映できていなかったことに気がつきました。というわけで歩行ルーチンを全面改装中です。

モータを壊したみたいです・・・

歩行モーションを確認している途中でやけに熱をもったサーボがあったのでこれはヤバイと思って少し間をあけたつもりだったのですが、既に逝ってしまっていたようです。というわけで歩行モーションは完成しませんでした。

壊したのは左足のP軸です。分解して確認したところモータのピニオンが全く回らなくなっていました。モータも分解してみましたが見た目にはあまりおかしなところはありませんでした。しかし、焼きついてしまったのかロータが全然回りません。

サーボケースを良く見ると熱で変形しています。新しいモータをいれたところピニオンの周りも熱で変形してしまっていて回転しなくなっていました。なんとかルータで削って事なきを得ましたが、これでサーボケースもおかしくなっていたら完全に心が折れてしまうところでした。

それにしてもFETを焼いたとか、ギアがかけたとかはよく聞きますがモータが焼きつくとは・・・サーボケースも変形しちゃうし。歩けるまでに機体が持つかどうか心配になってきました。とりあえずモータを交換して組み付けてギアが動くことを確認したのでもう今日は終わりにします。

私の一足早い短い夏休みは悲しい結末となってしまいました。目標を大幅に引き下げて今月中に歩けるようになることを目指します。

まだ歩けていません

3時くらいに外出から戻って歩行モーションに取り組んでいますが、まだ歩けていません。体重移動とかはしっかりできるようになったのでブラケットの再々作成はしなくてもよさそうです。歩くのってやっぱりむずかしいですね。重心の位置まで計算したらもう少し違うのかもしれません。重心の位置をうまく調節してあげることが重要なポイントなんだということがわかってきました。

暗くなる前に歩かせたいです。

足踏みモーション

歩行の基礎となるであろう足踏みができるようになりました。

モーション再生後状態がゆらゆらゆれて発振気味になることがあり歩行で苦労するかもしれません。最初、体重移動と足上げを同時に開始していたのですがうまくいきませんでした。やはり体重移動->足上げとちゃんと時間を区切ることが大切であると思いました。

「ashibumi.wmv」をダウンロード

もうお昼か・・。歩けるかな？タッパーの上はやめて机の上を歩くようにしようと思います。（最初からそうしろよって感じですが）。

外の空気でも吸ってこよう。

屈伸モーション

まずはお決まりの屈伸から。ホームポジションも微妙に修正しました。内部でかがみモーション->ホームポジションへの復帰ということをしています。計算によるモーション作成をしています。左足が早くかがんで右足が遅くかがんでいるように見えるのはひょっとしてデマルチプレクスしてPWMを分配しているのが原因なのでしょうか？もう少しいろいろ作って確認したいと思います。

「kusshin.wmv」をダウンロード

RoboshellのPWM幅

Roboshellをそのまま使ってPWMを出力すると私が使っているミニスタジオのサーボRB995では最大幅振ることができません。そこで現状がどうなっているかを確認し、RB995の最大幅が設定できるように修正をしました。現状の設定ではKONDOのサーボに合わせてあるようです。

具体的にはPWM_SDC.hの下記の値をRB995に合うように修正しました。

#define PWM_BASE_TIME 4827 　// 4400d(2320us)->4827d(2500us)
#define PWM_HOME_TIME 2750 //1.5msec
#define PWM_MIN_TIME 927 　　// 1020d(550us)->927d(500us)

実際に最大値、最小値を設定してみてPWMの波形が500us-2500usまで設定できるようになったことをオシロで確認しました。

これで膝のP軸が最大幅近くに設定したくてもできなかったのができるようになるはずです。サーボ角度の設定などを支援するRDC.exeは幸いにもminimam値、maximam値を超えた値でもちゃんと設定してくれるので助かります。

次はホームポジションが少し前かがみになっていたのを修正します。

修正版ブラケット完成

5時半起床で接着したブラケットと足平を取り付けて本体にも取り付けました。やっぱりギリギリを攻めてしまっているのでお昼くらいにまた再修正版ブラケットを作ってたりして・・・。

ホームポジションです。前回サーボの回転中心から23mmだった隙間を30mmにしました。

内側最大。90度曲がるようになりました。

外側最大。30度くらい？一応理屈としては足の付け根も30mmの隙間なので同じ角度で曲げる限りは足のブラケットも直さないといけないからという理屈です。そうなってしまったらちょっときびしいですね。

朝ごはん食べよう。

修正版足首ブラケット（接着）

足首を分解して、切り出したABSをアクリサンデーで接着しました。これで一晩おきます。もうちょっとがんばるつもりだったのですが眠くなってきました。どっちにしても待たなくてはならないので仮眠をとります。

修正版足首ブラケット（切り出し完了）

切り出して、穴あけして、仕上げ加工して、ヤスリがけしてとりあえず切り出し完了。次は組み付けて接着です。いつもならここまでに2日か3日かかります。まだまだ今日はがんばれます。50クロックくらいは進みたい。でもその前におなかがすいたので夜食タイム。

修正版足首ブラケット（加工前）

足首があたってしまって可動範囲を確保できないのでまずはブラケットを作り直します。

ロボット三昧！

J-classやROBO－ONE Specialが終わって参加された方も観戦された方も一息つかれているところかとは思いますが、私は今日明日と燃えに燃えています。

なぜかといいますとかみさんと子供たちが一足早くかみさんの実家に帰っているため私ひとりで家に残っているからです。そして明日は有給をとっているのです。ということは！この１年くらいで初めて１日中ロボットができる日がやってきました。うれし～い！森永さんのようにはいきませんが怒涛の勢いでロボット作りをしてロボットを歩かせてやります。歩かせますとも！

がんばるぞ～。

歩行モーションの問題点（その１）

動かしてみて初めてわかることってよくありますよね。ようやくそういう問題がわかるレベルになったことは喜ばしいのですが、　1つ問題がわかってしまいました。それは足首の可動範囲が十分ではないということです。これでは体重移動ができません。モーション作成開始早々で足首のブラケットを作り直さないといけないことになってしまいました（泣）。

Omniの前田さんみたいにR軸はP軸よりも上にある方がよいのだろうか？とか思ってみたり。すねのフレームも作り直さないといけないからちょっと手間になるなあ。でも、私はJ-classやスペシャルやロボファイト4に出るわけではないのでマイペースでやりたいと思います。

ホームポジションです。

内側最大。内側にはまあまあ曲がります。でも右と左でこんなに違うのはいけませんね。

外側最大。って全然あかんやん！ギリギリ攻めすぎてサーボブロックの外装で大きくなったのがあたっているようです。余裕は何事にも大切ということですね。

math.hを使うには（解決）

math.hの件ですが、解決しました。なんともありがちなスタックのオーバーフローが原因だったようです。結局、自前でsqrt,atanなどの関数を用意してデバッグをはじめていたのですが、挙動がおかしいのです。グローバル変数が動かしているうちにどんどん破壊されていきます。グローバル変数をどのファイルにおくかといった配置によって同じ変数でも破壊されたりされなかったりします。グローバル変数でvolatileをつけていない部分もありvolatileを片っ端からつけていきましたがやはりグローバルデータが一部破壊されていきます。これがスタックがオーバーフローしている可能性が高いと思った理由です。

具体的にはどうしたかというとC:\EZ-ARM\_commonにあるlpc2138.ldというファイルの

/* Memory Definitions */

MEMORY
{
  CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x00080000
  DATA (rw) : ORIGIN = 0x40003000, LENGTH = 0x00001000
}

を

/* Memory Definitions */

MEMORY
{
  CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x00080000
  DATA (rw) : ORIGIN = 0x40005000, LENGTH = 0x00001000
}

のようにしました。

LPC2138のRAM領域は0x40000000から始まっていますので0x3000（12kB)をスタックに割り当てていたことになっていたと思うのですが、これを0x5000(20kB)にまで増やしました。解釈は間違っているのかもしれませんが、とにかくこれでグローバルデータの破壊の問題もmath.hにある関数を使うとまともなバイナリができない問題も解決しました。スタックってこんなに積みあがるのかなあ？といった疑問もありますが結果として動作するようになったのでたぶんそういうことなんでしょう。贅沢ですねRAMが32kBもあるって。SISOさんやshin1さんをはじめH8/Tinyで計算歩行をしている方々はかなり苦労されているのではないかと推測します。

アドバイスをくれた森　秀樹さん、ぐ～たらパパ・おかださん、ありがとうございました。森さんからアドバイスをいただいたsoft-floatのオプション設定もやってみましたが挙動は変わりませんでした。LPC2138にFPUはありませんがデフォルトではFPUを使う命令は出力されないようです。

とりあえずこれで計算モーションが動きはじめました。でも、まだ考え違いがあるようで足の振り上げ方がおかしいです。でも俄然やる気になってきました。

math.hを使うには(未解決）

今まで私はgccをあまり使ったことはありません。math.hなどのシステムライブラリもあまり使ったことがありません。H8/TinyやR8CではROMやRAMがあまりないのでそもそもライブラリを使うということが選択肢に入りませんでしたし、画像処理や計算歩行などはやっていなかったのでmath.hにあるような関数自体も必要ではありませんでした。しかし今回はAMR7TDMIをコアに持つ大容量高速なLPC2138を使用しているわけですからこれを使わない手はありません。

今回math.hを使うにはどうしたらよいかを調べたのでメモしておきたいと思います。とはいってもまだ正常に動作していませんが・・・。

まずgccでmath.hに含まれる関数を使用するにはnewlibと呼ばれるライブラリをインストールしておく必要があるらしいのですがこれはTeamKNOxさんのところに書いてある手順でGCCをインストールすると既にインストールされているようです。OptimaizeさんのHPで紹介されているCygwinベースのGCCでも勝手にインストールしてくれるようです。

次にmath.hを使用したファイルに#include <math.h>を追加してmath.hのライブラリであるlibm.aをリンクするオプション-lmをmakefileに追加するのですが問題なのは追加するその場所です。TeamKNOxさんのmakefileを見るとLIBSという記述が見受けられますので単純にここに入れればよいのかと思われましたがundefined reference to `sqrt'のような感じでエラーとなってしまいます。

$(CC) $(CFLAGS) $(LDFLAGS) $(LIBS) $(OBJ) 　-o $@

となっている部分を

$(CC) $(CFLAGS) $(LDFLAGS)  $(OBJ) $(LIBS)　-o $@

と$(OBJ) と$(LIBS)の位置を入れ替えてあげることでエラーを回避できるようになりました。よくわかりませんが-lmはとにかく後ろの方につかないといけないようです。

これでコンパイルはエラーなしに通るようになりましたが、できたバイナリが正常に動作しません（泣）。libm.aが正常にリンクされていないのではないかと思いましたが、C:\GNUARM\arm-elf\libの中のlibm.aをリネームしてみるとエラーがでるので違うようです。

うーん、仕方がないので自前で必要な関数を用意することにしますか。まず確認でってやるとつまづいてばかりでちょっと悲しくなります。

ハンドをつけました

起き上がりのモーションなどでハンドがあるとないでモーションが変わると思うのでハンドをつけました。いろいろ迷いましたがドラえもんみたいにまんまるの手にしました。とりあえずバルサを削ったまんまなのですがバキュームフォームで上からプラスチックをかぶせることで強度強化をしたいと思います。

肩・腕・胴体・腰のカバーはこうしようというのがあるのですが、あとは頭ですねえ。ずっと考えていますがやはりいいアイデアが浮かびません。

計算歩行モーションを実行できるようにデバッグ

私が今使用しているRoboShellではパラパラ漫画方式のモーション再生を支援してくれる仕組みは入っているのですが、計算歩行などを使ったオリジナルモーションを実行できる仕組みはありません。まずは簡単にこのパラパラ漫画方式のテーブルを書き換えるやり方で計算歩行をさせようと考えて実装してみたのですが、どっぷりはまってしまって実行するとリセットがかかったり暴走したりするバグに悩まされていました。

コンパイルするたびに挙動が変わり2週間近くぼちぼちと調査をいていたのですが、先日ようやくその対処ができてオリジナルモーションを作成するメドが立ってきました。

とりあえず作ったのは現状を維持するために今のPWMの値を読み出してそのまま設定するといったものだったのですが、これがいけなかったようです。つまりモーション実行をしてもなんにも動作しないはずだったのですがこうすることによって暴走が引き起こされていました。

PWM_Value()という関数で現状のPWM値を読み出すのですが PWMの割り込みルーチンであるPWM_SDC_ISR()でも同じ変数を同じ関数で参照しており、割り込みが発生していたときに割り込み関数内で割り込み前にアクセスしていた変数（もしくは関数）にアクセスすると正しく割り込みが処理されないのではないかと推測しています。割り込み後に正常に割り込み前の状態に戻れないために暴走していたのではないかというわけです。とにかく割り込みで使用する変数には同じ値が入っている専用の変数を用意しお互いが別々の関数および変数を参照するようにすると暴走は発生しなくりました。

JTAGデバッガを使っても暴走していたのですが、JTAGデバッグで根気良くソースを追いかけていき暴走直前の位置がわかり解決に至りました。これ以外にも機能を大きく削減してみたり、ポートをON・OFFさせるルーチンを随所にいれてオシロで観測しながら怪しいところをしぼりこんでいってこの変数がどうも問題らしいということを突き止めました。それにしてもかなり時間がかかってしまいました。

仕事であればどうにか調べて裏を取るところなのですが現状ではモーション再生を優先して後で調べたいと思います。TamKNOxさんならわかるかもしれませんね。これが動かないことには計算歩行ができなかったので、出鼻をくじかれた感じですがなんとかモーション作りに入っていけそうです。