FC2ブログ

ぱぱっちの私事で恐縮ですが

ぱぱっちの日常の出来事で、何か皆さんのお役に立てそうなことがあったら、日記に書こうと思っています。

先日ホビーロボットに詳しい方々やロボゼロユーザーとお話した際に、常々の感想をぶつけてみました。
「ロボゼロのCPUボード”HSWB-04F”って処理速度が遅くない??」
大半の方が「遅いのでは」との認識でした。ただ、他のホビーロボットに使われているCPUボードとの相対比較を(主観が含まれていたとしても)実際にやった方はいなかったので、事実確認はできませんでした。

自分もロボゼロと(動かし方がわからない)ロボザックしか持っていないので比較できないので確かめようがないのですが、少なくとも「遅い」と思っている方が多い以上、それなりのプログラムの組み方を考えなければいけないと思います。

そこで仮説をもとに簡単な実験をしてみました。
<<仮説>>
1.CALL文を使うと極端に遅くなる。
2.IF文を使うと遅くなる。
3.INPUTADC文を使うと遅くなる。
※JUMP文を否定してしまうとロジックの制御ができないので、JUMP文は遅延原因から除外。

<<実験方法>>
ロボゼロをホームポジションから左腕肘だけ真っすぐ伸ばし、それから左腕を上げて、上げきったところで肘だけを元通り曲げて、最後にホームポジションに戻す。
この動作をさせる際に、腕を上げるのにかかった時間を測る。
※肘を伸ばしたり、曲げたりするのはストップウォッチで測るときに開始と終了がわかりやすいように。


<<結果>>
手動計測で10回ずつ測った平均で比較です。
遅くなる理由を何も入れないと約3.5秒に対して、
 CALL文を追加すると約1秒増える
 IF文を追加すると約0.5秒増える
 INPUTADC文を追加してもほとんど増えない。
 CALL文とIF文を同時に追加すると約1.5秒増える。

<<結論>>
CALL文はできれば使わない。(メンテナンス性は低下するけど、都度都度プログラムを書く)
IF文も可能なら使わない。(余計な判断はさせない。)
INPUTADC文はあまり影響なさそう。

ということで、次のステップとしては、CALL文をなるべく使わないプログラムの作り方を模索したいと思います。

