attitude controllerの整理

[chibi314]

具体的な場所はここになります． 今，ここにはAttitudeControllerというクラスが一つあり，その中でuav_modelを指定することで機体ごとに制御がスイッチするようになっていますが，そうすると各関数内でif文が発生するため可読性が低いと思います． なので，PWMの変換などの共通化できる部分を基底クラスに実装して，各機体ごとの制御を派生クラスに実装(HydrusAttitudeController, etc.)すると機体ごとに制御がメンテナンスできるのでいいと思うのですがどうでしょうか？ 勿論DragonがHydrusを継承する，というようなことも可能です．

[tongtybj]

いいと思います。修論終わってからでもいいとおもうけど。

あと、各ロボット内で、複数の制御手法を持つことも検討してほしい。例えば、hydrusに関しては既存のLQIと石君のSLQ-MPC手法が挙げられる(SLQ-MPC手法はもっと一般的な方法で、dargonやhydrusxiにも使えるかも)。

それと、同じ機体でも、地上と飛行で２つの制御モードが考えられるね(伊藤君がやっているような)。

[chibi314]

あとは ここにも機体種類依存のif文が書かれてしまっているので、制御方法を分割するというよりは、機体ごとに特有な処理とそれ以外で綺麗に分ける構造を考えています。

[tongtybj]

#406 によって、attitude_controllerの中身がだいぶ変わりました。 まず、線形フィードバック制御(PID, LQI)は一つの関数でまとめています。 https://github.com/tongtybj/aerial_robot/blob/refactor_aerial_robot_base/aerial_robot_nerve/spinal/mcu_project/Jsk_Lib/flight_control/attitude/attitude_control.cpp#L270-L349

@makit0sh

制御器の切替に関してだが、 #defineのマクロで切り替えると、動的な切替ができなくなるので、rosserialからrostopicかrosserviceで切る変えられるといいと思っています。 上記のスコープをswitch文の1caseにして、適応制御を別のcaseにとして実装していくのが一番はやいと思う。