Tongji dev#15
Conversation
- Return armor_id from input armor_pattern
…nterface implements to be read-only and immutable.
Note: The implement of ITargetPredictor interface is not fully implemented yet.
… load parameters from YAML config
- 时间戳: data::TimeStamp - 预测器更新包: data::PredictorPackage --- 自今日起 书同文 车同轨
…uto_aim into tongji-dev
Enable recursive submodule checkout in workflow.
这版本应该没有需要改的了,代码太多我脑袋跑不出来仿真,后面用实车debug |
修改了
fire control的逻辑,删去了Snapshot、SnapshotManager类等(冗余了)需要修改的地方:
在
fire_controller/fire_controller.cpp中(具体是这个函数:aiming_solver_->SolveAimSolution),使用
std::dynamic_pointer_cast对指针进行转换,原因是需要根据整车的状态(位置坐标和转速)来选择击打点,但返回的share_ptr<interface::IPredictor>无法获取该信息,暂时没想到别的办法,所以先这样写由于修改了
fire_control的一些逻辑,同步器同步的信息应该需要修改一下,但暂时还没改,属于一个TODO的状态为了方便理解,说一下下子坐标系的规定:一共就俩坐标系,没有muzzle坐标系。
一是相机坐标系,就是规规矩矩的ros的相机坐标系。
二是gimbal坐标系,右手系,原点在z轴(始终竖直向上,也是yaw轴)和pitch轴的交点。这个原点会随着车的(平移)移动而移动(平移),但是不会随着云台的旋转而旋转(即固定在车上)。xyz轴的正方向由初始状态决定,之后坐标轴的正方向不会随着车辆的移动、云台的旋转而改变。
如果说要引入一个绝对的世界坐标系的话,上述定义的云台坐标系和世界坐标系只差一个平移向量。本来估计器就是按照匀速运动估计的,我认为将云台坐标系的原点放到车上也没增加什么误差,反而更容易代入理解(余以为),so就这样规定了,俩坐标系足矣
先瞅一瞅逻辑上有没有啥大问题捏(如果没啥问题,短时间内被不会大量改动)
睡醒后写写测试(下次俺要及时写测试QAQ)