<<テストに使ったプログラム>>
;基本形
:MOTION_START
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
MOVE(0,0,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
V00=0
:MOTION_LOOP
MOVE(0,V00,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,10)
V00=V00+10
JUMPIF(V00,<,801,MOTION_LOOP)
:MOTION_END
MOVE(0,800,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
JUMP(TEST_END)

:TEST_END


;CALL文
:MOTION_START
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
MOVE(0,0,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
V00=0
:MOTION_LOOP
MOVE(0,V00,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,10)
CALL(TEST_LOGIC)
JUMPIF(V00,<,801,MOTION_LOOP)
:MOTION_END
MOVE(0,800,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
JUMP(TEST_END)

:TEST_LOGIC
V00=V00+10
RETURN

:TEST_END

;IF文
:MOTION_START
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
MOVE(0,0,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
V00=0
:MOTION_LOOP
MOVE(0,V00,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,10)
JUMPIF(V00,<,801,TEST_LOGIC_END)
:TEST_LOGIC_END
V00=V00+10
JUMPIF(V00,<,801,MOTION_LOOP)
:MOTION_END
MOVE(0,800,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
JUMP(TEST_END)

:TEST_END

;INPUTADC文
:MOTION_START
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
MOVE(0,0,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
V00=0
:MOTION_LOOP
MOVE(0,V00,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,10)
V01=INPUTADC(1)
V00=V00+10
JUMPIF(V00,<,801,MOTION_LOOP)
:MOTION_END
MOVE(0,800,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
JUMP(TEST_END)

:TEST_END

;CALL文+IF文
:MOTION_START
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
MOVE(0,0,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
V00=0
:MOTION_LOOP
MOVE(0,V00,0,400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,10)
CALL(TEST_LOGIC)
JUMPIF(V00,<,801,MOTION_LOOP)
:MOTION_END
MOVE(0,800,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1200)
MOVE(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2400)
JUMP(TEST_END)

:TEST_LOGIC
JUMPIF(V00,<,801,TEST_LOGIC_END)
:TEST_LOGIC_END
V00=V00+10
RETURN

:TEST_END
スポンサーサイト



コメント
もしかして
はじめまして。
ロボゼロは所有していますが、未だにマイコンボードに火入れが出来ていない状態なMK84です。

これは憶測なのですが、ロボゼロのマイコンボードはルネサス社のマイコンを搭載しているはずです。(R8Cだったような気がします)
しかしながらルネサスのマイコンをプログラミングするにはHEWと呼ばれる専用ソフトが必要です。
ロボゼロの雑誌にはマイコン用のソフトが添付されていますがHEWが組み込まれているようには思えません。
導きだされる結論はロボゼロ用のプログラミングソフトはあくまでモーションデータに近いコードを吐く為のモノであり、一般的なマイコンのプログラミングとは違うような気がします。
端的に言ってしまうとインタプリタではないのかなと。
出荷状態のロボゼロボードはHEWを用いて専用のバイナリが書き込まれていますが、このバイナリはロボゼロ用のプログラムを解釈して実行するタイプなのではないでしょうか?
一般的にコンパイルしてから実行するタイプと命令を逐一解釈しながら実行するインタプリタと呼ばれるタイプがあります。
一般的には実行速度はコンパイルしたものを実行した方が速いとされています。(HEW(コンパイラ)で最適化されているから)
しかしロボゼロのプログラムはどうみてもモーションデータに条件を付けたものであるとしか思えない。
つまりコンパイル型ではないのでは?という予測です。
ただでさえ一般的なコンピュータにインタプリタな作業をさせるとものすごく遅いです。
マイコン(マイクロコントローラ)にインタプリタな実行をさせているのでモーション等で遅延が発生するのではないか?というのが私の結論です。
つまりはマイコンが遅いのではなく、「運用」方法が遅い方法を使っているのではないか?ということです。
HEWでプログラミング(この場合カスタムされたバイナリ)を使うと速いと感じるかもしれませんが当然保証外の運用だと思います。
またインタプリタで条件分岐等を使うということはマイコン内の貴重なリソース(レジスタ)を使い切る可能性があります。よってレジスタのやりくりでマイコン内はてんてこ舞い→結果的に反応が鈍い→遅いと感じる

これが私の考えた仮説です。
2014/01/15(水) 21:02:05 | URL | MK84 #ftr86F3A[ 編集 ]
この仮説は正しそうですね。
MK84さん、コメントありがとうございました。
Twitterフォローさせていただいております。
たぶんA4さんのつぶやきからお越しいただいたのですよね。お二人とも興味を持っていただけてありがたいことです。
さて、正解は中村博士しかわかりませんが、この仮説はかなりの確率で当たってそうですね。インタプリタならちょっとコードが増えるだけで劇的に遅くなるのに合点がいきます。
仮に他メーカーのボードとハード的に性能が一緒なら、他メーカーのものがコンパイル方式だったらその段階で遅いですよね。
CALL文で呼んでるサブルーチンを事前に展開するプリコンパイラもどきを作ろうと思っていたのですが、きっと「プリインタラプタ」ですね。
2014/01/16(木) 07:16:06 | URL | ぱぱっち #-[ 編集 ]
Re: この仮説は正しそうですね。
> MK84さん、コメントありがとうございました。
> Twitterフォローさせていただいております。
> たぶんA4さんのつぶやきからお越しいただいたのですよね。お二人とも興味を持っていただけてありがたいことです。
> さて、正解は中村博士しかわかりませんが、この仮説はかなりの確率で当たってそうですね。インタプリタならちょっとコードが増えるだけで劇的に遅くなるのに合点がいきます。
> 仮に他メーカーのボードとハード的に性能が一緒なら、他メーカーのものがコンパイル方式だったらその段階で遅いですよね。
> CALL文で呼んでるサブルーチンを事前に展開するプリコンパイラもどきを作ろうと思っていたのですが、きっと「プリインタラプタ」ですね。

「プリインタプリタ」でした^^;
2014/01/16(木) 07:24:55 | URL | ぱぱっち #-[ 編集 ]
コメントの投稿
URL:
本文:
パスワード:
非公開コメント: 管理者にだけ表示を許可する
 
トラックバック URL
http://go2mtfuji.blog.fc2.com/tb.php/19-d7080901
この記事にトラックバックする(FC2ブログユーザー)
トラックバック