開発日誌(37)
■７月２日■
注文していたブツがやっと届きました。
KRS-6003HV
こいつをラムダの股関節ロール軸に適用します。 ブラケットとか取り付け穴とか4000番そのまま使えるのかと思ったら、ねじサイズとかホーンの取り付けねじ位置とかは違うですね。しっぱいするとこでした。
6003買うような人はきっとまとめ買いしちゃうだろうからもしかしたら需要ないかもなー。 もし需要がなければ股関節ピッチ軸にも投入しようかな。
■７月３日■
6003は届いたけど、ブラケットやネジがないのでラムダはおやすみ。
今日はビーグルボードで直接RS485サーボを動かす検討をしておりました。
今のシグマは、ビーグルボードは無線カメラ専用なのですが、ゆくゆくはコントロール信号も無線LANでやり取りするようにしたい。 すると、逆キネ計算とかはビーグルでやっちゃえば簡単だなと。 ビーグルボードにはADコンバータがないので結局マイコンのお世話になるところはなくならないんですが。。。 #BeagleBoardのGPIOやSPIをフル動員すればいいのだがデバドラとかよくわからんので。。。
LinuxからRS485を操作するにはRTSを使うそうです。 RTSはCTSとつないでハードフロー制御を行うもので、受信側が、「受信可能です」と意思表明する信号です。 今回の場合、「これから送信します。」という信号が欲しいので、「受信不可能です」＝「これから送信します」と読み取ってRTSを使うということです。
でも、シリアルポートは全二重回線になっているので、送信しながら受信することもできるので上述の条件が成り立たない。 ということで結局はマニュアルでRTSを操作することになります。送信する前にRTSを立てて、送信が終わったらRTSを降ろす。（本来のRTSのマーク・スペースの概念は無視です）
ここで問題なのは、リアルタイムOSではないLinuxでコレをやるとタイミング問題が出ることです。
Linuxの元祖となるUNIXは多くの人間が同時にコンピュータを使うことを想定してタイムシェアリングのシステムを構築してきているので、人間が困らない程度の時間感覚での精度で制御します。すると、場合によっては送信が完了していないのにRTSを降ろしてしまったり、いつまでもRTSが降りなくて通信が滞ったりする恐れがあります。
それよりも十分な速度でマイコンにデータを送り込み、マイコン側で正確な時間感覚でサーボコマンドを発行するようにした方がプログラムも簡単だし品質も上がるはず。
ビーグルボードからのシリアルはFT232RLを使ったUSBアダプタを使用。 ロジックレベルでRS232Cの制御信号全般もサポートされているし、RTSの論理反転なども設定できて便利。
上がTXD信号、下がRTS。 一応、マニュアルでRTSを制御してRS485通信ができる条件は整いました。
タイミング微調整するのがイヤなのでボツ。。。
■７月７日■
もう７日は２時間ほど過ぎていますが。。
ラムダの股関節ロール軸にKRS6003を投入しました。
結果は後日報告しますが、概ね良好。 質点情報を更新しないで、重心位置がずれた分だけZMPをずらしたりして動かしていた時は良かったのだけど、質点を調整したり、テンショナーを入れたりしていくと良くなったり悪くなったり、、 まだ色々と調整中です。
股関節ロールのトルクは完全に足りていなかったみたいで、4014で動かしていた時はぷらぷらしていた遊脚がしっかりしてきました。
関節角度を観察すると、テンショナーの効果は確かにあるようで、4軸あるピッチ軸のうち、膝に相当する2軸にはテンショナーを入れていますが、股関節と足首には入ってません。 この2軸が支持脚の時にぐらつくために上体の姿勢がぐらついているのが目立つようになってきました。 今度はここにも手を入れる必要があります。
ところで、ある程度は予想していましたが、6003のバルクにはまったく反応ありません。 やっぱ6003を使う人は1～2個だけ買ったり、数千円を惜しんだりしないのかなぁ。 ｼｮﾎﾞﾝ。。。 もうちょっとしたら店じまいしようかと思います。
■７月８日■
質点データを更新し、トリムを再調整し、ストレッチを変更しました。 実はいままでZMPを足裏中央より少し内側に設定していました。 その方が概ね安定していたからなのですが、それは股関節トルクの不足などからくるものだったようです。
股関節ロールを6003に変更した結果、ZMPを足裏中央にしないと、今度は足首ロールにしわ寄せが来てしまうことになって逆に不安定になりました。 ですのでZMPは足裏中心に変更です。 足首ロールにアシストを入れたらZMPの調整も可能になるでしょう。
それでは姿勢データです。
上から右足左右、右足上下、胴体姿勢です。
オーバーしていた支持脚時の左右方向はショート気味。 アシストが効きすぎてる？ 支持脚時の沈み込みも無しと言ってよいでしょう。姿勢の乱れはロール方向で１度ほどに小さくなりました。 次はピッチ方向の姿勢の乱れを抑える必要がありそうです。 股関節ピッチの6003化も含めて検討。
それより、SEMB1200Aをサーボにつなげる部分のレベルシフタがばしばし壊れてしまいました。 コレを機にいろんな不満点を改善したインターフェイスボードを作ろうと思います。
3歩進んで2歩後退ですが。
■７月１０日■
SEMB1200Aのインターフェイスボード（といっても、無線コントローラのレベル変換と、サーボのレベル変換が乗ってるだけだけど） 予想はしていたが、土曜日はまるまるかかってやっと無線コントローラのレベル変換部まで完成。 残すはサーボのレベル変換。 これは、SSOPのチップなのでユニバーサルボードに載せるのに苦労する。 今回、壊れたこともあって、交換しやすいようにピッチ変換基板をモジュール上にし、プルアップ抵抗までモジュールで配線する形にしました。 そしてそれをソケットで搭載するようにしたので交換部品も用意できる。 いざと言うときにモジュール交換で対応できれば良いかなと。
電源も、レース用ラジコンに使うようなぶっといケーブルを使っていたのだけど、扱いやすい太さに変えました。 配線もスマートになりました。
サーボコネクタも圧縮したので無線コントローラのコネクタを並べることができました。 いままで色々不満だったんだけど作り直す手間を理由にだましだまし使っていたのできれいになってキモチいい～です。
続けて股関節と足首のピッチ軸にテンショナーを入れる改造をしたいところだったけど、 作業はシグマの改良に。
前回のロボでサバゲで、動かすたびにカメラが止まってしまってゲームにほとんど参加できなかったのだけど、原因は電源容量の不足でした。 電動ガンの打ち始めは２Ａくらい流れることは小泉さんの報告でわかっていたので、事前にテストをしていく予定だったのだが、間に合わなくてテストしていませんでした。
現場ではモニターを外していたりして、ビーグルボードにリブートがかかっているのに気づかず。。。
で、電動ガンは打っているときにしか電流が流れないので、効率が悪いレギュレータでもいいでしょうということで電動ガン用のレギュレータを用意しました。 データシートによると３Ａ取れるらしい。 これで電動ガンを打ってもカメラが落ちることはなくなりました。
が、今度は電動ガンのトリガーの調子が悪い。 トリガーオフの状態でも、なんだかちょっとモーターが回っているようなきな臭いにおいがしてくるような。。。 どうもトリガーの制御信号が不安定なようです。 こないだはこんなことはなかったのに。
オシロで信号をモニターすると、BeagleBoardが動いていると信号にノイズが乗ります。 無線LANのノイズかな？ これは制御信号の方にノイズ除去のコンデンサを入れて解決しました。ノイズこわいなー。 ついでにレーザーサイトのON/OFF制御信号にもコンデンサいれときました。
IKETOMUさんがサバゲのMLで紹介された「パンツァーワォリアーズ」 これを見た田中さんがサバゲで考えている無線LANカメラも４台搭載にはならんかと。。 ううむ、、、４台はつらいだろうな。２台が限界っぽいけど。。
２眼カメラを動かすにはレゾリューションが大きなカメラだとダメです。ちょっとしょぼめ、でも早いってカメラが良い。 今のイチオシはLogicoolのC270なんだけど、こいつを２台積んで無線LANで動かしてみると、 メインカメラは320x240、 サブカメラは160x120ならばなんとかなりそう。 せめてもうひとつカメラがつながればメインを正面、サブを左右に配置すれば随分良くなるはず。 3台目ってデバイス認識するのかなぁ。
この週末はなんかたくさん作業して達成感あったような気がしているのだけど、よく考えると飛び込みの作業となったラムダのインターフェイスボードの作り直しのため、予定していた作業の半分もできなかった。 よく考えなきゃよかった。
■７月１２日■
ラムダの足首ピッチ軸と股関節ピッチ軸にテンションゴムを入れる改造をやっておりました。
足首ピッチ軸への改造が完了したので早速実験。
↓これがテンションゴムを入れる前
↓これが入れたあと
支持角度からの誤差の極性が反転してしまっていますが、誤差の抑制に対しては効果なし。 歩かせてみると、テンション入れたほうがちょっと硬質の足音がします。何かが変わってはいるようなのだけどこのデータを見る限りは目に見える効果はありません。 逆に、足上げ高さを低くしているのにも関わらず遊脚時には支持角度まで追随できていません。 ちょっと跳ねる傾向があるので、硬質の足音とあわせて考えると、胴体の姿勢の傾きのせいで遊脚の着地が路面をたたいているのでしょう。
テンションゴムによるがたつきの抑制は、手抜きの構造なので仕方ないのだけど、動作範囲の広い関節で、特に浅い角度で使う場合は効果どころか悪影響が出てしまいました。
股関節も一応改造して、あと少しでゴムが取り付けられるのだけど、ちょっと気持ちのテンションダウン。
寝なきゃ。
■７月１６日■
１３日夜。 ラムダの歩行実験を繰り返しておりました。 まだまだ姿勢のひずみはおさまりそうになくてそろそろ対処療法的な対策が必要になってきそうです。
たしか、歩幅100mm、ペース0.8秒くらいで歩かせていたところ、急に両足を寄せて股を閉めるような動作をとりました。 ま、簡単に言うとバグかなんかで暴走したみたいです。 今までには無い動作なので「え？え？え？」とうろたえた末に電源スイッチを切ろうとしたところ「パキッ！！」という破壊音。 まさか6003飛ばしちゃったか？と思ったのですがどうやらそうではないみたい。 股関節ヨー軸のサーボケースが割れた、、、んじゃないかな？と。
その後木曜日も金曜日も作業できなかったので、先ほどやっとラムダを修理。 やはりサーボケースが割れておりました。
いままでプラギヤを飛ばしたことがあるくらいで、FET燃やしたこともメタルギアを飛ばしたこともないので良く知らないんですが、ケースって良く壊れるんですかね？ モールドの厚みが異常に薄いからすぐ壊れてもよさげですが。
サーボが壊れたことよりも今までに無い動きをしたことが問題で、電源切っちゃったからもうなんの痕跡も残っていません。 障害解析のことを考えると、サーボへの電源供給だけを切断するスイッチをつけて、プログラムはバグ解析の手がかりになるようなログを残しておくようにしないといけないです。
■７月１７日■
ラムダの歩行は、股関節ロールの強化もきりが無いのでフロさんのアドバイス①（だったかどうかは忘れたが）の（※）、「遊脚を、支持脚の沈み込み分だけ着地の手前でとめる」というのを組み込んでみました。
手前でとめた分は、両足支持期間中に回復します。
効果は、うーん。。 いまいちわからんな。 ZMPを調整したりするといい具合になったりするんだけど、「手前でとめる」がなくてもよかったり。
実は、足踏みだと胴体の倒れこみが十分に小さくなってきたのだけど歩行だとそれほどでもない。 そのそれほどでもない原因がよくわかっていないので今回は「対策アイテムの作りこみ作業」という位置づけです。
パンツァーウォーリアーズのおかげで敷居の上がったロボでサバゲのカメラシステムですが、乗りかかった船ということもあり、BeagleBoardでトリプルカメラのテストです。
三つ目のカメラはもちろん実績があるC270です。もうちょっとだけ上位クラスがあるのですが、トリプルで要らないことになれば本当に要らないものになるし、C270より下のはあんまり興味ないのでやっぱり要らない。
で、結果はこんな感じ。 シグマに載せて動かせてないので実感ないですが、動きます。 ただ、センターのカメラがたまに落ちます。 リロードすれば復活するのでUSBが落ちてるわけじゃなさそうなのでまぁ、ロボでサバゲになら使えるかな。
面白いことに、5fps設定にするよりも15fps設定の方が安定します。
家だと比較的環境がユルイので本番で使えるかどうかの判断にはならないですけどねぇ。 そこが難しいところです。
※フロスティデザインさんのアドバイスは、着地衝撃を緩和するために着地時の速度を落とす目的で「着地前に一度止める」というものでした。「沈み込み分だけ手前でとめる」というのは私の誤解によるものです。訂正します。
次の日曜日にパンツァーウォリアーズにシグマを持っていくために鋭意プログラム修正中。
結構作りかけ状態で、サーボの状態管理なんかもやっていなかったのでコレを機会にその辺りの整備なぞしようかなと。 動作全体よりも管理プログラムって後回しになって、本番に発生するトラブルに対応できなかったりするんですよね。 今のシグマがその状態です。
実はサーボからの情報取得部分が作りかけのままだったのでそこを完成に持っていったりしてました。 そういえばシグマのサーボは601だから1Mbpsまで設定できるし、STM32のUARTなら1Mbpsくらいは設定できる。1Mbpsで、サーボ情報を細かに受け取るってのもいいかも。
ええと、今は460800bpsで20ms周期で角度コマンドを送っている。 6ms程度で送り終わるから、角度コマンド、情報要求、リターンパケットと考えても十分。
と、、、話がそれてしまった。 週末までにやらなきゃならないのはカメラ3個実装と、コントロールをアナログスティックから十字キーに直す部分。 アナログだとまっすぐ進めないんだよね。