アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
キュー投入のタイミング (スコア:1)
モーション実行中の次モーションのキュー投入タイミングの件です。
Aの実行を指示された直後にBの実行を指示された場合、Aの実行時間が比較的長め（数秒単位）の時、A→Bと連続投入してしまうと、Aの再生中に生じた状況変化に対応できなくなってしまいます（Bもそのまま再生されてしまう。）。
また、間違えていろんなボタンをどんどん押しちゃうとそれらが全て再生されるまで待ちになってしまいます。
前進ボタン押しっぱなしでオートリピートで歩行する場合にも必要以上にキューに溜まっちゃうのも問題かと。
対策として私の場合は、Aの再生残時間が残り0.2秒になるまで次のコマンドは受け付けないようにしています。
Aの再生残が0.2秒分になった時点で、Bを発動するボタンが押されていれば、Aの残データの後に繋いでBを投入するような感じです。
もしA再生開始直後にBのボタンが押されていても、残0.2秒時までに放していれば、Bのコマンドは受け付けません。
釈迦に説法かとは思いますが、ご参考まで。
Re:キュー投入のタイミング (スコア:1)
ご指摘の通り、どんどんキューイングしてしまうと困ったことになりますよね。
なので「キューに入ってるのを全部クリア！」っていうキャンセルコマンドも作ります。
いずみかわさんが実装されている「今のモーションの終わりに近付かないと次のコマンドを読み込まない」というのも便利そうなので拝借したいと思います。
ユーザーからの入力はシェルが読み込んでコマンドインタプリタの該当する機能を呼び出すようになっています。
コマンドインタプリタはサーボ制御周期(20msec)と同期して20msecに一ステップを処理します。
シェルはインタプリタとは独立して動いており、インタプリタがモーションデータを再生中でも自由にコマンド入力を処理できます。
(以下、鋭意実装中の機能の概要)
シェルは「モーションデータ再生コマンド」を受け取るとインタプリタの「モーション再生開始処理」を呼び出します。
インタプリタがアイドル状態であれば、即座にモーション再生を開始、他のコマンドを実行している場合は、要求されたモーション名を「コマンドキュー」(というよりも「再生データキュー」？)に投入します。
インタプリタはモーション再生が終わるたびに「コマンドキュー」をチェックし、再生待ちのモーションがあればそれを再生、なければアイドル状態となります。
シェルが読み込んだ命令が「コマンドキャンセル」だった場合は、コマンドインタプリタの「コマンドキュークリア処理」を呼び出します。
インタプリタは「コマンドキュー」をクリアし、現在再生中のモーションデータが終了するとアイドル状態になります。
という実装になる…予定です。
コマンドキャンセルは、バーチャロンのように両側のスティックを内側に倒す…のかな。
あと、今後追加する機能として、モーションデータ側に「割り込み許可／不許可」命令を入れようと思っています。
「コマンドキャンセル」の場合にキューのクリアだけではなく、再生中のモーションも途中で止められるようにしようかと。
…まだ夢の夢ですけど(汗
Re:キュー投入のタイミング (スコア:0)
Re:キュー投入のタイミング (スコア:1)
ようやくSISOさんからコメントをいただけるような状態になりました。
これからコマンドインタプリタにどんどん機能を追加していこうと思っています。
「モーションデータ」は「データ」と呼んでいますが実体はコマンドの羅列です。
(今は関節角指示コマンドしかありませんが)
制御コマンド＋データ属性(実行時条件や実行後の姿勢情報、他コマンドとの連携情報等)を入れようと思っています。
属性の「実行時条件」がAction Scriptの「実行レベル」に近いかもしれません。
早く実機を動かせるようにしたいです。(苦笑
Re:キュー投入のタイミング (スコア:1)
来ると思ってました（笑）。
SISOさんの構成はOS実装っぽいなと思ってたら、人形つかいさんもやはりそのようなイメージのようですね。
ウチの場合は、モーション投入時に補間データを展開してその補間データをFIFOに投入します。
そのFIFOが残り0.2秒分(20ms*10コマ分)以下になると次のコマンド受け付けを行うのは先に述べた通り。
FIFOバッファの管理用のメソッドは、FIFO投入とクリア、それと先頭データの取り出しだけですね。
処理用のプロセスはそれを先頭から順番に食っていく感じ。
あと、それとは別にサーボ毎の上書き用バッファがあって、そこにデータを投入すると、FIFOからデータを取り出す際にその値で上書きします。
アナログジョイスティックでやってたプチマスタースレーブはこの機能を使っています。
モーション間の優先順位は特になく、アプリ側で制御してます。
＃私なりの新型コタツトップマシン出来ました。
アスリート3000で18秒だったので、まずまずの結果です。
Re:キュー投入のタイミング (スコア:1)
> 人形つかいさんもやはりそのようなイメージのようですね。
他に思いつく方法がなくて…
Windows 3.1のイベントキュー管理がこんな感じだったと思います。
> ウチの場合は、モーション投入時に補間データを展開して
そうですね…補間データの展開領域と処理方法も考えなきゃですね…(汗
今は、Linuxの広大なメモリ(と言っても8M)を贅沢に使っていて、補間後のデータを保持しています。
(もともと歩行シミュレータで20msec単位に生成しているので「補間」とは呼ばないかも)
歩行とは関係ないモーションを作り始めたら自動補間機能がないと辛そうです。
サーボ制御角の直値上書きは、shell側のコマンドに持っています。
コマンドインタプリタに「一時停止」コマンドを送って、その後インタプリタを飛ばして角度データ保持領域を書き換えています。
色々アイデアは湧くのですけど実装が追い付きません。(笑
> ＃私なりの新型コタツトップマシン出来ました。
スーパーヒロムロボとは別のマシンですか？？
ヒロムロボの「パッシブロール軸制御」面白いですね。私も作ってみたいです。
Re:キュー投入のタイミング (スコア:0)
ヒロムロボのことなので同じです。
脚を延ばしてリポ化したものがスーパーヒロムロボとなります。
>ヒロムロボの「パッシブロール軸制御」面白いですね。私も作ってみたいです。
思ってたよりうまくいきましたね
スプリング設定の試行錯誤も、「最適解」ではないかもしれませんが「満足解」はすぐに得られました。
「計算」とは縁遠いですけど。