Enemy Detection

[ikemuuu]

• obstacle detector
• clubhouse アルゴリズム
• 画像処理
• 敵の壁マーカ取得状況から，エリアを推定

[ikemuuu]

Attack Mode に遷移したときに，独自設計の cmd_vel 吐き出すだけじゃなくて，move_base キャンセルする必要あり -> Done

Basic Mode に復帰した際に，続きの waypoint を再度目標地点に設定することも確認済み．

[EndoNrak]

Attack Mode に遷移したときに，独自設計の cmd_vel 吐き出すだけじゃなくて，move_base キャンセルする必要あり

これってmove_baseもattack modeもcmd_velを吐き出すから、コンフリクトするイメージ？

[ikemuuu]

Attack Mode に遷移したときに，独自設計の cmd_vel 吐き出すだけじゃなくて，move_base キャンセルする必要あり

これってmove_baseもattack modeもcmd_velを吐き出すから、コンフリクトするイメージ？

そうそう！
直前の目標地点が残った状態やと，Attack Mode やのにその目標地点を目指してしまうときがあるから

[EndoNrak]

多分あとでわからんくなるから、それだけに焦点を絞った修正のPRつくるわー

[ikemuuu]

burger_war_dev/burger_war_dev/scripts/navi/naviBasic.py

Lines 78 to 80 in c0255e6

	def cancelGoal(self):
	print('Cancel Navi Goals')
	self.client.cancel_all_goals()

[ikemuuu]

Basic → Attack 遷移時に，naviBasic に新たに追加した上のメソッド呼んでるだけやで

enemy-detection branch にはもう push してる

[EndoNrak]

enemy detectionとは関係ない話やから、こういうのはPRを分けたほうがいい
っていうこだわり！笑
PRの責任範囲を明らかにしとかないと、バージョンを戻すときにどこまで戻したらいいかわからんくなる

[EndoNrak]

conflictがないようにenemy-detectionから丸パクリしとく

[ikemuuu]

enemy detectionとは関係ない話やから、こういうのはPRを分けたほうがいい
っていうこだわり！笑

それで言うと，敵検知やらenemy-detection っていう名前が良くないかもやな笑
検知，してからのアタックもここに突っ込む気満々

[EndoNrak]

検知とアタックは分けたほうがよさそうやなあ
頼んだ！

[ikemuuu]

LiDAR による敵検知

clubhouse アルゴリズムを採用することにする．
obstacle detector の方が確かに ROS っぽいけど，動的障害物が1つだけ（敵機体のみ）なので，obstacle detector の旨味そんなにない．

clubhouse アルゴリズム でも自己位置がずれていなければ，十分敵を検知できる．
（自己位置ずれていたら，obstacle detectorも，どのみちしんどい）

[ikemuuu]

カメラによる敵検知

使うかどうか迷い中...
使うなら，LiDARによる敵検知で近づいてから，敵機体の緑を見る，という形になりそう．

カメラ使うメリットあるかどうか．

使うなら，
self.imgInfo.is_enemy_marker_recognized
を緑による判定に変える必要あり（今は赤バルーン）