ロボットコミュニケーションの練習会
中部地区の練習会が４月３０日に行われます。
主催はロボットコミュニケーションです。
もちろん私も参加します。
「ロボプロ競技会in私のしごと館(仮称)」大会に向けて高速化された（と言うほどのものではないが・・・）コーネリアスを披露しに行きます。
ロボプロのほうは５／３のみ参加する予定です。実はまだ未定だったりします。ちょっと満足行く歩行に程遠いもので・・・
で、ロボットコミュニケーションの練習会場所ですが、私の家からだと、車で行くなら大同大学とほとんど変わらないぐらいの距離かな。でも私は車を持っていないので、行くならバイクかな・・・。リュックにロボとパソコン背負って行くのも、無理じゃない。ツーリングの季節だしね。
本日、ロボットを触っていてたまたま発見した事があります。
私的にはものすごいショックを受けた発見です。
私のロボットにはJRのDSR581を使用しているのですが、そのDSR581のサーボケースを開けた状態で通電を行いました。
ギア部分のケースも外してある状態だと、ポテンショメータが動かないため、モーターはがんばって目的位置まで行こうと回り続けます。まあ、当然の動作ですね。
その状態でポテンショメータを手で回し、目的位置まで回すと、モーターは止まります。まあ、当然の動作ですね。
ショックだったのは、目的位置あたりにポテンショメータが近づいたときのモータの動きなのですが、だんだん回転速度が落ちるのです。
目的位置まで９０度ぐらい離れていると、モータはひゅんひゅん回っているのですが、１０度ぐらいになると、ひゅるひゅるって感じでゆっくり回り、３度ぐらいではひょろひょろって感じ。
おい！・・・
なんとなくこの動きの言わんとするところは理解できるのですが、こんな動作をされてしまうと、サーボの位置制御を細かく行えば行うほど、サーボの動作スピードは遅くなる理屈です。
早いロボットを作りたくて、0.11s/60度のDSR581を選んだのにこれじゃあ性能を使い切っていないし、性能を使い切る方法が思い浮かばない・・・。
どこの、どのサーボでも、おなじ仕組みなのだろうか・・・
主催はロボットコミュニケーションです。
もちろん私も参加します。
「ロボプロ競技会in私のしごと館(仮称)」大会に向けて高速化された（と言うほどのものではないが・・・）コーネリアスを披露しに行きます。
ロボプロのほうは５／３のみ参加する予定です。実はまだ未定だったりします。ちょっと満足行く歩行に程遠いもので・・・
で、ロボットコミュニケーションの練習会場所ですが、私の家からだと、車で行くなら大同大学とほとんど変わらないぐらいの距離かな。でも私は車を持っていないので、行くならバイクかな・・・。リュックにロボとパソコン背負って行くのも、無理じゃない。ツーリングの季節だしね。
本日、ロボットを触っていてたまたま発見した事があります。
私的にはものすごいショックを受けた発見です。
私のロボットにはJRのDSR581を使用しているのですが、そのDSR581のサーボケースを開けた状態で通電を行いました。
ギア部分のケースも外してある状態だと、ポテンショメータが動かないため、モーターはがんばって目的位置まで行こうと回り続けます。まあ、当然の動作ですね。
その状態でポテンショメータを手で回し、目的位置まで回すと、モーターは止まります。まあ、当然の動作ですね。
ショックだったのは、目的位置あたりにポテンショメータが近づいたときのモータの動きなのですが、だんだん回転速度が落ちるのです。
目的位置まで９０度ぐらい離れていると、モータはひゅんひゅん回っているのですが、１０度ぐらいになると、ひゅるひゅるって感じでゆっくり回り、３度ぐらいではひょろひょろって感じ。
おい！・・・
なんとなくこの動きの言わんとするところは理解できるのですが、こんな動作をされてしまうと、サーボの位置制御を細かく行えば行うほど、サーボの動作スピードは遅くなる理屈です。
早いロボットを作りたくて、0.11s/60度のDSR581を選んだのにこれじゃあ性能を使い切っていないし、性能を使い切る方法が思い浮かばない・・・。
どこの、どのサーボでも、おなじ仕組みなのだろうか・・・
逆運動学計算完成
逆運動学計算が完成しました。
しょーもない動画ですがUPしてみました。
逆運動学の動画（2.3M)
後方から前方に逆運動学でうごかして、
前方から後方に角度均等割りでうごかしている動画です。
後方に足があるときの膝サーボの角度と
前方に足があるときの膝サーボの角度が
ほぼ同じため、角度均等割り制御だと、足が動いているときは膝サーボは動いていないのです。
前回の日記で、ACOSの精度の低い領域があるため足の動きの精度が低いと書きました。その後わかったのですが、さらにルート計算の精度も低くかったです。
変数の浮動小数点型をやめたために、ルート計算時に精度が出ていなかったのです。
これをまた浮動小数点型にすれば精度は回復ですが、処理速度が追いつきませんでした。
で、結局、ルート計算をやめ（減らし）て、ATANを使用しました。
ACOSのテーブル２つとATANのテーブル１つを作成しました。
精度は0.5度単位です。
それなりの精度で逆運動学計算ができるようになったのですが、実際に動かしてみるとサーボトルクが低いためにうまいこと機能（保持）してくれません。特にヨー軸。（涙）
そんなこともあって、こんなんでOKかなって感じ・・・
さて、次はパラメータによる歩行に挑戦です。
しょーもない動画ですがUPしてみました。
逆運動学の動画（2.3M)
後方から前方に逆運動学でうごかして、
前方から後方に角度均等割りでうごかしている動画です。
後方に足があるときの膝サーボの角度と
前方に足があるときの膝サーボの角度が
ほぼ同じため、角度均等割り制御だと、足が動いているときは膝サーボは動いていないのです。
前回の日記で、ACOSの精度の低い領域があるため足の動きの精度が低いと書きました。その後わかったのですが、さらにルート計算の精度も低くかったです。
変数の浮動小数点型をやめたために、ルート計算時に精度が出ていなかったのです。
これをまた浮動小数点型にすれば精度は回復ですが、処理速度が追いつきませんでした。
で、結局、ルート計算をやめ（減らし）て、ATANを使用しました。
ACOSのテーブル２つとATANのテーブル１つを作成しました。
精度は0.5度単位です。
それなりの精度で逆運動学計算ができるようになったのですが、実際に動かしてみるとサーボトルクが低いためにうまいこと機能（保持）してくれません。特にヨー軸。（涙）
そんなこともあって、こんなんでOKかなって感じ・・・
さて、次はパラメータによる歩行に挑戦です。
ATmega128の計算速度 その２
やったー、やったー。
ロボットに搭載しているATmega128によるリアルタイム逆運動学計算ができました。
当初、アークコサインの計算に1400μsほど処理時間が必要だったのですが、テーブルによる高速化で140μs程度まで高速化できました。
（両足でアークコサインの計算は６回必要なので、効果は大きいです）
さらに、ATmega128が不得意そうな、浮動小数点型の変数をなくし、PWM制御中にも計算処理を分散させることで、リアルタイムでの逆運動学計算ができました。
わーい、わーい。われながらあっぱれ。笑。
・・・とは、いきませんでした。
実はアークコサインの計算ロジックが使用に耐えられないぐらい精度が低かったのです・・・
プログラムはこんな感じです。
unsigned char m_ucAcos[] =
{90,89,89,88,88,87,87,86,85,85,
84,84,83,83,82,81,81,80,80,79,
78,78,77,77,76,76,75,74,74,73,
73,72,71,71,70,70,69,68,68,67,
66,66,65,65,64,63,63,62,61,61,
60,59,59,58,57,57,56,55,55,54,
53,52,52,51,50,49,49,48,47,46,
46,45,44,43,42,41,41,40,39,38,
37,36,35,34,33,32,31,30,28,27,
26,24,23,22,20,18,16,14,11,8,
0} ;
と、角度を返すテーブルを用意しておいて、
角度 = m_ucAcos[sA / sB * 100] ;
とするだけ。ｓAとｓBは辺の長さで、＊１００にて配列のインデックスに使える値にしています。
（本当は”sA / sB * 100”じゃなくて”sA * 100 / sB”にしています）
問題点は、配列の値をみると良くわかるのですが、増加率がだいぶ違います。インデックスの100に近いほうだと角度の差が大きいですよね。
このへんは、体に近いあたりで足を動かしたときに使用する領域です。とっても大切な領域だったのでした・・・
なので、現時点では足を体から離せば離すほど綺麗に動作します。無意味・・・
計算処理で補間を行うか、テーブルを２，３パターン用意して領域ごとに切り替えるかして精度をあげようと思います。
テーブルの値の単位も１度じゃなくて、0.1度ぐらいにしたほうが良いのかな・・・
でもだいぶやる気がでてきました！
ロボットに搭載しているATmega128によるリアルタイム逆運動学計算ができました。
当初、アークコサインの計算に1400μsほど処理時間が必要だったのですが、テーブルによる高速化で140μs程度まで高速化できました。
（両足でアークコサインの計算は６回必要なので、効果は大きいです）
さらに、ATmega128が不得意そうな、浮動小数点型の変数をなくし、PWM制御中にも計算処理を分散させることで、リアルタイムでの逆運動学計算ができました。
わーい、わーい。われながらあっぱれ。笑。
・・・とは、いきませんでした。
実はアークコサインの計算ロジックが使用に耐えられないぐらい精度が低かったのです・・・
プログラムはこんな感じです。
unsigned char m_ucAcos[] =
{90,89,89,88,88,87,87,86,85,85,
84,84,83,83,82,81,81,80,80,79,
78,78,77,77,76,76,75,74,74,73,
73,72,71,71,70,70,69,68,68,67,
66,66,65,65,64,63,63,62,61,61,
60,59,59,58,57,57,56,55,55,54,
53,52,52,51,50,49,49,48,47,46,
46,45,44,43,42,41,41,40,39,38,
37,36,35,34,33,32,31,30,28,27,
26,24,23,22,20,18,16,14,11,8,
0} ;
と、角度を返すテーブルを用意しておいて、
角度 = m_ucAcos[sA / sB * 100] ;
とするだけ。ｓAとｓBは辺の長さで、＊１００にて配列のインデックスに使える値にしています。
（本当は”sA / sB * 100”じゃなくて”sA * 100 / sB”にしています）
問題点は、配列の値をみると良くわかるのですが、増加率がだいぶ違います。インデックスの100に近いほうだと角度の差が大きいですよね。
このへんは、体に近いあたりで足を動かしたときに使用する領域です。とっても大切な領域だったのでした・・・
なので、現時点では足を体から離せば離すほど綺麗に動作します。無意味・・・
計算処理で補間を行うか、テーブルを２，３パターン用意して領域ごとに切り替えるかして精度をあげようと思います。
テーブルの値の単位も１度じゃなくて、0.1度ぐらいにしたほうが良いのかな・・・
でもだいぶやる気がでてきました！
ATmega128の計算速度
逆運動学計算をATmega128でやらせようとしているのですが、意外と四苦八苦しております。
私のロジックではアークコサインを片足３回ぐらい実行する必要があるのですが、１回のアークコサイン実行で、なんと1600μs近く処理時間がかかるのです・・・涙
（I/OポートをON/OFFさせて、オシロで計測しています）
全部含めて2400μsぐらいにまとめないといけないのに、アークコサイン一回で1600μsでは絶望的です。
簡易的なアークコサイン関数を自作するしかないのかな・・・
ずいぶん前にSISOさんがATmega128の計算速度を計測したレポートをUPしてくれていたのを思い出したので、さっそく私の環境でもやってみました。
アークタンジェントを計測したら、１３秒。
１３秒÷２００００＝６５０μｓ
あれれ、SISOさんと結果がちがう？？？
なにが要因だろうか？コンパイルオプション？
それにしてもアークコサインはアークタンジェントよりも遅いみたいだ。ざんねん・・・。
私のロジックではアークコサインを片足３回ぐらい実行する必要があるのですが、１回のアークコサイン実行で、なんと1600μs近く処理時間がかかるのです・・・涙
（I/OポートをON/OFFさせて、オシロで計測しています）
全部含めて2400μsぐらいにまとめないといけないのに、アークコサイン一回で1600μsでは絶望的です。
簡易的なアークコサイン関数を自作するしかないのかな・・・
ずいぶん前にSISOさんがATmega128の計算速度を計測したレポートをUPしてくれていたのを思い出したので、さっそく私の環境でもやってみました。
アークタンジェントを計測したら、１３秒。
１３秒÷２００００＝６５０μｓ
あれれ、SISOさんと結果がちがう？？？
なにが要因だろうか？コンパイルオプション？
それにしてもアークコサインはアークタンジェントよりも遅いみたいだ。ざんねん・・・。
