▼終わったROBO-ONE

　今年は例年よりも時間がなかった・・・。と加工始めてから思っていたのだが。よくよく考えてみると、原因は設計の時間が長すぎた事だろう。
　下半身の設計が3回、上半身の設計が3回もやりなおしていれば、間に合わないのは当たり前。そんな訳で、レポートで8月4日まで何も出来なかったが、やはり間に合わなかったんだろう。今回のツヴァイ（※１）には悪い事をした。今まで棄権になったとしても、参加資格審査は受けられた。今回はそれもない。ごめんねツヴァイ。

　ロボット製作者に恵まれなかったら、オー○○○オー○○○・・・ゲフゲフッ

※１　2号機（※２）の「２」をドイツ語読みにしただけ。（Zwei）
※２　今までの5号機までは「試作」を付けていたが、歩けるまで試作を付けようと考えていたので、歩けるようになった現在は、その試作を取り去り、2号機になったのである。今後は3号機、4号機となっていく事になる。

▼さて、予選会場にツヴァイは居たのか？

　実は試作5号機の上半身とともに、控え室入り口にこんな感じで眠っておりました。もし、片足だけのロボットを見かけたなと思ったら、たぶんそれはコイツです。
　参加者の方からも尋ねられました。なぜ片足しかないのか、もう片足はどうなったのか。答えはこれが現状での完成形なんです。(T▽T)両足がついた形は、脳内で反転させて両足にしてください。＞ぉぃ
　で、コクピットがないのは、予選前日に分解して置いておいたはずのコクピットカバーが、朝になったら行方不明になっていたんです。悲しい・・・。とりあえず作り直し確定です。

▼今後の予定は・・・？

・ハードを完成させる。（Wegweiser Zwei α）
・ソフトを完成させる。
・動かす。
・センサー（ジャイロ）を使って動かす。
・センサーを増設（加速度、側距、デジタルコンパス）
・増設したセンサーで遊ぶ。
・攻撃力を増強する。（Wegweiser Zwei β）

　最後の攻撃力ってのは、腕の力が弱いので、それを補う何かです。まぁ、来年の冬を狙ったものですね。それでも予選突破しなければ意味がありませんが。とりあえず、目標は今までの予選突破から、本戦のデモと戦闘でいい結果を残すってことにします。

さぁ、がんばろう。

