開発日誌みたいなの(13)

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

最新へ↓

11月23日

HPビルダーでの編集が異様に重いので新ページに。前のページは字が少ないが画像が多い。画像が多い方がHTMLファイルは複雑になるのか?

今日は秋葉原へ買出しに。主な目的はバッテリー搭載に関する部品の購入。例の極小MBも見てみたいなとあわよくば買ってしまうかも、という気分で行って来ました。

 リポ二つと充電器。バランサーはどうしよかなと迷ったけど今回は買わず。たっかいなぁ〜。

バッテリーはイガアさんにジャンクで組み立てれば安く上がるよと教えてもらったのだが、リポは使ったことがないのでまずは純正品から。みんなが使ってるサンダーパワーをロボット王国で購入。これもどっか安く買えるところがあるんだろうなぁ。

バランサーは買っちまおうかと思ったが今回は見送り。急速充電をしないのであれば必須ではないと理解して見送ったのだが、バッテリーの寿命を延ばしたかったら使った方がいいんだろうなぁ。

 高効率コネクタ。極性がわからないからネットで調べてみたらやはりエアガンワールドに突入。

うっかりコネクタを買い忘れるところだった。高効率コネクタを購入。これ、固くって抜き差しが大変である上にハウジングが小さい。抜き差しやりにくそう。うっかりとすきまにマイナスドライバーを差し込んでぐりぐりやりたくなるが、ショートしたらえらいことになる。ストレインリリーフが欲しかったな。小さいのと大きいのがあったが小さいのが不安なサイズだったので大きいのを選択。 メスは4個パック、オスは2個パックだった。メスはバッテリー用で、バッテリー2個と安定化電源用で3個必要。オスはロボット側を2重化対応にして2個あればOKと思ったのだが、充電器用にあと一つ必要だった。。。 2重化はすぐにできないからしばらくは事足りるってことで。(>_<)

 ←使うか使わないか判らない部品郡   ←本命

FETスイッチを作るための部品をチョイス。安いのでいろんなサイズのいろんなFETを適当に買ってきた。右上のが本命のPチャンネルFET。右の画像がその拡大。2SJ607-Z 83A 0.011Ω そんなに容量要らないはずだが、電流容量を小さくしてもサイズは変わらないのでできるだけ電流容量が大きくて低抵抗なものを選んでみた。 同容量のNチャンネルFETも一応買っておいた。

 RS302CDの補修部品

RS302CD用の穴明きサーボホーンが欲しかったが、売ってない。代替できそうなホーンもなかった。代わりに302のプラギヤセットは500円なので念のため1セットだけ買っておいた。一生使わない予定。

リポのパッケージに「説明書をすべて理解した上に開封しろ。」って書いてるけど、開封しなきゃ読めないやん。読めるところだけ読みましたがまさか折りたたんだところにもっと重要なコト書いてたりしないよね。(^_^;)

あと、話題の(話題としては古いけど)極小MB見ました! 小さい! 寸法では判っていたが、目にすると感動するくらい小さい。買ってしまいたかったが、買っても触る時間がないのでやはり見送り。でも帰ってからも買っとけばよかったかなーとイジイジしてます。 インテルバイナリーが動くMBとしては最小最安価の地位はしばらく揺るがないとの友人の見解から買っても後悔し無さそうではある。ただし、需要が大きいとも思えないので市場から姿を消す恐れも無きにしもあらず。 RPU-100とは縁を切りたくもあり、Linux環境に切り替える手間を惜しみたくもあり、まったく悩ましい。

11月24日

簡単なところからってことで、バッテリーの搭載から着手。バッテリーを買ってきたのでとうとうまじめにバッテリーの固定方法を考えねばならない。

バッテリーはしっかり固定しなければならないし、簡単に交換できなければならない。サイズが変わるかもしれないからその辺りも考慮して、でももうこれ以上重くできないから部品は最小で。 、、 と注文ばっかり多くて余り面白くない検討なので随分悩んで悩んで、何とか諦めもついて形がきまったのがもう3時。これから工作すると寒くて死んでしまうかもしれないので工作は明日やることにする。

 バッテリーはお腹部分に。

バッテリーを載せた検討図。1〜2ミリの隙間があるが、クッションをはさむスペース。バッテリーのサイズが変わった時にもクッション厚を変えて対応するつもり。

固定部分拡大。凝った作りにしたかったのだが、重量を増やしたくないので結局ネジ止め。ネジはつまみネジを使って工具レスで作業ができるように。

メネジ部はナットプレートにしてそこだけは真鍮で作る。ネジが壊れたらナットプレートだけ交換できるようにした。

股下部分のスペースにFETスイッチを収容したいのだが、うまく入るかな。

この状態だと左右の固定が無い。サンダーパワーの2100mAは長さが違うため、それにも対応したかったため左右固定はバッテリー個別のキャディを作る。キャディはプラ板で適当に作るつもりで検討してない。(^_^;)

 ついでにリアガードの検討もしてみたが、どうもしっくり行かない。これはボツかなぁ、、

 60Wのはんだゴテ、1290円也。画像を載せるほどのものではないが。。

バッテリーのコネクタははんだ付けで取り付けるタイプ。 大容量のコネクタのはんだ付けはパワーが要るのでいつも苦労する。 今回はバッテリーのはんだ付けもしなければならないのでもたもた作業できない。ささっとはんだ付けが完了するように大容量のはんだゴテを買ってきた。100Wくらいのが欲しかったのだが、近くのホームセンターで売っていた最大容量は60W。これでガマン。

というか、これで十分だった。無事はんだ付け完了。ラムダの電源ケーブルも昨日買ってきた高効率コネクターに交換した。最終的にはFETスイッチにする予定なのだが、FETスイッチ回路ともこのコネクターでつなげばいいかな。

バッテリーのコネクタ取り付けはちょっと緊張。なんせ、リポの説明書には、あれやったら爆発、これやったら爆発って書いてあって萎える。恐ろしいものを買ってしまったものだ。(>_<)

11月25日

 ←普段より足を背伸び気味で撮影。ちょいスタイルが良くなった。扉画像これに差し替えようかな。

バッテリー搭載完了! まだ充電していないので画像はバッテリーを積んだ状態で立たせたところ。この重量なら問題なくいままで通り歩けるらしい。ってもともと大して安定していないのだが。 頭が出来て、バッテリーも乗せたので重心計算データを更新せねば。しなくてもあんまり変わらないんだよなー。

頭部ユニットのサーボリンクも双葉さんにもらったCADデータを使って全部作り直した。 さすが設計データだけあって、ネジ穴はピシャリと合いました、気持ちイィ〜(^・^)

キュリオが「ヨォ」ってやってるところのポーズが取りたかったのだが、手首の自由度が足りなかった。ガッツポーズみたいになってしまった。

ラムダに使っているRS601CRもRPU-100も、電源電圧は9.6V。 12Vまでは大丈夫ですよ、と言われていたのでリポ3セルで11.1VならOKだなと思っていたのだが、リポの満充電電圧って4.2×3=12.6V 多分問題はないだろうが、、、、 トルクも増えるが電流も増える。 低電圧電源で歩かせてみたところ、メーター読みで4〜6Aくらい、立っているだけで2A弱ほど流れているみたい。するとぉ〜、歩き続けて15分。 立っているだけだと40分くらい。実力ではその2割減といったところか。バッテリー1本でロボビリヤード終わらせられるかなぁ〜。


しかし、工作はほぼ今日一日かかってしまった。他のことも進めるつもりだったのにな。

■ その場旋回
□ 歩行セット化
□ こけた時の受け身
□ 立ち上がり
□ トラッキング歩行
□ 色いろいろ認識テーブル作成か、複色物体把握
□ 紙コップを持ち上げるとかはらうとかけるとか
□ どのコップがどこにあるか大体把握する頭脳
□ 適度なタイミングでまばたき
■ バッテリー搭載
□ 障害物回避(またはルート生成)

11月25日−2

バッテリー搭載できたのでバッテリーでどれくらい動き続けられるかを確認してたのだけど、、、 バッテリーが無くなる前に膝のサーボが温度アラームでダウン(>_<)。膝サーボだけがアツアツになってました。電圧を上げたから発熱が増えたのか? 普段だと、プログラム修正中はトルクオフで寝かせて待機させてたもんなぁ、ずっと膝曲げ状態で立たせてたのって初めてかも。ヒートシンクつけなきゃな。 バッテリー1本でロボビリヤードできるか?とかいう問題じゃなくなっちゃうな。(^_^;)

リポは過放電は厳禁らしいから電源管理が必須。 FETスイッチができたら、プログラムからシャットダウンすることができるようになるんだけど、それまでは電圧監視はマニュアルになる。とりあえずは電圧低下警告を発声させるようにしなきゃなぁと思って、試しにサーボプログラムと画像処理プログラムを動かしながら音声合成をさせてみたら、、、 案の定ブツ切れでダメダメ。 試しに人形つかいさんに教えてもらった nice コマンドを使ってみたら、ほぼ正常に発声できました。逆に言うと発声中はサーボの動作は不全になる可能性があるってことか。 音声認識にも同じことが言えるわけだ。 プロセス管理についてもっと勉強しないといかんな。

  

冬場は赤系でのトラッキング調整には向いて無いな。

11月26日

昨日はその後、冷や汗モノだった。バッテリーの持続時間を測りたくて電圧を監視しながらラムダを立たせたり歩かせたりしたのだが、ふと気がつくとボーダーの10Vを下回ってる。そうなるとあれよあれよと思う間に電圧下がっていくんですね。一旦は7V代にまで電圧が下がってしまってやばーい! 急いでバッテリーを切断しました。

