コードレビュー/2011年3月 をテンプレートにして作成
開始行:
[[開発者向け情報>devel]]
~
* 2011年3月 コードレビュー [#fad62255]
** Framework [#uf6736d3]
*** MultiRateHapticを実現するためのFWの実装の現状 [#u1f8c608]
- クラス図
-- http://haselab.net/intra/haselab_wiki_before2010/index.php?plugin=attach&pcmd=open&file=FWApp_interaction.png&refer=%BF%DC%BA%B4%A4%CE%B8%A6%B5%E6%A5%CE%A1%BC%A5%C8
- glutIdleFuncに登録した関数内でPhysicsのステップが動く
- MultiMediaTimerに登録したTimerFunc内でHapticLoopが呼ばれる
- MMTimerからidleFuncに同期命令を飛ばす
-- MMTimerで走っている物体の位置と速度をglutIdleの方に代入するような感じ
- FWInteractScene
-- FWApp側からMMTimerで走っている力覚系のオブジェクト群にアクセスするためのもの
-- FWSceneを持っている
-- InteractPointerやInteractSolidを保持する
-- FWInteractSceneのStep : 前後にいろいろ追加処理をしたうえで内部でFWSceneのステップを呼ぶ
-- FWInteractAdaptee（＝実装はFWLDHapticなど）のStepで，モビリティ行列の計算など物理ステップからの同期の処理をする
- 本物のFWSceneはFWInteractSceneが持っている
- LocalのSceneは独自実装
*** Timer問題 [#tdfd4f4a]
- CreateTimerの戻り値をint（id）ではなくオブジェクトにしたほうがいいのでは
-- UTTimerIfを返して，そこからintervalの設定等を行えるようにしたほうがよいのでは？
-- FWAppがtimerを持っている理由は？
--- ユーザがFWApp以外のオブジェクトをCreateするのもおかしい
--- FWApp::Initの中でTimer作成をやってしまう（値等も適当に入れる．デフォルト処理）
- tazzさんがFoundation/UTTimerをしっかり実装しなおしてコミット待ち中，上記について見直した上でコミット予定
-- → FWTimerはなくす予定
*** Physics周辺 [#tdfd4f4a]
- PHContactDetectorに市民権を与える
-- 当たり判定情報をユーザにも開発者にも利用しやすい形で整備してインタフェースを公開
- 力覚専用の物理演算機能
-- FrameworkからPhysicsへ移すか検討．Physicsにおくならある程度の汎用性が必要
*** モジュールを分ける話 [#bf2a8f3e]
- FWの立ち位置とは？
-- PhysicsとGraphicsをつなげるもの？
-- HIはHapticのみならずキーボードやマウスを含むヒューマンインターフェース全般？
- FWの各機能をバラして他のライブラリに入れ，FWはできるだけ薄っぺらくしたほうがいいのではないか
-- Local DynamicsのInteractPointer等はHumanInterfaceへ
-- Local Dynamicsのモビリティ行列計算等はPhysicsへ
-- マウスでつかむのはHumanInterfaceへ
-- マウスで視点変更はGraphicsへ
-- ...etc.
- ...できるの？
-- Local Dynamicsの計算はPHの計算をあこちで利用しながら行われている．ばらすことは可能だろうか
-- ''↓以下で検討開始''
- アクセレランスの計算は汎用化できるのではないか
-- 現在のアクセレランスの計算はFWLDHaptic3Dの中
-- アクセレランス行列の計算のようなものは制御にも使える
--- LDHapticのアクセレランスは力に対する加速度の行列，軌道追従制御で使うのはトルクに対する加速度の行列
--- 軌道追従制御のは関節トルクの次元数がとても大きくなる場合もある．
-- → 自由度nを渡すとn回テストシミュレーションを行って行列を返してくれる機能をPhysics(PHScene)につけるべきだろう
--- （PHSceneにアイランド機能が付いた暁には，アイランドごとに付けるべき機能．）
- （ちなみに今までモビリティと呼ばれていたものは実はアクセレランス：http://www.onosokki.co.jp/HP-WK/eMM_back/04_07_22add.htm）
- ポインタに一番近い物体の探索はどこに実装すべきか
-- 参考：PHRay : 直線上の最初にある物体を見つける機能
--- CDShape::LineIntersect : 直線に関して交差するかを調べ，交差する場合交差する点を返す
--- 同様に，点から最近傍の物体を探す機能をCDShapeに付けてもいいのでは？
-- そもそも何故CDに入ってないのか？
--- solidPairを持ってるのがPHだから
--- PHContactDetectorがsolidPairや物体のソート結果を持っている ： 利用出来るようにするにはどうすれば？
--- ・ContactDetectorはテンプレートになってて一般ユーザからは使いづらい
--- ・・ なぜテンプレート？ → forLCPかforPenaltyかによってPairに持たせるべき情報が全く違うので．
-- 近傍物体の探索にはPairは要らないのでは？
--- それでもsolidPairが使いたい場合はある ： クリーチャにおいて接触対象の剛体を知りたい場合とか
-- → SolidPair， ShapePairの基本クラスを作ってそれが外から見られるようにするべき
--- それができるとContactDetectorをテンプレートではなくせるか？→まだわからない．書いてみてうまくいったら開示
-- PHSceneインタフェースを持つのが良いのではないか。
- ↑以上の機能の移行が行われれば，FWにおけるLocal Dynamicsの処理はPHのAPIを呼び出すだけで済むようになるはず
- フレームワークがPhysicsとHumanInterfaceの橋渡しを行っている，という考え方には問題がなさそう．
-- この立場は今のまま，現在FW内部にある実装のうち共通で使える機能はどんどん他のライブラリに移転していく．
- MMTimerで動いているLocal Dynamicsのシミュレーションはどこへ・・・？
-- ポインタの侵入量から力を算出して出力するような処理を行っている
--- つまりHaptic Renderer なので HumanInterface に入れるべき？
--- ・Graphic RendererがGraphicにあるように．
--- IASolidはPHSolidに依存している（これは速度の観点から避けられない）．
--- ・これをHIに入れるとHIがPHに依存してしまうので避けるべき．
--- ・Physicsに入れるべき？
- 剛体を操作するための機能等はPhysicsにいれてしまうべき
-- Physicsの剛体にハンドルを付ける ＋ HumanInterfaceで位置の入力等が行われる ＋ FWが位置を剛体のハンドルに反映させる
-- これらはマウスで剛体の位置を動かす機能や，ARアプリでカメラから剛体の位置を動かす場合等にも共通する処理．
-- → PHPointer
*** 命名問題 [#ea069cda]
- Adapter？
-- Adapterパターンは既存のクラスに覆いかぶさって見た目を変えるもの．
-- Observerパターンはメッセージを待ち受けるという印象が強い．
-- Bridgeパターン ： 実装を分離するパターン．AbstractionとImplementer．これか？
--- Implementerは長い・・・が，Implだと将来 If をやめて Impl にしようと思ったときかぶるかも．
--- ''Handler'' とも呼ばれる．''←これで！''
*** FWAppInfoの整理 [#ea2c1fb4]
''（このへんに関してはtazzさんお願いします）''
- FWVFuncBridge
-- RubyでFWAppを継承したクラスを作った時に仮想関数が呼ばれるようにするためのもの
-- → そういう場合はRuby上でFWAppを書いたほうが早い．不要．
- FWWin
-- Ifでないのはなぜ？
--- → Vec3等と同じ扱い．
--- FWWindowIfにしよう
-- なぜFWAppに居る？FWSdkに持たせるのが筋では？
- FWMouseInfo
-- HumanInterfaceに持っていくべき（というか使ってないけどすでにある）
-- Mouseを使うためにHIが必要になるのはいいのか？
--- Deviceは別ライブラリにしよう
--- FWがHIに依存しているのでHIが必要なのは構わないのでは
- FWUICamera
-- 視点変更等はGraphicsに移動
-- HIMouseは2次元のマウスのみ扱う
-- マウスの移動を移動・回転に変換する機能をどこに置くか
--- 状態量は無くして，座標変換をBaseに（緯度・経度・距離はその都度Affineから逆算）．
- FWDragger
-- Physicsとマージ
- FWAppにデフォルトのInitを用意して，改変しなくていい場合はおまじない０で動くようにしましょう
** Creature [#v2135964]
- BodyGenerator：今は使っていない、体をプログラムで生成するためのツール。
- CRScene: シーン（CRCreatureの基本クラス）
- CREngine: エンジン（センサとコントローラ）
-- シーンが持つ。Step()で動くもの。
- センサー：
-- TouchSensor（皮膚のこと）、接触位置と力がかえってくる。
-- PHSolidPairを参照してる。
- コントローラ：
-- CRReachingController 躍度最小でリーチング動作。IKを使う。
-- PHIKEndEffector / PHIKActuator エンドエフェクタに位置を指定・アクチュエータがジョイントの目標関節角を指定。
-- IKのバネダンパの設定、なぜ基準姿勢へのバネと並列に入れるのか？ 位置だけ入れればよいのでは？
-- →到達後、冗長自由度部分が変化していく
-- http://ai.stanford.edu/~ok/ Oussama Khatib Synthesis of Whole-Body Behaviors Through Hierarchical Control of Behavioral Primitives.
CRCreature {
CRBody{
CRIKSolid{
label= ""; *soRightHand; *ikefRightUpperArm;
}
}
}
- このラベルがHeadのやつをNeckControllerが制御対象にするなど。
-- →直接ノードを参照するのとどっちがいいの？
終了行:
[[開発者向け情報>devel]]
~
* 2011年3月 コードレビュー [#fad62255]
** Framework [#uf6736d3]
*** MultiRateHapticを実現するためのFWの実装の現状 [#u1f8c608]
- クラス図
-- http://haselab.net/intra/haselab_wiki_before2010/index.php?plugin=attach&pcmd=open&file=FWApp_interaction.png&refer=%BF%DC%BA%B4%A4%CE%B8%A6%B5%E6%A5%CE%A1%BC%A5%C8
- glutIdleFuncに登録した関数内でPhysicsのステップが動く
- MultiMediaTimerに登録したTimerFunc内でHapticLoopが呼ばれる
- MMTimerからidleFuncに同期命令を飛ばす
-- MMTimerで走っている物体の位置と速度をglutIdleの方に代入するような感じ
- FWInteractScene
-- FWApp側からMMTimerで走っている力覚系のオブジェクト群にアクセスするためのもの
-- FWSceneを持っている
-- InteractPointerやInteractSolidを保持する
-- FWInteractSceneのStep : 前後にいろいろ追加処理をしたうえで内部でFWSceneのステップを呼ぶ
-- FWInteractAdaptee（＝実装はFWLDHapticなど）のStepで，モビリティ行列の計算など物理ステップからの同期の処理をする
- 本物のFWSceneはFWInteractSceneが持っている
- LocalのSceneは独自実装
*** Timer問題 [#tdfd4f4a]
- CreateTimerの戻り値をint（id）ではなくオブジェクトにしたほうがいいのでは
-- UTTimerIfを返して，そこからintervalの設定等を行えるようにしたほうがよいのでは？
-- FWAppがtimerを持っている理由は？
--- ユーザがFWApp以外のオブジェクトをCreateするのもおかしい
--- FWApp::Initの中でTimer作成をやってしまう（値等も適当に入れる．デフォルト処理）
- tazzさんがFoundation/UTTimerをしっかり実装しなおしてコミット待ち中，上記について見直した上でコミット予定
-- → FWTimerはなくす予定
*** Physics周辺 [#tdfd4f4a]
- PHContactDetectorに市民権を与える
-- 当たり判定情報をユーザにも開発者にも利用しやすい形で整備してインタフェースを公開
- 力覚専用の物理演算機能
-- FrameworkからPhysicsへ移すか検討．Physicsにおくならある程度の汎用性が必要
*** モジュールを分ける話 [#bf2a8f3e]
- FWの立ち位置とは？
-- PhysicsとGraphicsをつなげるもの？
-- HIはHapticのみならずキーボードやマウスを含むヒューマンインターフェース全般？
- FWの各機能をバラして他のライブラリに入れ，FWはできるだけ薄っぺらくしたほうがいいのではないか
-- Local DynamicsのInteractPointer等はHumanInterfaceへ
-- Local Dynamicsのモビリティ行列計算等はPhysicsへ
-- マウスでつかむのはHumanInterfaceへ
-- マウスで視点変更はGraphicsへ
-- ...etc.
- ...できるの？
-- Local Dynamicsの計算はPHの計算をあこちで利用しながら行われている．ばらすことは可能だろうか
-- ''↓以下で検討開始''
- アクセレランスの計算は汎用化できるのではないか
-- 現在のアクセレランスの計算はFWLDHaptic3Dの中
-- アクセレランス行列の計算のようなものは制御にも使える
--- LDHapticのアクセレランスは力に対する加速度の行列，軌道追従制御で使うのはトルクに対する加速度の行列
--- 軌道追従制御のは関節トルクの次元数がとても大きくなる場合もある．
-- → 自由度nを渡すとn回テストシミュレーションを行って行列を返してくれる機能をPhysics(PHScene)につけるべきだろう
--- （PHSceneにアイランド機能が付いた暁には，アイランドごとに付けるべき機能．）
- （ちなみに今までモビリティと呼ばれていたものは実はアクセレランス：http://www.onosokki.co.jp/HP-WK/eMM_back/04_07_22add.htm）
- ポインタに一番近い物体の探索はどこに実装すべきか
-- 参考：PHRay : 直線上の最初にある物体を見つける機能
--- CDShape::LineIntersect : 直線に関して交差するかを調べ，交差する場合交差する点を返す
--- 同様に，点から最近傍の物体を探す機能をCDShapeに付けてもいいのでは？
-- そもそも何故CDに入ってないのか？
--- solidPairを持ってるのがPHだから
--- PHContactDetectorがsolidPairや物体のソート結果を持っている ： 利用出来るようにするにはどうすれば？
--- ・ContactDetectorはテンプレートになってて一般ユーザからは使いづらい
--- ・・ なぜテンプレート？ → forLCPかforPenaltyかによってPairに持たせるべき情報が全く違うので．
-- 近傍物体の探索にはPairは要らないのでは？
--- それでもsolidPairが使いたい場合はある ： クリーチャにおいて接触対象の剛体を知りたい場合とか
-- → SolidPair， ShapePairの基本クラスを作ってそれが外から見られるようにするべき
--- それができるとContactDetectorをテンプレートではなくせるか？→まだわからない．書いてみてうまくいったら開示
-- PHSceneインタフェースを持つのが良いのではないか。
- ↑以上の機能の移行が行われれば，FWにおけるLocal Dynamicsの処理はPHのAPIを呼び出すだけで済むようになるはず
- フレームワークがPhysicsとHumanInterfaceの橋渡しを行っている，という考え方には問題がなさそう．
-- この立場は今のまま，現在FW内部にある実装のうち共通で使える機能はどんどん他のライブラリに移転していく．
- MMTimerで動いているLocal Dynamicsのシミュレーションはどこへ・・・？
-- ポインタの侵入量から力を算出して出力するような処理を行っている
--- つまりHaptic Renderer なので HumanInterface に入れるべき？
--- ・Graphic RendererがGraphicにあるように．
--- IASolidはPHSolidに依存している（これは速度の観点から避けられない）．
--- ・これをHIに入れるとHIがPHに依存してしまうので避けるべき．
--- ・Physicsに入れるべき？
- 剛体を操作するための機能等はPhysicsにいれてしまうべき
-- Physicsの剛体にハンドルを付ける ＋ HumanInterfaceで位置の入力等が行われる ＋ FWが位置を剛体のハンドルに反映させる
-- これらはマウスで剛体の位置を動かす機能や，ARアプリでカメラから剛体の位置を動かす場合等にも共通する処理．
-- → PHPointer
*** 命名問題 [#ea069cda]
- Adapter？
-- Adapterパターンは既存のクラスに覆いかぶさって見た目を変えるもの．
-- Observerパターンはメッセージを待ち受けるという印象が強い．
-- Bridgeパターン ： 実装を分離するパターン．AbstractionとImplementer．これか？
--- Implementerは長い・・・が，Implだと将来 If をやめて Impl にしようと思ったときかぶるかも．
--- ''Handler'' とも呼ばれる．''←これで！''
*** FWAppInfoの整理 [#ea2c1fb4]
''（このへんに関してはtazzさんお願いします）''
- FWVFuncBridge
-- RubyでFWAppを継承したクラスを作った時に仮想関数が呼ばれるようにするためのもの
-- → そういう場合はRuby上でFWAppを書いたほうが早い．不要．
- FWWin
-- Ifでないのはなぜ？
--- → Vec3等と同じ扱い．
--- FWWindowIfにしよう
-- なぜFWAppに居る？FWSdkに持たせるのが筋では？
- FWMouseInfo
-- HumanInterfaceに持っていくべき（というか使ってないけどすでにある）
-- Mouseを使うためにHIが必要になるのはいいのか？
--- Deviceは別ライブラリにしよう
--- FWがHIに依存しているのでHIが必要なのは構わないのでは
- FWUICamera
-- 視点変更等はGraphicsに移動
-- HIMouseは2次元のマウスのみ扱う
-- マウスの移動を移動・回転に変換する機能をどこに置くか
--- 状態量は無くして，座標変換をBaseに（緯度・経度・距離はその都度Affineから逆算）．
- FWDragger
-- Physicsとマージ
- FWAppにデフォルトのInitを用意して，改変しなくていい場合はおまじない０で動くようにしましょう
** Creature [#v2135964]
- BodyGenerator：今は使っていない、体をプログラムで生成するためのツール。
- CRScene: シーン（CRCreatureの基本クラス）
- CREngine: エンジン（センサとコントローラ）
-- シーンが持つ。Step()で動くもの。
- センサー：
-- TouchSensor（皮膚のこと）、接触位置と力がかえってくる。
-- PHSolidPairを参照してる。
- コントローラ：
-- CRReachingController 躍度最小でリーチング動作。IKを使う。
-- PHIKEndEffector / PHIKActuator エンドエフェクタに位置を指定・アクチュエータがジョイントの目標関節角を指定。
-- IKのバネダンパの設定、なぜ基準姿勢へのバネと並列に入れるのか？ 位置だけ入れればよいのでは？
-- →到達後、冗長自由度部分が変化していく
-- http://ai.stanford.edu/~ok/ Oussama Khatib Synthesis of Whole-Body Behaviors Through Hierarchical Control of Behavioral Primitives.
CRCreature {
CRBody{
CRIKSolid{
label= ""; *soRightHand; *ikefRightUpperArm;
}
}
}
- このラベルがHeadのやつをNeckControllerが制御対象にするなど。
-- →直接ノードを参照するのとどっちがいいの？
ページ名:
サイト内検索
and
or
メニュー
Springhead
トップページ
スクリーンショットと紹介
ダウンロード
ドキュメント
開発者向け情報
SprBlender
SprBlender
SprBlenderの特徴
SprBlender使用例
ダウンロード
ドキュメント
Choreonoid Springhead Plugin
CnoidSprPlugin
Counter: 0, today: 0, yesterday: 0
ページ一覧