　でも、これだけで夏が終わりそう・・・というか、これらを終わらせられるのだろうか・・・。完成したら、ロボット王国で模擬戦がやりたいなぁ・・・あとは王様の許可が降りるか次第ですが。(＾-＾；

▼ROBO-ONEのその後

　今回は、珍しく3日連続アルコール漬けだった。内訳（土曜日の懇親会、日曜日の打ち上げ、月曜日のサークルの飲み会）今週サークルの先輩（OB）の松田さんが、帰省されているので、じゃあ久々に飲み会をやろうと急遽決まり、秋葉原で17時から開始しました。

　そんな訳で、火曜日はそれらの反動で、ボロボロに。（笑）水曜日はパスポートが切れていたので、申請しに行ったりしてました。なかなか時間が取れないですね。そんな中でも少しずつ進めています。

　今行っているのはII（ツヴァイ）のソフトを作成していることです。前回バグだらけで、最終的には動作不能に陥ったので、作り直しています。とは言っても、元のデータは残っているので、無駄な関数を簡素化したり、機能を増やしたりと言った作業が中心になっています。

▼EEP-ROM

　前回の時点で、EEP-ROMが使用可能になったので、今回もこれを使って行こうと考えています。今までは、モーション作成　⇒　ハイパーターミナルに出力　⇒　出力されたものをプログラムに貼り付け　⇒　プログラムをコンパイル　⇒　動作確認（ながっ）

　という面倒な手順を行っていたのですが、EEPROMの登場で一転。モーション作成　⇒　EEPROMに保存　⇒　動作確認 　と、かなり早くなりました。EEPROMも256KBitを1MBitに変更したので、容量も4倍になったので容量をあまり気にせず自由に使えそうです。前回は搭載したのが、後半辺りだったので、モーション程度しか保存できなかったのですが、今回はまた修正して作り直しているので、色々とデータを保存する予定です。

保存予定のデータ

1. ロボットのホームポジション
2. H8のポートと送る信号の割り当て
3. ロボットのモーション
4. モーションとコマンドの割り当て

　前回の失敗を教訓に、今回は色々と保険をかけています。2番目もその一つで、ポートが死んでしまった場合配線をハンダ付けしなおして、ポートの設定を変更しなければならないのですが、コンパイルし直すと時間がかかります。そこで、EEPROMに保存してデータの変更をしやすくした訳です。

　まぁ、ポートが壊れるなんてことは起こらないに越した事はないんですけどね。（^-^；

▼バックパックの光るヤツ

　今回は背中のモニターLEDを紹介しようと思います。このLEDは秋月で10個100円で売っているチップLEDです。マイコンから信号線を引っ張ってきて、片方をLEDに、もう片方をRCサーボの信号線へ接続しています。

余談ですが、チップLEDなどのチップ部品に1608サイズとかいう言葉が出てきて、今まで謎だったのですが、どうやら縦と横のサイズの事らしいですね。（1608　⇒　1.6mm × 0.8mm）

　さて、このLEDは何の役に立つのかというと、プログラム実行時の信号の出力を視認できる事です。自分は信号の出力をH8に元からある機能の一つ、DMACというものを利用して、大量のRCサーボ用の信号を発生しています。故に、プログラムにミスがあるとRCサーボの破損という事態に陥ってしまいます。
　そして、今回このLEDが威力を発揮しました。その詳細をここに記録しておきます。

▼バックパックの光るヤツ　〜詳細〜

　今回は、RCサーボのモーション再生プログラムを作成したのですが、プログラム完成後RCサーボを動かすと、動きがおかしかったので、RCサーボの電源供給を止めて、LEDに注目するとLEDが一瞬フラッシュしたような現象が起き、さらに角度を変化させているLEDが暗くなって行くのが分かりました。

　これらだけでは、情報が足りないので、各データを収集してみた所、原因はパルス発生時のパルス幅と、角度がおかしかったことが分かりました。右のグラフはパルス幅についてのグラフです。

　グラフだけ見ても分からないので説明を加えます。まず2秒間90°のまま保持します。その後2秒間かけて角度を135°に変化させ、2秒間停止、残りの2秒間で90°に戻すという単純な動作です。しかし実際は違ったのです。

簡略化すると

時間	2秒間	2秒間	2秒間	2秒間
予定	90°	90°⇒　135°	135°	135°⇒　90°
実際	90°	90°⇒　-120°	-120°	-120°⇒　90°

　左に、その実際の角度を示します。さて、なぜ角度が135°にならずに-120という通常では考えられない値に変化してしまったのでしょうか？

　プログラムをやっていて勘の良い方は、もう気づいているかもしれません。アレです。この角度を格納する変数はint型ではなく、char型を使用しています。と言うのも、EEPROMが1バイトだからというのもあるんですが、この「char」を「unsigned char」としていなかったがために起こったトラブルだったんです。いわゆる オーバーフローってヤツです。

　C言語では「unsigned char」にすると-128〜127という範囲が、負の領域も全て正の領域として扱えるので、0〜255まで使用できます。と言う事は、135°って「unsigned char」じゃないから127超えてるよね。越えたらどうなるか、-128からどんどん増えていくことになります。よって、135-127=8でこの8を足すと-120になり、実際の値と一致します。そんな訳で、変数の指定を「unsigned char」に直したら、問題なく動作しました。

　左の動画は、オーバーフローという欠陥を持った時に動作させた動画を載せています。 動画を載せていますが、フラッシュしているように全く見えません。デジタルカメラでは 捉え切れないようです。(T▽T) 　フラッシュは分かりませんが、一つのLEDが暗くなっていく現象は確認できると思いま す。右から3番目のLEDです。グラフ１に示したとおり、のパルス幅になっていくので、 最初に暗くなっていき、明るさが元に戻る瞬間にフラッシュしています。 　ソフトをやっているとなかなか更新するネタがないので、載せてみました。(^-^； たぶん、他の方には役に立たない情報かも・・・。まぁ、オーバーフローには気をつけましょうということで。

▼EEP-ROM　〜参考文献ならぬ参考WEB〜

　思い立ったが吉日のいしかわさんからリクエストがあったので、自分が参考にしたサイトと、参考になると思われるサイトを掲載しておきます。（BBSが消えても、これは残るので・・・・）

・Flight Feather
H8講座⇒TIPS（シリアルEEPROM）
http://www008.upp.so-net.ne.jp/funfly/

・電子工作実験室
PICの活用⇒PIC18シリーズ（I2C通信の使い方）⇒EEPROMの使い方とCの関数
http://www.picfun.com/

・Miyata's Robot Factory
お手軽ロボット制御システム製作プロジェクト
「Little Burning Core」⇒ I2CとEEPROMとXMODEM

http://www.geocities.jp/mimiin/

・SISO　JUNK　STUDIO
SISO-LAB⇒Knowledge⇒I2C EEPROM 24LC256をAKI-H8/3664へ接続
http://cgi.f16.aaacafe.ne.jp/~siso/index.php

　私がEEPROMを使初めて使用したときは、Flight Featherのソースプログラムを使用させて頂きました。動くはずなのに、あろう事か、SDAとSCLに接続する端子（H8）を逆に取り付けてしまったため、動かせるようになるまで時間がかかりましたが、動けば簡単なものです。あとは電子工作実験室を参考にしてプログラムを強化しました。

　EEPROMはXMODEMも合わせて習得されると、保険ができるので信頼性がUPします。

それでは、今日はこの辺で・・・。

▼今日一日

　母親が日本へ転勤してきたドイツ人のための情報紙をボランティアグループで書いているのですが、その原稿の締め切りが、明日なので、その編集作業やら何やらで付き合わされる。

　朝方にデータをCD-ROMに焼いて、渡して、そのままダウン。その後、編集作業に付き合う。なんか時間がないが、その中でまた余計な事に気を取られてしまう。それが、ベジェ曲線である。

▼べじぇさんとの出会い

　元々、モーションの動きを今までは線形、Sin曲線、Cos曲線のいずれかの形で行ってきた。それらを分割し、20msecごとに1分割動かす事で、スムーズに動かしてきたのです。で、今回やろうとしたのがSin曲線、Cos曲線を２モーションで共通化できないかという事でした。

　例えば、手を振るモーションを考えてみましょう。普通ならば１モーションで済み、問題はありません。しかし、それを１モーション増やし、肘を曲げるというモーションを追加したとします。そうすると、手は１モーションの時と同じように振ろうとしても、それはSin曲線だけで連続で動かす事が出来ず、ギクシャクしてしまいます。（Sin、Sin）

　Sin曲線⇒Cos曲線とすれば、スムーズに動きますが、Sin曲線単体の時と違う動きになってしまいます。これをなんとかしたかったんですね。私は・・・。で、色々と試したのですが、うまく行かず、そこで頭に浮かんだのがベジェ曲線。さっそくそれについて調べてみた・・・というのがいきさつです。

▼べじぇさんを描く

　先程書いた通り、モーションの動きを今までは線形、Sin曲線、Cos曲線のいずれかの形で行ってきたのですが、どうもしっくりこない。そこで、曲線と言えばベジェ曲線かな？と思いさっそく調べてみた。そして、数式を入手。

x=(1-t)³x₁+3(1-t)²tx₂+3(1-t)t²x₃+t³x₄
y=(1-t)³y₁+3(1-t)²ty₂+3(1-t)t²y₃+t³y₄
0≦t≦1

　以上の3式がベジェ曲線を作成するために必要な数式である。これらの数式を元にEXCELでグラフを描いてみた結果が左の図である。モーションはグラフのように連続しているから、端点を３つにして描いてみた。端点から伸びる方向線の長さと傾きで曲線は様々な形に変化してしまうので、もはやハイパーターミナルで数字を表示しているだけでは、どうにもならないのである。少なくとも現時点の私には、その術を知らない。

　現時点の私には、モーションエディター（Windows版）でも作らない限り、ベジェ曲線の修正は不可能だと思う。それには、また他の技術がいるだろう。と言う訳で、今回は実装を見送らざる終えない。魅力的なんだけどなぁ・・・。どなたか良い方法ありませんでしょうか？（^−^；　←他力本願

　もしも、実装するならばある程度条件を固定すればなんとかなるかもしれない。恐らく方向線の向きや長さに関する情報がキーポイントなのだろう。どの道、今は他にもやらねばならぬ事があるので、しばらく保留にするしかない。何かがきっかけで、道が開けるといいのだが・・・何かがきっかけで・・・。

▼ベジェ曲線　〜参考WEB〜

GOOGLE検索「検索文字」：　ベジェ曲線

・武蔵システム
フォント入門⇒ベジェ曲線

　一件だけですが、何とかベジェ曲線と言うものは描けたので、これだけしか調べてないです。本当に理解したか？と聞かれると、非常に怪しいですが・・・（^−^；

　まぁ、何はともあれ、動かす事が最優先です。その過程でうまい方法が思いつけば、それを試せば言い訳で、しばらく煮込んで見ることにします。胴体だけあれば、プログラムのデバッグ、動作確認が済んでしまうので、ロボットはアレから組みあがってないですね。

　とりあえず、ロボットのプログラムが済み、一通りモーションができ、余裕ができればそろそろハイパーターミナルを卒業して、モーションエディタ作って見たいですね。余談でした。