それからバッテリーが冷えるのを待って充電をしてみたところ、充電を開始せず、チャージャーはエラーアラームを出すばかり。バッテリーを測ると10V以上には復活している。(もちろん電流がほとんど流れていない状態で、だけど) あららぁ、もしかしてこれでバッテリーはおシャカなのか??? とブルーになっていた。

でも、何度もエラーを出しながらもチャージャーにつないでいるとバッテリーの電圧はちょっとずつ戻ってきているようだし、説明書にはエラーアラームは充電器のエラーか、接続ミスだと書いてある。おかしいな???

おかしいと思いつつも何度も充電しなおしていたら何度目かでとうとう充電を開始、低電流モードになりました。ほぉぉぉぉ〜、 その後1時間ほどで正常に充電完了。

結局何がどうなったのかわからなかったけど、またチョンボったのかと思った。 恐るべしリポ(なのかどうかわからんが) 

・・・・・・・・・

歩行のセット化が完了。 ラムダは後退が苦手で、こけないまでも後ろへ進まない。遷移時間や足上げ寸法を調整すればなんとか後ろへも歩けるのだがこのパラメータが前進の時と異なってしまう。 そういった固有のパラメータをセット化して動作に応じて姿勢も含めて適用する。倒立線形振子で計算しているけど、結局は設定したパラメータでしか歩けないってことなのでしょぼいのだが、まぁまずは仕方ない。 今日の状況ではラムダ側のプログラムが出来ただけでコントローラ側のプログラムが出来てない。というわけでリモコンでさえ動かないけど。だが、これで概ねは自律で歩かせる準備はできた。

次は転倒時の受身と起き上がりの実装。

起き上がりについてはいざとなったらモーション再生でやるとして、今日現在は姿勢値対応での起き上がりを実装したいと思っている。受身については絶対必須の機能ではないのだけど、頭ユニットが衝撃に弱いのでラムダとしては必須の機能と思っている。今日、歩行のセット化で動かしてみたら画像処理をしていると歩行が不安定。何度かこけたが首のヒューズは飛ばなかった。もちろんサーボのギアも。ほっ。

転倒回避について、春から間欠的に半年くらい検討してきたが、今回の「自律でロボビリヤードプロジェクト」では転倒判定だけを実装しようと思っています。

というのも、理想的には転倒を判定した時点の姿勢を取得したいのだけど、今のラムダのセンサーでは難しいというのが半年間での結論。センサーの整備にはもう少し時間がかかるので、まずは転倒に対する受身動作だけでも実装しようという考えです。

転倒回避歩行のときは、止まっている状態で外力がかかった状況を想定していたのだが、今回は不安定な歩行に対してこける事を前提に、受身動作をさせる。 よって、転倒を検知するのは歩行中を含むことになる。

受身動作をさせるのが転倒判定の目的なので、転倒してから、または受身が間に合わない状態での判定は無意味なのだ。

簡単なところではZ軸方向の加速度センサーで傾きを検知し、Y軸方向の加速度センサーで傾き方向を決定。例えば45度くらいの傾きを閾値としたならばこれでも判定できるのではないかと考えている。 その閾値で受身動作が実行できるかが問題。 ・・・・多分間に合わない。

他にはジャイロデータが使えそうだが、これは直読みでは使えないので一定期間の積分、または時系列データを分析しなければならない。もしかしたら現状の姿勢に関係なく、角速度の大きさだけで転倒を判定してもいいという解もあるかもしれないなと思ったりしている。

ふぅ、、、今日も予定していた作業の半分もできなかった。(>_<)

■ その場旋回
■ 歩行セット化
□ こけた時の受け身
□ 立ち上がり
□ トラッキング歩行
□ 色いろいろ認識テーブル作成か、複色物体把握
□ 紙コップを持ち上げるとかはらうとかけるとか
□ どのコップがどこにあるか大体把握する頭脳
□ 適度なタイミングでまばたき
■ バッテリー搭載
□ 障害物回避(またはルート生成)
○ 膝サーボの放熱処理
○ 頭ユニットの取り付け構造変更(メンテ性向上)

※「○」は問題発生により課題となった項目

11月27日

やっとコントローラ側のプログラムが出来た。

一応はリモコンで歩かせることが出来るようになった。CDTのトラッキングを同時に動かして、視線に合わせて操縦すると、結構風情があって面白かったり。(^_^;) 早く自律で動かしたいなぁと切に思う次第です。

バッテリーで動かすようになって、トルクが違っているせいか、動きがガツガツしている。(あ、あと画像取得を同時にするようになったのも影響しているかもしれないな)

もともと倒立振子での動作ははじめと終わりが最高速度なのでガツガツしているのではあるが、こう、、なんていうか無駄に力強い。 足首のダンパーの具合も変わっているだろうからトルク値を少し落とした方がよさそうな気配だ。

テストでバッテリーで動かしていたら、今日は両膝がくだけました。(熱でサーボがダウン) こりゃ、週末はまた工作だな。

さて、歩行のセット化は完成したので(昨日完成したことになっているが、)今日の次の課題は転倒判定のための実験。 でも、もうすぐ1時だし、ロボットこかせる音を響かせるとまずいだろうな。

受け身動作はトルクと姿勢を一気に指示して実現しようとしている。モーション作成じゃなくてモーションのハードコーディングにしてしまおうと思っている。そのモーション作りはイガアさんの話を応用して作ってみようとしている。 問題は発動条件の転倒検出。これにかかっているのだがぁ〜。

・・・・・・・・・・・・・

石川さん主催の忘年会、行きたいなぁと思っていたのだが、結婚おめでとう会が一緒になって、ありゃぁ行けないなぁと・・・、でもやっぱり行っとくことにしました。こないだは知り合いのライブに行って知らない人の誕生日を祝ったし、(^_^;) 知らない人の結婚も大いに祝おう(^^ゞ

■ その場旋回
■ 歩行セット化
□ こけた時の受け身
  □ 転倒検出
  □ 受け身モーション
□ 立ち上がり
□ トラッキング歩行
□ 色いろいろ認識テーブル作成か、複色物体把握
□ 紙コップを持ち上げるとかはらうとかけるとか
□ どのコップがどこにあるか大体把握する頭脳
□ 適度なタイミングでまばたき
■ バッテリー搭載
□ 障害物回避(またはルート生成)
□ バッテリー電圧低下検出と対応
○ 膝サーボの放熱処理
○ 頭ユニットの取り付け構造変更(メンテ性向上)

11月28日

転倒判定のための実験をやろうと思っていたのだが、週末のために頭ユニットの取り付け構造の検討を先にやることに。

大体構造は考えていたのだが、検討図を描いてみるとどうにも気に入らず、やりなおし。やはり予定以上の時間がかかってしまった。(>_<)

頭ユニットの取り付けを赤丸の2箇所のネジに変更。いままでは真ん中のサーボの下にあった。 そもそも頭を設計する前にフレームを設計したもんだから、頭ユニット固定用のネジは大体こんなもんかなーという位置にネジを設けておいた。 結果、さっぱりいい位置じゃなく、頭ユニットを付け外しするためにCPUユニットを外さなきゃならないという羽目になった。 思ったより頭サーボのヒューズが飛んじゃうもんだからメンテ性考えて部品追加のデメリットを省みずに構造変更することにした。

これでヒューズ交換の手間がいくらか軽減するだろう。

あとは膝の放熱だな。 これは膝サーボのモーター部を下腿のアルミフレームに熱的に接続すればいいんじゃないかと考えている。熱的接続にはグラファイトシートを使ってみようと思っている。 これは面方向の熱伝導率が高く、広い面積に熱を拡散させる働きがある。うまくいけばフィンを立てたりしなくても放熱効果が得られるんじゃないかと期待してる。

■ その場旋回
■ 歩行セット化
□ こけた時の受け身
  □ 転倒検出
  □ 受け身モーション
□ 立ち上がり
□ トラッキング歩行
□ 色いろいろ認識テーブル作成か、複色物体把握
□ 紙コップを持ち上げるとかはらうとかけるとか
□ どのコップがどこにあるか大体把握する頭脳
□ 適度なタイミングでまばたき
■ バッテリー搭載
□ 障害物回避(またはルート生成)
□ バッテリー電圧低下検出と対応
○ 膝サーボの放熱処理
○ 頭ユニットの取り付け構造変更(メンテ性向上) → 
構造検討まで完了
○ サーボのトルクとコンプライアンススロープの調整(歩行安定化)

消化するどころか増えて行ってるな。。。

11月29日

悲しい出来事。

首サーボのギアがとんでしまいました。

 ファイナルギアはとばなかった。でも画像のギア、2個がとんじゃいました。

それは受け身モーションを作っているときの出来事でした。 受け身モーションってもともと頭部ユニットのサーボを守るために転倒時の衝撃を少しでも小さくするのが目的で実装するつもりなのです。

こける時に前に手を出して、顔面が激突するのを防ぐという、いわゆる柔道の前受け身をやらせようということです。もちろん下半身の姿勢やトルク、首サーボのトルクなども連動して衝撃を逃がすようにするつもり。

今日は一番問題の腕の動きを検討してました。 腕の上げ方が問題で、ラムダは普段は手を下に垂れ下げているので前受け身をする腕の姿勢になるには、こう、、スカートをめくるような軌道になります。あ、ちゃぶ台をひっくり返すような、の方がいいかな。 それだと、モーションの起動が遅れると事態を悪化させ、顔面激突どころか顔面で受け身という状態になってしまうのです。

なので、そうならないような腕の軌道を作るのが問題で、それに取り組んでました。具体的には手先が胴体をなめながら上に上げていくような・・・って言えばいいのかな、そういう軌道にしなければならない。。

モーション作成は難しい。。。 今回はハードコーティングでやっているのでプログラムに直接書き込んでいるのでモーション調整もいちいちプログラムをコンパイルです。 で、なんとかそれらしいのができたので、いそいそと実機で確認をしていたのです。

お、なかなか調子いい♪ 結構簡単にできそうだなーとか思いつつ、何度もやってたら、、 第一チルトのサーボがブチンと逝ってしまった。(>_<)

今回はヒューズは飛ばず。。 ヒューズネジは2本でよかったようです。3本だとギアの方が弱いらしい。

いや、それより、首のサーボトルクはフルのままだった。。これだと腕で受け身をせずにベターンと倒れた方がサーボに対する負荷は小さいんじゃないかな。腕で受け身を取ることと首のトルクを抜くことはセットだったのをうっかり忘れていた。(>_<)

ギアはプラギアだし、こないだ念のために買っておいてたし、500円だし、全然問題ないのだが、自分の浅はかさが悲しい。予想してた通りになってしまった。(11月4日の日誌を参照)

週末には頭ユニットの取り付け構造の改良を行うので、ラムダはしばらく首なしに逆戻りです。

11月30日

まずは前側の受け身モーションができました。

練習はご近所の迷惑にならないように低反発クッションの上でボフゥっと倒れる。これくらい分厚いクッションがあるといいな。低反発クッションを手の甲につけようかな。(^_^;)

腕と足のモーションはできたが、頭ユニットはまだ外しているので、頭ユニットの動作やらトルク指示やらはまだ未実装。

タイソンのピーカーブーの感じの受け身姿勢を考えていたのだが、それだと肘で受けて、肩に衝撃を受けることになる。さすがのRS601も軸に直交した力が加わってもダンピングできない。 なので、パンタグラフ型、いや、腕立て伏せかな?のようにして、肘と肩のダンパーで衝撃を吸収します。

・・・・・・・・・・・・・

掲示板を復活させました。

苦情・要望・感想、その他なんでも書き込んでください。よろしくお願いします。

12月1日

午前、膝の放熱構造の検討と設計をやって、午後から工作。 と思っていたら、設計が終わったところでCADがダウン。。 ファイルしてない。。 (>_<) 2時間の作業が無駄に。

やり直しなのだが、一度やった作業なので1時間で取り戻して、工作開始。

頭ユニットの取り付け構造はすんなりできたが、膝の放熱板はうまくいかねー。削ったり隙間を埋めたり調整したが、サーボのモーター部分にうまく接触できなーい。高価で希少なグラファイトシートを貼ったのに薄過ぎてダメでした。もっと性能が悪くてもしっかりと接触できる方が効率がいいに決まっている。材料入手して修正せねばなるまい。

  

膝裏のアルミ板が追加した放熱板。フィンは無し。 足のフレームに熱的に接続することでの放熱効果を期待。

   矢印部分に固定ネジ。4本も要らないとは思うけど4本。 以前は真ん中のサーボの下にあったのだ。さらに真ん中のサーボを外すのは背中のCPUユニットの下にあるネジを外さねばならなかったのだ。 ヒドイ構造だ。(^_^;)

頭ユニットの取り付け構造も変更。 指さしている首の付け根のネジ(左右で4本に変更)で頭ユニットの付け外しが出来る。これで、検討時は気軽に頭をはずせるし、ネジヒューズが飛んだ時の交換作業も簡単になった。実は、頭ユニットの設計をした時もユニットの付け外しがやりにくいことはわかっていて、随分と悩んだのだがいい構造は思いつかなかった。今回の構造変更では首の取り付け位置を変えずにネジ位置だけ変えることができたので満足。 とは言ってもネジを使い過ぎだし、部品を3つも追加したけど。。

ロボットの構造設計において、メンテナンス性は相当大事。 特に競技に出場することを前提としているロボットではよく考えなければならない要素だと思う。

ラムダは競技に出場することを前提としていない上に、身長を抑えたいとか、構造部材を少なくしたいとか、直交軸でなければならないとか、そういう注文の方がプライオリティが高かったため、メンテナンス性は相当悪い構造になってしまっている。それでも今回の頭ユニットとか、バッテリーの取り付け構造のような部分はメンテ性が重要。必要に応じて改良する必要がある。

ラムダを作った頃の構造では、サーボの固定ネジなんかが緩むだけで分解して締めなおさなければならない部分があったりしたのだが、ネジや部品の形状を変えて、今では増し締めもし易くなってきた。

今日の残務
@膝放熱板の効果測定  → クッション性のある放熱シートを入手してから実施
A後ろ側転倒受け身モーションの作成 → 明日に延伸
■ その場旋回
■ 歩行セット化
□ こけた時の受け身
  □ 転倒検出
  □ 受け身モーション 
→前受け身完成
□ 立ち上がり
□ トラッキング歩行
□ 色いろいろ認識テーブル作成か、複色物体把握
□ 紙コップを持ち上げるとかはらうとかけるとか
□ どのコップがどこにあるか大体把握する頭脳
□ 適度なタイミングでまばたき
■ バッテリー搭載
□ 障害物回避(またはルート生成)
□ バッテリー電圧低下検出と対応
○ 膝サーボの放熱処理 
→放熱板取り付け完了
● 頭ユニットの取り付け構造変更(メンテ性向上)

○ サーボのトルクとコンプライアンススロープの調整(歩行安定化)

カメの歩みだな。

12月2日

今日は、後側の受け身モーションを作るのだけど、前から気になっている頭部分の外装についても検討してみた。

ラムダのイメージは、キュ・・・じゃなくて、イノセントな感じで、生物でいうと宇宙人(?)にしたい。 あとはそう、、人間の子供でいうと大体2歳くらいのイメージで開発している。

イラストに描いてみたりしてもなかなかしっくりこないので、今日はクレイモデルを作ってみた。

まずは骨格部分をバルサで作る。

 大体の大体。

  そして、粘土を盛ってみた。 キュ・・じゃなくて宇宙人のイメージ。

悪くないのだが、目の部分がものすごく難しい。 顔面部分に丸みを持たせると、まぶた部分はすり鉢状にして、目の部分は円形にしなければならない。 形状が複雑なので、3次元CADで描いて、3次元プロッターで原型を作るってのが筋だろう。 んなもん無いし。(^^ゞ

でもさすがに適当に作るわけにもいかないのでCADで描いてみて全体のイメージ合わせ。

 ざっくり削ってみた。 こうするとなんかイマイチ。ぼってりしてる感じ。

丸みを持たせると骨格より一回り大きくなってしまう。 骨格状態で見慣れたものに外装をつけるとちょっとポッチャリしてしまう。 それも限度モノ。

なので外装を薄皮饅頭の皮のようにできるだけ薄くしたモデルを描いてみた。

 描きかけ。 全身のバランスや、顔の大きさに対する目の大きさなんかも大体マッチしてるかなー。

この作り方なら3Dプロッターなしでも精度を出せるはずだし、まずはこの線で形を整えていこうかと思います。


さて、寄り道でほぼ1日使ってしまったのだが、本編も進捗させました。 後ろ側受け身。簡単だった。

 お尻が痛くなりそうなので低反発クッションにドスン。

後にこける時はしりもちをつく。後側は頭で受け身ってわけじゃないから背中からベターンって倒れなきゃオッケー!

我が家の環境は畳かカーペット。とりあえずフローリングでラムダを動かすことはまだないので問題ないのだが、ロボビリヤードはリングでやるわけで、コケルと痛そう。

特にしりもちをついた時は股関節のサーボケースに直接衝撃が加わるのでお尻にパッドを取り付けられるようにしようかな。クッションは低反発クッションがよさげ。膝、手の甲、お尻に取り付ける予定。

さて、次は転倒検出。 

■ その場旋回
■ 歩行セット化
□ こけた時の受け身
  □ 転倒検出
  
■ 受け身モーション ※頭ユニットの動作は未完成
□ 立ち上がり
□ トラッキング歩行
□ 色いろいろ認識テーブル作成か、複色物体把握
□ 紙コップを持ち上げるとかはらうとかけるとか
□ どのコップがどこにあるか大体把握する頭脳
□ 適度なタイミングでまばたき
■ バッテリー搭載
□ 障害物回避(またはルート生成)
□ バッテリー電圧低下検出と対応
○ 膝サーボの放熱処理 →放熱板取り付け完了
● 頭ユニットの取り付け構造変更(メンテ性向上
○ サーボのトルクとコンプライアンススロープの調整(歩行安定化)

12月3日

  

曲面で描いてみた。目の部分もすり鉢状にしてみた。(右ね) まぶたがついてると左の系統の方がしっくりくるのはなぜだろう? うーん・・・、発散してきた。

12月5日

昨日は忘年会(その1)で、作業進捗は無し。

今日で顔の外装設計は完了させるつもりで取り組んだ。CADが言うことを聞かず、手間取ったが、一応は完成。  でも、、、なんだかしっくりこないんだよなぁ。このまま作っていいのか? ボンバーマンか、ディグダグのキャラクターに見えてきたんだけど。。

  

でも、この顔も見慣れてきたようで、久しぶりに外装が無い顔を見ると、「外装を取った構造体」に見えてくるから不思議。

とにかく一度作ってみるか。ダメなら作り直せばいいわけだしね。

12月6日

今日はいよいよ転倒判定に着手。 まずはジャイロセンサーのみで判定する方向でトライしてみます。

↓これが歩いている時のX軸ジャイロの様子。

↓次にこれが止まっている状態から前方へ倒れる時の様子。

↓最後に止まっている時から後方へ倒れる時。

やはり、転倒なんだからX軸の回転を見るべきだろうということで回転方向の連続性を判定基準にしてみます。もちろん絶対的な回転角度も合わせて判定基準にしてみます。

何度か実験してあまり敏感では無い範囲での閾値を見つけて、モーションの起動をかけてみる。

↓まずは簡単な後方受け身。

青い三角が後方転倒を感知したマーク。起動条件がそろうと転倒感知は止まるのではじめの三角グループの最後の位置でモーションの起動がかかったはず。そして、モーションの起動により上体の姿勢が戻っていっているのが判る。

ただし、その後、間違えて前方転倒の感知をしてしまい、姿勢自体は後へ反り返った形になって終わり。 要は起動はうまくいったけどその後の処理がまだ未配慮なんです。

↓次に前方受け身

これはこのグラフじゃわからないけど、失敗。 モーションの起動はかかってはいるが、受け身の手が出る前に胸で着地してしまっている。

モーションの速度には限界があるから、起動を早める必要がある。  が、、、 早めると過敏になってしまう。 感知の判定基準をもう少し複雑にしなければならないようだ。

あと、サーボのトルクを少し落として、電圧を上げる前と同じフィーリングになるようにしてみた。歩かせるとガツガツした感じがなくなった。

■ その場旋回
■ 歩行セット化
□ こけた時の受け身
  □ 転倒検出
  ■ 受け身モーション ※頭ユニットの動作は未完成
□ 立ち上がり
□ トラッキング歩行
□ 色いろいろ認識テーブル作成か、複色物体把握
□ 紙コップを持ち上げるとかはらうとかけるとか
□ どのコップがどこにあるか大体把握する頭脳
□ 適度なタイミングでまばたき
■ バッテリー搭載
□ 障害物回避(またはルート生成)
□ バッテリー電圧低下検出と対応
○ 膝サーボの放熱処理 →放熱板取り付け完了
● 頭ユニットの取り付け構造変更(メンテ性向上
● サーボのトルクとコンプライアンススロープの調整(歩行安定化)

12月8日

発散し気味の頭で考えたのだが、転倒判定の新しいルールが浮かばない。 まずは、転倒受け身をしたままの状態では転倒受け身を行わないようなフラグや転倒受け身を行う時に歩行中なら歩行をやめる(そして内部変数を整える)といった辺りを整理。

そうすると普通に歩かせることが出来るので、ランダムに歩かせてみて転倒受け身モーションがうまく発動するか、を試してみた。


トルクを調整したせいか、なかなかこけない(^_^;) 人がコントロールすると、あ、こけそうと思ったら思わず止めてしまったりするんですね。 ま、でもそのうちこけたんですが。

まーなんというか受け身モーションは発動するんだけど、なんていうのか、、、、唐突なんです。普通に歩いてたと思ったらストンとこける。見ててびっくりする感じ。おっとっとぉ〜っていうプロセスが無いからなんだろうなぁ。転倒回避歩行の方がそれっぽいんだろうな〜(遠い目)

それなりに動いているんだけど、まだ微調整が必要かな。微調整するのにプログラムをちまちま直すのがいやなので、転倒受け身モーションを外部ファイルで指定できるようにしました。転倒モーションは普通のモーションと違って、関節移動時間は最速にしつつ、次のモーションの発行までのウェイト時間があったり、トルクを変えたりコンプライアンススロープを変えたりするので結構多彩な記述が必要です。固定フィールドの固定フォーマットにすると記述データ量が膨大になるので、変更点だけを指定できる可変フォーマットにすることにしました。指定パラメータを識別する識別子とその関連パラメータ列を羅列したものが1フレームを構成する。パラメータにはfloatもintもあるのだが、桁を上げてすべてを整数で表現できるようにして、listに格納します。そのフレーム列が一つのモーションを形成するので、データ構造は

vector<list<list<vector<int> > > >

ややこしー(>_<)

いつものようにくだらない間違いに悩まされつつ、さっきやっと動きましたぁ〜。 モーションの微調整が必要だけど、一応は完成フラグを立てておこう。

歩いててこけるところを動画で公開したいとこだけど、起き上がりができないから動画は無し。さて、次は起き上がりだ。

■ その場旋回
■ 歩行セット化
■ こけた時の受け身
  
■ 転倒検出
  ■ 受け身モーション ※頭ユニットの動作は未完成
  
■ 受け身モーションを外部ファイル化する。
□ 立ち上がり
□ トラッキング歩行
□ 色いろいろ認識テーブル作成か、複色物体把握
□ 紙コップを持ち上げるとかはらうとかけるとか
□ どのコップがどこにあるか大体把握する頭脳
□ 適度なタイミングでまばたき
■ バッテリー搭載
□ 障害物回避(またはルート生成)
□ バッテリー電圧低下検出と対応
○ 膝サーボの放熱処理 →放熱板取り付け完了
● 頭ユニットの取り付け構造変更(メンテ性向上
● サーボのトルクとコンプライアンススロープの調整(歩行安定化)

12月9日

今日は、膝サーボの放熱処理から着手。結果から言うと失敗。全然効果なしです。(T_T)

 熱拡散用プレートに熱伝導材を貼ったもの

放熱板無し・放熱板あり・熱伝導シート付き放熱板 の3パターンで耐久試験をやってみました。 ラムダを膝曲げ状態で立たせて温度を監視。 数値はRS601CRの温度センサーのデータそのまま。マニュアル見ても摂氏への変換式がない。数値が少ないほど温度は高い。横軸はひと目盛り30秒。

結果はこのとおり、差分は認められなかった。強いて言うなら放熱板のみを取り付けたケースが一番いい。でも、これは変化ありとは言わないなぁ。

熱伝導シートを変えて試してみる価値はあるけれど、放熱の方式自体に問題があるように思える。サーボが熱でダウン(制御による停止だけど)した時点でのモーター部表面温度は51℃。マニュアルによるとセンサー付近の温度は120℃程度になっているそうだ。

ハウジングが50℃超の時、放熱板はほのかに暖かくなるだけなので、熱伝達がうまくいっていないのも事実。このあたりに改良の余地がある。

もしかすると、モーター部のハウジングの熱抵抗が高いのかな。それだと手の打ちようがないが。


放熱板はそこで打ち切り。次は立ち上がりモーションの生成に取り掛かる。

起き上がりのプロセスは

寝ている → 座っている → 手を付いて立つ → 手を付かずに立つ

という感じ。 ラムダはサーボの情報から今の姿勢を算出できるので、いまの姿勢から一番適した立ち上がりモーションを生成・実行するようにする。例えば、コケかけて手を付いた状態にある場合、「手を付いて立つ」状態なので、そこから「手を付かずに立つ」に移行するモーションを生成するというわけである。

まずは、現在姿勢を「姿勢タイプ」に分類する。 とりあえず、こんな↓感じ。

■仰向け姿勢
仰向けに寝ている状態。
判定基準↓
胴体姿勢: tilt ≒ +90deg, pan ≒ 0deg
下半身姿勢: height ≒ 0 または height < 0
整った仰向け姿勢
depth = 0, hung = 0, footpan = 0, foottilt = 0
■俯き姿勢
俯きで寝ている状態
判定基準↓
胴体姿勢: tilt ≒ -90deg, pan ≒ 0deg
下半身姿勢: height ≒ 0 または height < 0
整った姿勢
depth = 0, hung = 0, footpan = 0, foottilt = 0
■横向き寝姿勢
横向きで寝ている状態
判定基準↓
胴体姿勢: pan≫0 または pan≪0
■座位
座っている状態
判定基準↓
胴体姿勢: tilt ≒ 0deg, pan ≒ 0deg
下半身姿勢: height ≒ 0 または height < 0
整った姿勢
(depth = 0), hung = 0, footpan = 0, foottilt = 0
■準立位
手を付いて立っている状態(手を着けば立てる状態)
胴体姿勢: g.y≫0 または g.y≪0 pan ≒ 0deg
下半身姿勢: height ≫ 0
※height とtiltの関係で、手先が床に届く必要がある。
整った姿勢
(depth = 0), hung = 0, footpan = 0, foottilt = 0
■膝立ち
膝を付いて立っている状態
■立位
立っている状態(手を着かないでも立てる状態)
■転倒姿勢
立位でも準立位でも無い状態
g.yは十分大きいが、手が着かない。

まだ、寝転んでいるのに「準立位」と判別してしまったりするのでデバッグが必要。

判別できたら、その姿勢のリファレンス姿勢に移行し、そこから先は各姿勢のリファレンス姿勢を移行していく。。 とすれば簡単なのだが、面白くないので、 今の姿勢にもっとも近い「整った姿勢」に移行し、そこから上位(立位を最上位として、)に移行する。この時、1段階上位の姿勢へ移行するのだが、今の整った姿勢から移行できる上位姿勢へ移行する。

できるだけ床面を滑らないで動作できればいいかなと思っている。

今日出来たのは「仰向け姿勢」を整った仰向け姿勢に移行するところまで。この調子だと週末の練習会までにラムダが自分で立ち上がるのは難しいかもなぁ。

12月12日

出張続きだったり、飲みに行ってたり、工作途中だったりで日誌を更新していなかった。

実は今日も日誌を書くほどの進捗はないのだが、IKベースでの姿勢移行に必要な「ロール軸消失問題」の回避策として用意したJ1角度ゼロ化処理とその適用についてまとめた。

ラムダと同じ軸構造を持っているロボットはほとんど居ないと思われる上に、角度ベースでのモーションだと問題にならない事象なので純粋に自分のメモってことです(^_^;)

【姿勢移行中のJ1Z処理の適用について】

J1関節角度を0度とすることでロール軸消失問題に伴うJ1関節角度が不安定になる問題を回避したい。 もちろんJ1関節が常に0度でよいはずはないので、J1Z処理を適用するか否かの判断が必要となる。

J1Z処理は適用できる姿勢と出来ない姿勢があるため、開始姿勢から目標姿勢までの全フレームにおいてJ1Z処理が適用可能とは限らない。さらには適用可能な姿勢といっても「J1Z姿勢への移行」というプロセスが必要となる。

このJ1Z姿勢への移行をどのように実装するかを考える上でいままでの問題を整理する。

・J2関節角度が-90度付近で、J1関節角度が大きく変動する領域がある。これは足の関節構造に依存しており、ロール角を一定角度に保ったままで姿勢を移行しようとした時に問題に直面する。

具体的にはJ2が-90度の時、J3とJ2は同軸となり、自由度が一つ消失する。J2が-90度付近では自由度の消失とはならないがJ1,J3が不安定になる。

・対策として、もっとも簡単なものは姿勢の移行を関節角度を等速で変化させればよい。ただし、その方法だと姿勢移行中の姿勢が不安定となり、重心補正やジャイロフィードバックのような制御類が行えなくなるという問題が新たに発生する。

他の対策として、ロール角をフリーとし、姿勢以降に際して関節角度の変化が大きくならないような姿勢移行軌道を取れば良い、という方法が考えられる。

・そこでJ2関節が-90度付近ではJ1関節角度を0度に決めうちし、目的の足先座標を取るためのロール角度を逆算する。この方法はやはり自由度が一つ減ることには違い無く、実施できない姿勢が発生する。概ねJ4関節(膝関節)が伸びているような姿勢は取ることができなくなる。

・J1Z処理が必要な移行のケースは、開始姿勢と終了姿勢でのJ2関節角度を見比べたとき-90度をまたいでいるかどうかを見ることでほぼ判別できる。ただ、-90度付近でも不安定な挙動が見られるため、判断するためにはある程度の幅を持つ必要がある。

・J1Z処理を適用するタイミングを決めるにはJ1Z処理を必要とする姿勢を取るフレームの範囲と、J1Z処理が適用できるフレームの範囲をあらかじめ知る必要がある。これは今のところ解析的に求めることができないため、全移行フレームを一度計算することで把握するしかない。

そのうえでJ1Z処理適用可能範囲のエッジとJ1Z処理必要範囲のエッジでJ1Z姿勢の移行を行う。


本当は解析的に算出したいんだけど、今後、ロボットの知能部分を開発していくと解析的に計算できることなんてほとんど無くなる。まぁそれの前哨戦みたいなもんかなぁと思って納得するしかないです。

12月13日

やっとラムダの面の皮ができたぁ〜。

といってもまだファーストトライ。 バキュームは失敗するし、あちこち干渉もありそうだし、調整しなきゃ。 でも、なんとなくいい感じなので目の穴を開けて取り付けてみた。

瞬きさせてみたり↓

 ガチャピン

色々準備できてないのでただまばたきするだけ。 ちなみに面の皮はかぶせているだけ。すぐ取れちゃいます。 白のままだと画像栄えしないなー。

  これが原型。バルサを削り出して、ポリパテで仕上げ(仕上げ?)。

  穴が開いて失敗。 お試しで0.5ミリのプラバンでやったのだが、吸いきる前に穴があいたので最後まで引けず。

練習会までに頭部全部の外装を作るつもりだったけど、あきらめました。このファーストトライ面の皮をくっつけて参加します。

12月14日

 開発中のアラレちゃん状態。

白面の者のままだと白すぎるので軽く塗装してみた。

プラバン自体がものすごーく薄くなっているので、まもなく変形して塗装がはがれてくると思う。明日の輸送に耐えられるか?(^_^;)

塗装色は、CAD上で決めた色が模型屋でみつからなかったのでその場で物色してシャンパンゴールドを選んでみたが、可も無く不可も無くといったところ。この色を本採用するかどうかはちょっと様子見だな。

今日は、明日の練習会の準備で開発らしいことは何も出来なかった。 準備というのは、、、、@秋葉原での開催なのでついでに買い物に行くつもりでその買い物リスト作り A忘年会でお初の方に沢山出会うであろうからラム研の名刺作り Bそれと不慮の事故に備えてパソコンのデータをバックアップ。ラムダ本体より大事かも知れない。(いや、601サーボとRPU100の方が価値はでかいか?)

練習会でラムダを動かすに当たって最低でもやっておきたいことがいくつもあったのだが、完全に完了している事項は何一つない。。。まったくもって情け無い限りだ。

・転倒受け身、頭ユニット含み版モーション → 未完了
・歩行セット化バグ修正 → 未完了
・バッテリ電圧監視。音声で通知とトルクオフ(トルクをオフする前にしゃがみこむ) → 未完了
・尻餅のためのお尻の肉(低反発クッション)取り付け → 未着手(設計未完了)

面の皮を作ってる時間があったら幾つかはこなせたはずだが、バルサを削る快感には勝てなかった。(^^ゞ

出来なかったリストのうち、転倒受け身の頭付きモーションについては秋葉原でサーボの修理部品を購入してからやろうと思っていたので、致し方ないところではある。

さて、荷物をまとめるとするか。。。

12月16日

昨日は関東組ロボット練習会&忘年会

ロボット界に名を馳せている沢山の人とお知り合いになれてうれしかったです。みなさんこのページを読んでくれているそうで、うれし恥ずかしです。

Jin Satoさんともすこしお話ができまして、忘年会の帰りがけに「ROBO-CUP出場を目指しているんですよね。」といわれました。 が、初夏のころ目指していた来年の5月のジャパンオープン出場はありません。 来年のジャパンオープンからはヒューマノイドリーグが2対2から3対3になるということがほぼ決定のようで、ヒューマノイドリーグに出場するためのロボットを3体準備するのは現実不可能だし、そこまではやらないなぁということです。

と言うのも、自分がイメージする自律ロボットはロボカップには無いのが直接の問題で、出場を目指していたのは「ちから試し」のつもりでした。夏ごろから「とにかく自立」(自律ではなく)を進める中で、ロボカップに向けたロボットを開発するという寄り道をする余裕は自分にはないなと思いまして、自律ロボットは独自路線で進める方向を改めて見直したという次第です。

でも、ダラダラと作っていても目標がぶれてしまったり活動が偏ったりしてしまうのも事実ですので、マイルストーン目標は必要かとも思っています。

今のマイルストーン目標は、第一に「自律でロボビリヤード完遂」。遠い目標としてはわんだほーのダッシュ2000を自律で行わせる。ただし、ルールを人語で説明し、ターンするパイロンを指差し指示とかで教えた上で達成させる、というもの。遠い目標を達成するまでには沢山のマイルストーン目標が必要と思う。

・・・・・・・

昨日の練習会。

昨日の練習会は正直失敗でした。ロボット好きが集まってワイワイやるムードを満喫して楽しかったのは間違いないのですが、大会イベントに参加しないラムダにとって練習会出場はある意味お披露目の場でもあるのです。今回は完全な準備不足であまりにも中途半端な状態での参加だったので、参加目的の半分は失敗ということです。

間に合わなかったアイテムは早々に完了させて次に進まねば。

2月には第一回のロボビリヤード自律トライを計画しているのだが、できるかなぁ〜。 ぶれずに開発を進めなければ難しいだろうな。 ・・2月の練習会ってどこ開催だっけ?

首サーボの補修部品(プラギアセット)を買ってきたので、練習会場で頭ユニット付きの転倒受け身モーションの作成をやったんだけど、つい、転倒受け身が発動しない設定のまま転倒させてしまい、またもやギアが飛んでしまった。買ってきた補修部品はあっというまに活用されてしまった。orz

第一チルトのサーボはプラギアじゃ持たないですね。今日早速RS301CRを一つ注文しました。ロボットファクトリーで新古品で7350円(税込み)で売ってた。未使用品らしいから買いです。(1個しか買わなかったけど。)

・・・・・・・

昨日帰ると、注文していた「Pico-ITX」が届いてました。 練習会を抜け出してこれを動かすためのアイテムを色々と買い集めていたので早速動作確認のために組み立てる。

  

電源はのむむさんに教えてもらったpicoPSU-60WI電源入力がDCジャックになってるので、安定化電源につなぐためにコネクタをバシッと切断。切った後に、「あ、初期不良交換できなくなった。。」大丈夫だったけど。(^_^;)

ストレージはCFカードをIDEに変換して接続。8GBのCFカードを6000円以下で買おうと思っていたが8500円までしか見つからなかったので通販で買うことに。動作確認には家にあった256MBのCFカードを使用。「Flash Card」と認識されました。ってか、これって変換カードが送ってるんだよな。

メモリーはDDR2-533 1GBを3000円で買ってきたけど、探せばDDR2-667 1GBで2000円くらいでも売ってる様子。やっすいなぁ〜。

家にあるスリムCDドライブはIDEしかないのでS-ATAに変換して接続するつもりで変換ボードも買ってきたのだが、SATAのケーブルって添付されて無いのね。。。 我が家にはSATAモノがいままで無かったのでケーブルもありません。 OSインストールしてCFでのブートのテストは後日となりました。

これにLinux入れてラムダ(もしくはラムダ2号)に搭載する予定。 ちっこいけどファンが付いてるからちょっとうるさい。 搭載できるようになる前に、ファン無しで、もっと速くて、消費電力が小さなMBが出るような未来のイメージがハッキリと見えるんだけど、まぁいいよね。(^^ゞ

 キーボードコネクタの接続方向。メモのつもりで掲載。

・・・・・・・・

夜からは昨日の練習会で動作がおかしくなったいくつかの事象について、確認。

首の第一チルトの動作がどうもおかしい。いや、頭部ユニットの動作がおかしい。まだ全容はわかっていないが、サーボへのロングコマンドが一部のサーボに反映されていなかったりする場合がある。バグなのか仕様なのか?

その他でもまだ頭部ユニットの動きが不全な点がある。特に第一チルトサーボがおかしいのだが、場合によっては第二チルトと同期しておかしな動作をすることがある。二つのサーボが同期して動くなんてハード障害では極めて起こりにくいと思うので、これはバグかなと。

症状から疑うべきは@バグ。割り込みルーチンの時間オーバーで一部のコマンドが正しく送信できない。 A通信エラー。必ず通信エラーを起こすってのはおかしいな? Bサーボのファーム仕様またはバグ。

ファームの仕様を調べたが一度のロングコマンドで送れるデータサイズ(またはサーボ数)が書いてない。これが原因なら調べる時間が無駄なのでそこだけは確認しておこう。

続きは明日の夜。早く帰れたら。。

12月17日

今日は朝から福岡へ出張だというのに、昨日は「なんでだろう?なんでだろう?」って考えてさっぱり眠れなかった。飛行機でも2時間考え詰め。これじゃいかんということで考えられることと帰ったらやることをリストアップして、このことはとりあえず忘れることに。

仕事が順調に終わったので福岡の街に滞在すること数時間(^_^;)、予定の飛行機を早めて帰ってきました。早く解決しなきゃ不眠で倒れてしまう。(>_<)

帰ってメシ食って、デバッグにいそしみました。

結果はどうやら複数のサーボに一度にコマンドを送るロングパケットに問題があるようです。601サーボと302サーボが混在しているせいなのかどうなのかまでは突き止めてませんが、20個のサーボだと混在でも問題なしなのに23個にするとロングパケットで送ったデータが反映されません。

反映されないだけならまだしも302に到ってはその後に発信された角度データが自分宛ではないのになんだか反応してしまい、おかしな動作をするようです。

ウェイトやコマンド順序などは関係なさそうで、単に一度のロングパケットのID数を20個に限定すれば問題がなくなりました。302側の配慮不足なのかなぁ?

おかしくなるケースが判明したのでプログラムで対処し、まずは思い通りの動きをしだしたので、転倒受け身モーションのテストやら調整やらをしました。前方への転倒はまだ検討の余地があって、遅い速度ならなんとかなるが、少し早くなるとまだ胸で着地してしまう。後側の尻餅だけはまぁうまく行っている(簡単だから(^_^;) )ので簡単な動画で紹介しておきます。

 転倒受け身(しりもち)

衝撃吸収をするなら柔道の受け身みたいに後に転がって頭を持ち上げてってする方がいいんだとは思うけど、尻餅にしました。背中は色々あるし。お尻には低反発クッションをつける予定だけど、仮にスポンジゴムを貼り付けてます。

転倒判定としては単純にジャイロ値の累計を取っているんだけど、同じ方向の回転がある短い時間続く中である大きさの累計量があれば転倒と見なすという判定です。つまり、遅い転倒には反応しない。静止状態で転倒してしまうような姿勢になった時は(回避行動を取らせたいがまだ出来ないので、、、、)それも転倒させてしまった方がいいかなと考えているので加速度センサーを使った転倒判定も併用するつもりです。

前側の転倒はこちらは柔道の前受け身に近い動作をさせるのだけど、もうちょっと検討が必要。腕の動きが付いてこなくてまだまだ顔から落ちる。

ちなみに第一チルトはデフォルトでコンプライアンススロープ設定を大きくしているのでなかなか壊れません。最初からそうすりゃ壊れなかったんだろうなー、アホです。

今気付いたけど、腕のトルクのデフォルトが50%だった。腕を上げるときは一旦100%にしなきゃならないんだったぁ〜(>_<)

・・・・・・・・

ちなみに昨日注文したRS301CRは、もう今日届きました。まだ通電してみてないけど。

さて、301に積み替えだけは今日やって、寝るかなー。 今日は気持ちよく眠れそうです。(*^^)v

12月19日

 悶死状態のラムダ

さて、次は転倒受け身(前側)だ! と勇んで取り組んでいたのだが、できたぁ〜、 というところで首のネジヒューズが飛んでしまった。RS301CRに交換した成果(?)かな。実はサーボをプラギアの302からメタルギアの301に交換する際に、ネジヒューズにも細工をしておいた。302の時にネジヒューズが飛ばずにプラギアが欠けてしまったので、ネジが飛びやすいように溝をつけておいたのだ。プラギアと違って、メタルギアの交換セットは2500円。欠けたらいやだし。

前受け身タイプ以外の転倒受け身手段も考えねばならないな。尻餅みたいに頭が倒れないで済む方法ないかなー。いっそのこと第一チルトのトルクを抜いてしまった方がいいかも。

尻餅や前受け身のモーションの再生はクイックモーション(命名:しまけん)という仕組みを作った。 といっても特に難しいことをやっているわけじゃなく、キーフレームとキーフレームの間に補間フレームが無いだけである。 仕組みとしては補間フレームを生成させることもできるが、転倒受け身モーションでは使っていない。 すばやく動かすために移動時間ゼロでサーボを動かし、実際にサーボの動作にかかる時間をウェイトをかけるモーション再生である。 多分、バトル系のロボットのモーションはほとんどこのような動かし方をしてるんじゃないかと思う。 転倒受け身の場合はサーボのトルクを抜いたり、関節にダンパー要素としてコンプライアンススロープ設定を行ったりすることもモーションデータで指定できるようにした。

少し前の日誌にも書いたが、姿勢を表す全パラメータを指定するのは冗長で面倒なので、元になる姿勢からの差分だけを指示できるようにしている。

条件分岐なんかが無いので「スクリプト」とまでは言えないが、こんな感じですよーってことでクイックモーションファイルをお見せします。

MOTION  ←モーションの開始
# front fall landing
FRAME  ←フレームの開始
ARMTORQUE:0:80:80:80:80  ←右足のトルクを80%にする。
ARMTORQUE:1:80:80:80:80  ←左足のトルクを80%にする。
ARMSLOPE:0:-1:-1:-1:-1:-1:-1:-1:-1  ←右足のコンプライアンススロープをデフォルトにする。
ARMSLOPE:1:-1:-1:-1:-1:-1:-1:-1:-1
UBPARM:0:5000:97000:6000:0:0  ←右足の座標指示
UBPARM:1:5000:97000:6000:0:0  ←左足の座標指示
UBPARM:0  ←上半身姿勢決定
TIME:6  ←フレームの継続時間(待ち時間)
FRAME  ←次のフレームの開始
LBPGETTARGET  ←下半身姿勢を現在値を取得
LBPHEIGHT:170000  ←高さを170oに設定
LBPTILT:15000  ←上半身(股関節姿勢)のチルト角を15度に設定
LBPGY:85000  ←Y方向重心オフセットを85oに設定
LBP:0  ←下半身姿勢決定
HEADPOS:0:45000:0:0  ←頭ユニットの姿勢指示
LEGTORQUE:0:-2:-2:-2:10:10:-2  ←右足のトルクを指示(J4とJ5を10%に、その他は今のまま)
LEGTORQUE:1:-2:-2:-2:10:10:-2
LEGSLOPE:0:200:200:200:200:200:200:200:200:200:200:200:200  ←右足のコンプライアンススロープを設定(ゆるゆるにする)
LEGSLOPE:1:200:200:200:200:200:200:200:200:200:200:200:200
TIME:10
FRAME
HEADTORQUE:0:10:10
HEADSLOPE:250:250:250:250:250:250:
TIME:4
FRAME
ARMTORQUE:0:30:30:30:30
ARMTORQUE:1:30:30:30:30
ARMSLOPE:0:200:200:200:200:200:200:200:200
ARMSLOPE:1:200:200:200:200:200:200:200:200
#MEND
MOTION
# back fall landing
FRAME
UBPARM:0:30000:0:-100000:0
UBPARM:1:30000:0:-100000:0
UBPARM:0
LBPHEIGHT:8000
LBPTILT:0
LBPGY:-180000
LBPJ1Z:
LBP:0
LEGTORQUE:0:-2:-2:-2:10:10:-2
LEGTORQUE:1:-2:-2:-2:10:10:-2
LEGSLOPE:0:200:200:200:200:200:200:200:200:200:200:200:200
LEGSLOPE:1:200:200:200:200:200:200:200:200:200:200:200:200
TIME:8
FRAME
ARMTORQUE:0:30:30:30:30
ARMTORQUE:1:30:30:30:30
ARMSLOPE:0:200:200:200:200:200:200:200:200
ARMSLOPE:1:200:200:200:200:200:200:200:200
HEADTORQUE:10:10:10
HEADSLOPE:250:250:250:250:250:250:
#MEND
MOTION
# test motion
FRAME
ARMTORQUE:0:80:80:80:80
ARMTORQUE:1:80:80:80:80
ARMSLOPE:0:-1:-1:-1:-1:-1:-1:-1:-1
ARMSLOPE:1:-1:-1:-1:-1:-1:-1:-1:-1
UBPARM:0:5000:97000:6000:0:0
UBPARM:1:5000:97000:6000:0:0
UBPARM:0
#MEND

これは少し面白い使い方ができ、例えば歩いている時に転倒したとすると、片足が前に出た状態になっている。 立っている時に転倒したとすると両足が揃っている状態かもしれない。現状の姿勢を取り込むことで、転倒する時の状況に応じたフレームを生成することができるのだぁぁぁ。 って、まだ有意義な活用ができてませんが。。(^^ゞ

気を取り直してネジヒューズを交換して転倒受け身(前側)撮影↓

 転倒受け身(前側)

モーション起動時に第一チルトのトルクをゼロにまで落としたが、ネジヒューズが飛んでしまった。

動画を見ると、手を出しているだけのように見えるが、脛から下も脱力して、膝を付くようにしている。転倒速度が速いので膝を付く前に倒れてしまうのだ。もっと積極的に膝を付けた方がいいのかな?もうちょっと悩まなきゃならなそう。。

さて、、ネジヒューズを交換して今日は寝るかぁ〜。

12月20日

昨日に引き続き、転倒受け身(前側)の検討。

積極的に膝を落としたら、なかなかいい感じ。 その調子で、もっと腕を伸ばした状態で受け身できないかと検討を続けたところ、何とかなりそう。

で、またもやできたぁ〜。さぁ撮影しよう! と、思ってみたらネジヒューズとんでました。(>_<) ネジヒューズをもっと固くしようかなとも思ったけど、ここは我慢して更に検討すべきところだろう。大きな力が首にかかっていることは間違いないのだし。

次に、 腕を伸ばした状態での受身ができるようになったので、こんどは逆に首を下に伸ばして荷重を受けないようにしてみました。腕で支えるのを失敗したらひどいことになるのでどんなもんかな?とは思うのだが、とりあえずトライ。下の画像が転倒受身をした状態。足がちょっと内股気味になっているのはJ1Z処理を行っているため。

 なかなかいい感じで転びます。(^・^) 今日はもう時間がないので動画は後日。


早速、歩かせてみて、こかせてみたのだが、モーションの起動条件が合わないなぁ〜。転倒判定はもっと調整が必要のようです。

※昨日、眠いの我慢して日誌を書いたのにアップせずに寝てました。(^^ゞ 今日(12月21日)は忘年会で作業なし。出張だったんだけど移動中爆睡してたので考察もなしってことで今日(21日)の日誌は無しです。

12月23日

転倒受身も出来上がったので次のステップとしては起き上がりモーション生成。 そのための姿勢判別の精度を上げるというのをやろうと。。

その前に、先日時間がなくて動画がアップできなかった前側転倒受身第2パターンの動画をアップしておきます。

 転倒受身(前側のその2) 

手が先に着くのを期待して、第一チルトは力を受け流す方向へ積極的に動かしています。 手が間に合わなかったら顔面で着地です。

この受身の方がいい感じなので採用したいところですが、モーション発動が間に合わなかった時のダメージがでかいので先日のとどちらがいいのか難しいところ。正解はまだ別にあるんじゃなかろうかとも思います。

受身が出来るようになったので歩かせながらモーションの発動具合を見てみると、、、 後ろ側は言うに及ばず問題なし。 でも、前側が全然ダメ。 あれこれ試すうちにとうとう第二チルトのサーボのギアがお亡くなりになってしまいました。(第一チルトはネジヒューズを何度も飛ばした)

第二チルトも301にしようかなぁ〜と思ったけど、オプションのメタルギアが301/302共用らしいのでメタルギアに取り替えるだけにしておくことにしました。中古301はとっくに売り切れた様子。残念。

まーそんなこんなで転倒受身モーションの発動タイミングについてはまだまだ検討を続けねばならなそうです。今の条件は余りにもやっつけ仕事的なのでキチンと検討しなきゃならないだろうな。


転倒受身を活かしたまま、歩かせてみると、なんだか歩行の様子がおかしい。 なんだかガッツンガッツンしてる。おかしいなぁ??? 悩むこと半日。 結果は転倒から復帰してサーボのトルクやコンプライアンススロープ設定を戻す処理にバグがあり、関節ガチガチにしてしまっていた。

ラムダの歩行は3次元倒立振子軌道を計算して足の動きを生成しているのだけど、足首の左右のサーボはダンパー設定をゆるゆるにしています。そうしないとすぐに振幅が大きくなりすぎてこけてしまう。ロボットが計算どおりに動いていないってことなのだけど、それほど厳密な計算をしているわけじゃないので仕方が無い。それにしても、機能を付け加えていくと、バグの関連も複雑に関与し合う様になって、究明解決するのに時間がかかる。もっとシステマチックなプログラムにすればもうちょっと安定するのだろうけど、なかなかその手法がわかりません。修行が足らんってことなんでしょう。(>_<)

・・・・・・・・・・・・・

そろそろ歩かせながらの開発になるので紐付きじゃなく、バッテリー駆動の機会が増えてくる。 まだ電圧監視回路には未着手なので、バッテリーの過放電が心配。電源切断はできないにしても、サーボのトルクオフくらいは出来るので、電圧がある程度低くなったらモーションを発動してトルクをオフにするようにしておくことにします。とりあえずの処置なので余り手間をかけずに、、座り込んでトルクをオフにするだけにしました。グシャリとへたり込むところが情緒があるので動画上げときます。

 バッテリー監視

クイックモーションでも、普通のモーション再生もできるので、こんなにあやつり糸を切ったみたいにしなくてもいいんだけど。。(^^ゞ 転倒受身モーションが発動してしまっているのがけなげです。

結局、姿勢判別については未着手でした。(^_^;)

・・・・・・・・・・・・

実は平行してPico-ITXのOSインストールも進めています。そんなに急がなくてもいいんだけど、気になって落ち着かないのでキリがいいところまではやっておこうと。。

CFカードにDebian Linuxをインストールして、temp とか var とかはRAMDISKで、って感じにしたいのだけど、CFでうまくブートするかがとりあえずの問題。

8GBのノーブランドのCFを6000円くらいで買おうと思っていたが、ブートしなきゃ安くても意味がない。色々探しているうちにやっぱりブート実績がある速いCFカードの方がいいかなー、8GBも要らないから2GBか、4GBくらいにしていいヤツを買おうかなと方針変更しました。ブート実績があって速いってことで、トランセンドのTS4GCF266がいいかなと思ってます。

あとはMBとIDEアダプター側の問題。メモリーカードが良くてもこちらがダメでは元も子もない。というわけで、手持ちの256MBのCFでブートさせてみるってことをやってました。

調べると、USBメモリーでのブートについてはあちこちに記述があるんだけど、CFをIDEにして、うまくいくって話が見つからない。試してみるにしても、普通にOSインストールは容量が小さくて無理だし。 でもまぁ大して変わらないはずだから、とUSBメモリーでブートさせる手順をほぼそのままIDEにつないだCFカードに試したところ、うまくいきました。さて、CFカード注文しようかなー。年内に届くかな?

   CFから立ち上がった〜。ふぅ。。

こう書くと簡単なんだけど、ここにくるまで結構手探りでした。MBにはIDEとSATAがついているんだけど、スリム型の光学ドライブはIDEの古ーいのしか持って無い。2mmピッチのIDEに2ドライブつなげるためのマルチケーブルって売ってないし、最終的な形態を考えて光学ドライブはSATA-IDE変換アダプターで接続しようと目論んだ。 でも、HDDなら問題ないのに、光学ドライブはSATAに変換しても使えない場合が多いらしい。実際、CDでブートはしてもマウントは出来ず、失敗。 左の画像にあるように、IDEに光学ドライブをつなげばマウント可能になるんだけど、CFカードをSATAにつないでインストールしても意味がない。(SATAはケーブルが邪魔なので最終形態では使わない予定なので。)

インストールした後に接続I/Oを変えようとしてもうまくいかず、最終的にUSBからブートさせてIDEにつないだCFにOSインストールすればなんとかなるかな?となりました。 CFからのブートは確認したけど、USBメモリーからのブートは確認していないのでまだそれでいけるかどうかはわからない。 っていうか、CFでブートしてCFにOSインストールってのもできそうだからそれでいけるかもしれない。

そういえばMBの動作確認さえも手間取った。 最初にHDDで普通にLinuxをインストールしてみたのだが、手元にあった2.5インチのHDDが古かったらしく、このMBじゃブートがかからなかったりして、MBの動作とかメモリーの動作が正常かとかの確認を取るのも手間がかかった。その後、もう処分しようってことで押入れに押し込んでたノートPCから取り外したHDDでMBとかメモリーの動作確認はできました。

ちなみにCFカードよりUSBメモリーの方が安くて小さいからメインのストレージにUSBメモリーを、とも考えたけど、どうもしっくりこなくてCFを選んでます。USBには無線LANアダプターやカメラをつなぐつもりで、そちらのために空けておきます。(USBバスの仕組みを知らないので空けておくことに意味があるかどうか判りませんが。)

#ん〜、なんかイッパイ書いたな。

12月24日

世間はクリスマスイブだが、うちはわき目もふらずにロボット開発(^_^;)

今日はまじめに姿勢判定に取り掛かった。

ここでいう姿勢判定というのは、関節角度と加速度センサー情報を元にした胴体姿勢を元に構築したロボットの姿勢を平面の床に適用したとき、ロボットがどういう状態にあるのかということを判定することです。

この判定結果により、出来る行動やしなければならない行動を判別する。

こないだ作ってみた判定関数は、胴体姿勢と股関節の高さと、支持多角形と重心点(股関節中心)の位置関係から、姿勢の判定を行うというものだった。

これでうまくいくだろうと思っていたのだが、さっぱり判定ミスが多いのだ。

まずは、仰向け寝とうつ伏せ寝から。 これは股関節の高さが低くて、胴体の角度が+90度に近ければ仰向け寝、 -90度に近ければうつ伏せ寝 で、決まりだろう、と思っていたのだが、そんなに簡単でもない。ラムダは背中が膨らんでいるので仰向けになっても股関節の高さは結構ある。100oくらいになる。角度が90度付近で、高さが100oならば四つん這い姿勢でもそれくらいは出来るので判定できない。 ならば条件を切り分けて、ボーダー値の組み合わせで・・・・ と考えていくとなんかキリが無いように思えてきた。

要は判定のパラメータが間違えているのだ。

じゃあ、仕切りなおして寝ている状態の条件はなんだろう?と考える。つまりは地面に対して、胴体で体を支えている状態でいいのかな。お尻の一点で支えている状態ならば座っている状態だから、肩とか背中とかお腹で支えている状態なら「寝転がっている」と言っていいだろう。

というわけでそれを調べることにした。

仰向け寝 うつ伏せ寝

関節角度と胴体姿勢から得られる姿勢値は、足先でもっとも地面に近い点が地面に着いているという前提で計算している。そのため、うつ伏せ寝のような状態では胴体の接地部分の高さはマイナス値になってしまうのだが、判定するだけなら問題ない。(その後のモーション生成には大いに問題なのだが。)

 ラムダの胴体側面 (背中側のチェックポイントの位置が間違えていたので修正した)

チェックポイントとしては図の赤い点と緑の点。赤い点は仰向け寝の判定ポイント。緑の点はうつ伏せ寝の判定ポイント。

股関節を原点としたチェックポイントの座標を胴体姿勢角度で回転させ、股関節座標を加えることでチェックポイントの床面からの高さがわかる。

やってみると仰向け寝は良好に判定するが、うつ伏せ寝がうまく行かない。マイナス値になるはずなのにプラス値、それも30ミリとかの大きな値。なんで??? しばらく悩んだが、結局は胴体角度が±90度付近での股関節高さは角度の誤差が大きく影響するのが原因らしい。調整の結果、胴体チルト角度がマイナス値の場合は補正角度-5度を加えることでほぼ正しい値を出すようになった。

さて、次は座位の判定だな。これは簡単だと思うんだけどなー。 いや、次は立位の方がいいのかな? 寝転んでなくて、立ってなくて、四つん這いじゃないならば、座っているということ。(ただし、静止状態に限る) っていう順番の方がいいのかも。

12月27日

やっと年賀状が書き終わりました。毎年ぎりぎりなんだよねー。

で、4GBのCFカードが届いたのでまずはブートさせてみてその勢いでLinuxのインストールまでやっちゃおうとしたところ、失敗。 (>_<)

ext3ファイルシステムだとさっぱり受け付けないのでext2にしてみたら、ファイルシステムは作れるみたいだけどマウントに失敗する。なんかオプションが要るのかな?CFでシステム構築するときは、もしかしてブートだけさせてramdiskに展開(knoppixみたいに)しなきゃだめなのかと思ったけど、そうでもないらしい。

カーネルにドライバー入れなきゃならないとかだと敷居高いなー。

もうちょっと勉強しないとわからないですね。 年賀状終わらせてCFの動作確認(ブート確認)が終わったら次はラムダを、、とか考えていたが全然時間が足りませんでした。



明日は仕事納め。 仕事後に納会があるらしいから夕方から酔っ払いで帰ってくる予定。 やっぱり明日もプログラムはむりかなぁ〜(^^ゞ

12月29日

今日は帰省の移動日。昨日は「夕方から酔っ払い」どころか、深夜まで飲み続けだったのでもちろん昨日はなんにも出来ず。

いつもは夜移動するので日中は作業ができるはずなんだけど、今回の帰省は昼過ぎに出発することになった。なので、今日は朝から帰省の準備をやりつつ、CFカードでのブートにトライ。本当は転倒判定と転倒モーションの改良をやりたかったんだけど時間の関係でCFカードで。

あれから色々調べたのだが、どうやらCFカードでもext2ファイルシステムで普通にマウントできそうな様子。なぜマウントができなかったのかわからないが、取りあえずHDDでLinuxをブートして、CFカード上のext2ファイルシステムをマウントできることは確認できた。CFカード上のファイルシステム自体には問題ないらしい。

ネット上のみんなのログを見ると、ファイルシステム作成後にカードを抜き差ししているケースがあったので、電源を入れ直せばマウントできるような気がしてきた。そこで、HDDにインストール用のカーネルとinitrdを入れてブートさせてみる。(この時点ではCFカードにext2fsを作ってCFでブートさせる方法がわからなかったので)

Linuxってホントにいろんな仕組みが組み込まれていていろんなことができるんですねー、感動しました。無事HDDからインストールカーネルでブートさせ、CFカード上のext2ファイルシステムをマウントできました。

ただし、ブートローダーを書き込むところでHDDの先頭パーティションを選んでしまい、CFカードからのブートは失敗。続いてCFカードへブートローダーを書き込むところでもやり方を間違えてしまい、ファイルシステム自体を壊してしまいました。

インストールメニューでは「第一ハードディスクの第一パーティションにブートローダーをインストールするのが無難です。」「GRUBブートローダーをインストールしますか?」って聞かれる。これって第一ハードディスクの第一パーティションにインストールするって意味だったんだね。次の画面でインストールする場所を選べるんだと思いました。正解はこの質問では「いいえ」とするとインストールが選べたらしい。

でも、大体見えてきたのでHDDへのLinuxインストールからやりなおし。続けてCFカードにext2fsを作成。なぜか今度はそのままマウントにも成功。(fat16からext2fsへ書き換えるのが問題なのか?)ブートローダーの書き込みもちゃんとCFカード上のパーティションを指定できました。

そしてCFカードからブートしてLinuxを立ち上げることができました。ただ、GRUBブートローダー上はHDDを取り付けているときと外しているときではドライブ番号が変わってしまうため、HDDを外すと立ち上げに失敗します。これは/grub/menu.lstを編集し、(hd1,0)を(hd0,0)に書き換えることでうまく行きました。ほ〜。。

次は頻繁に書き込むパーティションはRAMドライブに、書き込まないドライブはリードオンリーに設定したりをやってみよう。 どうやるんだろ??

帰省先にラムダを持って帰るのはちょっと大変。 今回の帰省ではロボビリヤードでの画像処理の検討をしてみようということでCPUユニットと頭部ユニットだけを持っていくことにしました。電源を持っていくのも荷物なのでニッケル水素バッテリーとその充電器で。ニッケル水素バッテリーをラムダにつなぐためにコネクタ変換ケーブルを作ったんだけど、なんだかおかしい?? 高効率コネクタが接触不良でうまく接続できない。そんなことあるんだなー。  もしかしたらはんだ付けの際にハウジングが変形してしまったのか?? とにかくコネクタを付け直す羽目になってしまった。

リポの充電電圧が供給できるACアダプターを用意しておかなきゃならないな。

12月30日

帰省先から更新です。

今日の宿はネットにつながるので、Linuxのramdiskについて色々と調べていたが、色々試しながらじゃないと感覚が沸かないね。 あ、考えたらこのノートPCにVMware入れているんだからこれにLinuxを入れればいいのかな。CD-R買ってくればできるな。

・・・・・・・・・・・

帰省中は転倒判定とか転倒モーションなんかはできないので、画像関連とか、プロセス管理についての検討を進めようと思っている。

今回の「自律でロボビリヤード」では数字の認識まではやる気がないので、ターゲットの判別には色を使うつもり。色の判別はCDTを使えばでき、CDTは8チャンネルあるので8色の色まで判別できる。だが、近い色は光の加減一つで判別ができなくなるので、判別しやすい色を3色くらい選び、8種類の組み合わせを作って@からGのターゲットにあてがうつもり。

この時、ある色のターゲットを「見る」のだが、同じ色のターゲットが複数目に入る場合が出てくる。

ピンクボールを見ている時のラムダはボールそのものを見ているのではなく、ピンク色の重心の方向を向いているだけで、ボールそのものを見ているわけではないのだ。例えばボールが二つある場合は二つのボールの間を見ることになる。

ロボビリヤードの場合はこれでは具合が悪いため、ある色のカタマリを見分ける必要がある。

この処理、パターン認識の前に対象領域の切り出しなどで行う処理に近いと思うので一般的なアルゴリズムがあるはずだと思うのだが、みつからない。エッジを見つけて領域を切り分けるとかの方法が一般的なのかな?

物体の領域の切り出しについては以前に「物体認識」として取り組んだことがあるのだが、結構面倒な処理なのだ。CDTだと1ビットデータ(ピクセル毎にあるかないか)なので綺麗に切り分けられるとは思うのだが、もっと軽い処理はないものか。。 とりあえずは自分が作った処理ルーチンをラムダに移植して使うことにしよう。すっかり忘れてしまったので自分で書いたソースをよむところからはじめなければならないが。。

 持ち帰ったラムダ(の一部) あと、スピーカーとマイクユニットがある。

このページの先頭へ