Note32.md

修细节 & 训练学搬运 和 用搬运

---

• 修细节 & 训练学搬运 和 用搬运
  • n32p01 试错效率低下问题: 新增OutSPDic
  • n32p01b 回测
  • n32p02 多层子H任务嵌套时的H迁移
  • n32p03 整理下：HE模型流程图
  • n32p04 调整"持续饿感"的"任务失效机制" : 调整为负mv反馈后任务不失效
  • n32p05 学搬运
  • n32p06 用搬运（一）
  • n32p07 迭代TCPlanV2
  • n32p08 用搬运（二）
  • n32p09 "搬运,去皮,飞至,吃掉": 连起来跑通
  • n32p10 连续视觉
  • n32p11 用搬运（三）
  • n32p11b 迭代-学Canset触发机制(更易发)
  • n32p12 HCanst学和用-知识结构整理
  • n32p13 回测-学Canset触发机制(更易发)
  • n32p14 训练FZ97
  • n32pxx TODO备忘

---

n32p01 试错效率低下问题: 新增OutSPDic

CreateTime 2024.06.09

32011-我特意加训了rCanset[饿,扔无皮果,飞至,吃],但rSolution就是激活不到它;
训练: 在FZ954x7基础上: 加训饿果飞吃三次后,存为:FZ955x3;
说明: 如下日志,rSolution激活到的,都是一些[硬扛],或者[饿,果,果],这些rCanset;
3. I<F4900 F8772[M1{↑饿-16},M1{↑饿-16},M1{↑饿-16},M1{↑饿-16}]> {0 = 3;} {} (null):(分:0.00)
4. I<F4900 F8798[M1{↑饿-16},M1{↑饿-16},M1{↑饿-16},M1{↑饿-16}]> {0 = 3;} {} (null):(分:0.00)
3. I<F3611 F6351[A13(饿16,7),A4899(距11,果),A4899(距11,果)]> {} {0 = S4P2;1 = S0P1;2 = S0P1;} H2N6:(分:0.25)
4. I<F3521 F5100[A13(饿16,7),A5099(向90,果),A5099(向90,果)]> {} {0 = S0P1;1 = S1P2;2 = S3P2;} H3N3:(分:0.50)
4. I<F3521 F5100[A13(饿16,7),A5099(向90,果),A5099(向90,果)]> {} {0 = S0P1;1 = S1P2;2 = S3P2;} H3N3:(分:0.50)
解决思路: 说白了,无论是错误还是正确的rCanset,都没有积累过SPEFF,导致对的没出头,错的又易胜出,所以搞下试错训练自然就好了,如下:
试错训练: `FZ954x7,饿,上方扔无皮果`,如果它激活硬扛等错误rCanset就会败北,如果它激活[无皮果,飞,吃]就能成功解;
具体实行: 打出flt日志,step1=激活行为化的rCanset,step2=feedbackTOR反馈,step2b=feedbackTOP反馈,step3a=OR反省,step3b=OP反省,从这5个日志观察整个rCanset从激活到最终SP反馈;
遇到问题: 在跑以上试错训练时,发现试错训练有点慢,虽然传染了,但只要SP不打负分,就相当于每次遇到任务时,都得重新来一遍 `此问题转32012`;
结果: 在32012写了OutSPDic后,Canset可以快速响应了,试错效率没啥问题了 `T 参考32012-结果`;

小结: 上表在做试错训练,但并不顺利,问题如下 (此问题转下表解决,待解决后,再回来继续进行试错训练);

问题: 因为SPEFF仅针对cs_besting的canset,导致那些cs_none状态的,在下次重启时又可以卷土重来,而真正有用的canset[无皮果,飞,吃]则很难有出头之日 (即试错效率太低);

32012	Canset池SPEFF试错效率太低
说明	见上表试错训练时-遇到问题: 传染只发生在工作记忆中,长时记忆的SPEFF又仅针对转实后的Canset,导致效率低下;
方案	即使不转实,也可以累积SPEFF,这样可以从根本上解决试错效率低下的问题;
实践	可以在sceneTo下,直接针对sceneFrom和cansetFrom记录SPDic,这样性能才ok,可不转实就批量记录SP参数;
	> 借此机会把IN和OUT的SPDic分开 (IN是对scene存SP,OUT是对canset存SP);
TODO1	新写一个AIOutSPStrong(),把sceneFrom和cansetFrom存里面,然后把spDic也存里面 T;
TODO2	在AIFoNodeBase里加一个outSPDic<K=sceneFromPId_cansetFromPId, V=AIOutSPStrong> T;
TODO3	改下在生成xvModel前(更不需要等siModel),就把outSPDic初始一下 T;
	时机: 在构建canset到canset池时,把cansetFrom的spDic做为初始化outSPDic (加上防重,仅初始化一次) T
	更正: 把由spDic做初始,改成由sceneFrom中cansetFrom的outSPDic来初始 T;
TODO4	改下把中间帧超时反馈失败的 (及所有传染到的),在actYes超时未反馈后,计SP- T;
TODO5	改下把中间帧反馈成功的 (或被唤醒的),在feedbackTOR反馈匹配后,计SP+ T;
	另外: 其中唤醒的,应先把传染时的负1回滚一下,再把正1加上 T;
TODO6	改下把末帧超时未反馈负价值的 (及所有已达到末帧的canset),在actYes超时未反馈后,计SP+ T;
TODO7	改下把末帧反馈负价值的 (及所有已达到末帧的canset),在feedbackTOP反馈匹配后,计SP- T;
TODO8	把canset竞争由InSP改成由OutSP来计算 T;
回测	继续上表末的试错训练: 试跑几次,饿,上扔无皮果,看下canset的竞争情况会不会快速响应竞争变化;
结果	经测跑三四次饿,无皮果,飞,吃后,是可以快速响应变化,使这些有用的canset快速具备竞争力 存为FZ955x6;

小结: 上表支持了OutSPDic,然后可以快速响应试错效率提升了,但是这改动会影响OutSP评分,所以TO阶段的训练也需要重新训练下: 下面重跑下训练FZ66,以及继续推进31183的训练项3-无皮果动机;

---

n32p01b 回测

CreateTime 2024.06.21

上节支持了OutSPDic,本节回测;

32013	在FZ955基础上接着继续31183-训练项3的无皮果动机及后续训练项 (参考31183)
训练项1	测下newRCanst,absRCanset,newHCanset,absHCanset四个都能执行到 在31183完成过,此处重训练下;
	> 步骤4: (路边出生,饿,路上扔带皮果,扔棒去皮,手动飞至,触发吃掉) x 路下n次 (注:鸟与果相对位置要稳定些)
	> 注意: 跑前几次还好,后几次最好边观察hSolution有激活结果,边慢训几次,以使absHCanset可执行到;
	> 说明: 在FZ913基础上,按此步骤4重训练,得到FZ964 T;
训练项2	试错训练: 测下可以快速响应Canset的OutSPDic变化,使有用的canset快速具备竞争力;
	> 步骤5: 跑三四次饿,无皮果,飞,吃,存为FZ965 T;
训练项3	测下无皮果动机;
	> 训练6 FZ965,路下出生,点击饿 (说明: 观察日志,看能否得到无皮果动机);
	> 日志: HDemandA4584(向89,距12,果),A4467(向92,距12,果),A4075(向86,距12,果)等,可见无皮果动机ok T;
训练项4	学去皮: 学会去皮(压去皮) T;
	> 训练步骤: 1.在去皮动机生成H无皮果后 2.扔有皮果 3.扔棒去皮 4.feedbackTOR反馈到无皮果 5.生成扔棒去皮H经验
	> 具体步骤: FZ965,路上出生,点击饿,在生成H无皮果后,扔有皮果,扔木棒去皮,上飞吃掉;
	> 取一些训练中关键日志如下:
	H无皮果日志1: flt1 A4204(距12,果)
	H无皮果日志2: flt1 A4592(向88,距0,果)
	H无皮果有反馈成立1: flt2 R feedbackTOR反馈成立:A4584(向89,距12,果) 匹配:1 baseCansetFrom:F4622[↑饿-16,4果,飞↑,4果,吃] 状态:CS_Besting
	H无皮果有反馈成立2: flt2 R feedbackTOR反馈成立:A4204(距12,果) 匹配:1 baseCansetFrom:F4565[↑饿-16,3果,飞↑,3果,吃] 状态:CS_Besting
	学会去皮HCanset经验1: flt3 Canset演化> AbsHCanset:F5611[M1{↑饿-16},A4204(距12,果)] toScene:F4565[↑饿-16,3果,飞↑,3果,吃] 在2_1帧:A4467(向92,距12,果)
	学会去皮HCanset经验1: flt3 Canset演化> NewHCanset:F5612[M1{↑饿-16}] toScene:F4622[↑饿-16,4果,飞↑,4果,吃] 在1帧:A4584(向89,距12,果)
	> 说明: 如上日志可见,此训练过程能够生成扔棒去皮H经验,并存为:FZ966 T;
训练项5	用去皮: 能生成H有皮果动机;
	其间问题1: 其间发现反思不通过,加训[饿,更饿]和[饿,皮果,去皮,食之] (参考32016-方案);
	其间解决1: 具体解决的训练步骤:饿,更饿,更饿,皮果,扔棒去皮,飞至食之 (这个可以加强饿更饿,并且减弱饿皮果更饿),存为FZ967 T;
	结果日志1: > F5841行为化前 的 子任务分:-9.91 > 当前任务分(饿):-10.86 =====> 已通过,日志可见,它可以反思通过了;
	继续回测1: 继续测有皮果动机步骤: FZ967,饿,效果如下:
	> H有皮果动机ok: TCDemand.m 39] A4006(向87,距12,皮果),日志可见,可以生成H有皮果动机了 T;
	其间问题2: 测得在更饿发生后任务会失效,导致来不及生成"有皮果动机",这个root就不再有激活机会了
	其间解决2: 在n32p04中,已经调整"持续饿感"的"任务失效机制":调整为负mv反馈后任务不失效,此问题已修复 (参考n32p04);
	继续回测2: 继续测有皮果动机步骤: FZ967,饿,效果如下:
	> H有皮果动机执行行为化ok: R行为化中间帧下标 (1/10) A3955(向90,距13,皮果)
	结果: 随着以上两个BUG的修复,H有皮果动机已经彻底ok,下面开始训练学搬运 转训练项6;
训练项6	学搬运: 学会搬运(踢坚果);
	说明: 前几个训练项已经在下面直至n32p04修了许多个BUG,此处训练项6的推进转到n32p05中继续干 (转n32p05);
训练项7	用搬运: 使用搬运;

小结: 上表就是本节的训练测试的主表,下面都是些中途发现BUG并修复的记录;

32014	BUG-生成canset时的indexDic又有越界问题了,查下原因
原因	在NewHCanset时,使用了self.realCansetToIndexDic映射,但这个映射此时也还在更新中,导致有更新后,越界了;
修复	创建NewHCanst时先把realCansetToIndexDic.copy(),这样后续再更新,就不会同步追加到已经创建的NewHCanset映射中 T;

32015: 测有皮果动机-测得反思因噎废食不通过问题
复现: `FZ966,路下出生,点击饿`
说明: 如下日志:`1.hSolution输出了有皮果的解 2.行为化前先反思并得到P20条解 3.形成了子任务 4.反思没通过`
反思: 的双方为: A任务本身是为了防止更饿 <= PK => B以往失败时它也会更饿;
    > 分析: 以往的更饿,与执行Canset无关,即使不执行,它也会变更饿;
示例1: 喝药没治好病,只能说明药没用,而不是药使你继续病 (用药的后续病重程度 ≈ 不用药的持续病重程度);
示例2: 中药用错即为毒,确实会让病更重 (用药的后续病重程度 > 不用药的持续病重程度);
示例3: 喝药非常苦,不管病好不好,药苦是药带来的;
    > 分析: 下方日志中,其实二者是约等于的,此时不应因此而`因噎废食`;
方案1: 留下50%的余地,即`A x 1.5 < B`时才判定为反思不通过 (参考3005a-方案1 已经做过);
方案2: 不应该取`最严重子任务分`,因为那个最严重也未必就会发生,所以取每个子任务的平均分 `先选定此方案`;
方案3: 不应该取`最严重子任务分`,因为那个最严重也未必就会发生,所以按每个子任务的pFo的强度来分配评分比重求出最终综合得分 `现在本就支持sp率影响评分`;
抉择: 方案2简单便捷,并且本来就支持spScore对评分的影响,暂选定,进行实践 `已实践 T`;
回测: 经回测,改完方案2后还是反思不通过,平均分依然很高,导致不通过 `转32016 T`;
3438 [11:14:52:084 TO        TCSolution.m  39] =============================== 12 hSolution ===============================
3439 [11:14:52:084 TO        TCSolution.m  39] flt2 目标:A4628(向89,距11,果) 已有S数:0
3440 [11:14:52:160 TO    TCSolutionUtil.m 117] 第2步 H转为候选集:29 - 中间帧被初始传染:9 = 有效数:20
3441 [11:14:52:161 TO    TCSolutionUtil.m 198] 第5步 HAnaylst匹配成功:29
3442 [11:14:52:161 TO    TCSolutionUtil.m 206] 第6步 H排除Status无效的:29
3443 [11:14:52:161 TO    TCSolutionUtil.m 212] 第7步 H排除Infected传染掉的:20
3444 [11:14:52:162 TO    TCSolutionUtil.m 218] 第8步 H排除FRSTime来不及的:18
3445 [11:14:52:164 TO            AIRank.m 189] flt3 H0. I<F3998 F4228[↑饿-16,4果皮]> {0 = 0;}  (null):(分:0.00) [CUT:0=>TAR:1]
3446 [11:14:52:165 TO            AIRank.m 189] flt3 H1. I<F3998 F4241[↑饿-16,4果皮]> {0 = 0;}  (null):(分:0.00) [CUT:0=>TAR:1]
3447 [11:14:52:166 TO            AIRank.m 189] flt3 H2. I<F3998 F4327[↑饿-16,4果皮,4棒]> {0 = 0;}  (null):(分:0.00) [CUT:0=>TAR:1]
3448 [11:14:52:167 TO            AIRank.m 189] flt3 H3. I<F3998 F4249[↑饿-16,4果皮]> {0 = 0;}  (null):(分:0.00) [CUT:0=>TAR:1]
3449 [11:14:52:168 TO            AIRank.m 189] flt3 H4. I<F3998 F4342[↑饿-16,4果皮,4棒]> {0 = 0;}  (null):(分:0.00) [CUT:0=>TAR:1]
3450 [11:14:52:169 TO      TCRefrection.m  39]
3451 [11:14:52:169 TO      TCRefrection.m  39]
3452 [11:14:52:169 TO      TCRefrection.m  39] =============================== 12 TCRefrection反思 ===============================
3453 [11:14:52:169 TO      TCRefrection.m  39] F4228[↑饿-16,4果皮] CUT:0 无效率:0.00
3454 [11:14:52:169 TO      TCRefrection.m  67] 反思评价结果:已通过 (解决任务奖励分10.0 Canset风险:0.00 懒分:0.0 = 10.0)
3455 [11:14:52:169 TO    TCSolutionUtil.m 256] 第9步 H求解最佳结果:F4228 {}
3456 [11:14:52:185 TO AIThinkingControl.m 271] energy > delta:-1.00 = energy:18.00
3457 [11:14:52:190 TO        TCSolution.m 278] > newH 第29例: eff: sp:{} I scene:F3998 canset:F4228 (cutIndex:0=>targetIndex:1)
3458 [11:14:52:199 TO     TCRecognition.m  35]
3459 [11:14:52:199 TO     TCRecognition.m  35]
3460 [11:14:52:199 TO     TCRecognition.m  35] =============================== 12 行为化前 反思识别 ===============================
3461 [11:14:52:199 TO     TCRecognition.m  35] regroupFo:F6332[M1{↑饿-16},M1{↑饿-16},M1{↑饿-16},M1{↑饿-16},A4227(向91,距13,皮果)]
3482 [11:14:53:443 TO          AIFilter.m 351] 过滤器: 总91需20 主:0.22 => 剩:20
3483 [11:14:53:443 TO           TIUtils.m 470]
3484 [11:14:53:443 TO           TIUtils.m 470] 时序识别结果 P(20条) R(0条)
3485 [11:14:53:633 TO          AIFilter.m 191]
3486 [11:14:53:633 TO          AIFilter.m 191] 时序二次过滤后条数: 剩3 >>>>>>>>>>>>>>>>>>>>>
3487 [11:14:53:634 TO          AIFilter.m 192] 	1. F1351[M1{↑饿-16},A1348(距47,向147,皮果)]
3488 [11:14:53:635 TO          AIFilter.m 192] 	2. F518[M1{↑饿-16},A515(距32,向72,皮果)]
3489 [11:14:53:636 TO          AIFilter.m 192] 	3. F1323[M1{↑饿-16},A1320(距63,向58,皮果)]
3490 [11:14:53:637 TO           TCDebug.m  61] [TCRecognition.m => TCDemand.m] 操作计数:811 用时:****** (616) (读:0 写:0)
3491 [11:14:53:639 TO          TCDemand.m  39]
3492 [11:14:53:639 TO          TCDemand.m  39]
3493 [11:14:53:639 TO          TCDemand.m  39] =============================== 13 subDemand ===============================
3494 [11:14:53:639 TO          TCDemand.m  39] 子任务数:1 baseFo:F6331[M1{↑饿-16},A4227(向91,距13,皮果)]
3495 [11:14:53:640 TO          TCDemand.m  76] 	 pFo:F1351[M1{↑饿-16},A1348(距47,向147,皮果)]->{饿-16.00}
3496 [11:14:53:641 TO          TCDemand.m  76] 	 pFo:F1323[M1{↑饿-16},A1320(距63,向58,皮果)]->{饿-16.00}
3497 [11:14:53:642 TO          TCDemand.m  76] 	 pFo:F518[M1{↑饿-16},A515(距32,向72,皮果)]->{饿-12.80}
3498 [11:14:53:642 TO      TCRefrection.m  39]
3499 [11:14:53:642 TO      TCRefrection.m  39]
3500 [11:14:53:642 TO      TCRefrection.m  39] =============================== 13 行为化前 反思评价 ===============================
3501 [11:14:53:643 TO      TCRefrection.m 104] > 最严重子任务分(饿):-10.45 > 当前任务分(饿):-10.04 =====> 未通过
3502 [11:14:53:643 TO AIThinkingControl.m 242] TO上轮:失败 等待:0.0 下轮:10 消息:action反思不通过
3626 [11:14:54:645 TO     DemandManager.m 300] 	第1条 饿 评分-10.17 激活成功 	{proto:F6334 pFos:(F3871,F3825,F3566,F3717,F3579,F3597,F3521,F3531,F3543,F3553,F3611,F3629,F3651,F3699,F3644,F3559,F3546,F3534,F3524)}
3627 [11:14:54:646 TO     DemandManager.m 303] Demand竞争 <<<== SUCCESS 共6条
3628 [11:14:54:647 TO            TCPlan.m  51] 取得最终胜利的末枝 >> 取分: K:0x600003f04750_ => V:(null)分

32016-反思子任务迫切度太高,导致反思仍不通过;
//=============================== 13 subDemand ===============================
//子任务数:1 baseFo:F6642[M1{↑饿-16},A4227(向91,距13,皮果)]
//pFo:F1351[M1{↑饿-16},A1348(距47,向147,皮果)]->{饿-16.00}
//pFo:F1323[M1{↑饿-16},A1320(距63,向58,皮果)]->{饿-16.00}
//pFo:F518[M1{↑饿-16},A515(距32,向72,皮果)]->{饿-12.80}
//=============================== 13 行为化前 反思评价 ===============================
//> 行为化前:F4228 的 子任务分:-10.45 > 当前任务分(饿):-10.04 =====> 未通过

分析1. 在经验中,场景pFo饿了不一定会更饿,所以任务分在10.x左右 `即[饿]->{更饿} 只有65%稳定性`;
分析2. 而在反思预测中,饿了看到皮果,的场景pFo,却更大几率会更饿,所以它的评分在15左右 `即[饿,皮果]->{更饿} 却有95%稳定性`;
思路: 可以把[饿]->{更饿}训练的更稳定,或者把[饿,皮果]->{更饿}训练的更不稳定,即以下两个方案都执行下来试下;
方案1: 降低子任务分: 看下多训练几下: 看到有皮果后,去皮并吃到,看能不能把这个几率降低一下;
  > 实践: 训练步骤`饥饿,皮果,扔棒去皮,飞至食之` => 使之知道皮果去皮一吃是可行不再饿;
方案2: 提升父任务分: 当饥饿多次无解,它自然会任务分更高,直到饿的程度足够它冒险尝试;
  > 实践: 训练步骤`饥饿,等一会让它多饿几次` => 使之知道稳定不解决一直会饿;
结果: `转32013-训练项5-其间问题1` 加训并存为FZ967 (最终训练步骤也转32013-其间问题1);

32017: 查为什么H有皮果有动机,但没持续推进求解,日志如下:
问题说明: 在`32013-训练项5`,训练有皮果动机时,发现生成了`H有皮果`,但没执行`hSolution有皮果`,经测,发现更饿发生后,`H有皮果`所在的Root再也没激活了,导致没能持续性去推进它,本节重点解决Root的持续性问题;
回顾: 以前其实已经搞过Root的持续性 (在TCDemandManager.refreshCmvCacheSort()中,根据其Canset的进度来评分) (参考31052);
//第1条 饿 评分-10.32 激活成功     {proto:F7597 pFos:(F3871,F3825,F3900,F3566,F3717,F3579,F3597,F3521,F3531,F3543,F3553,F3611,F3629,F3651,F3699,F3644,F3559,F3546,F3534,F3524)}
//第2条 饿 评分0.00             {proto:F7592 pFos:(F7304,F7061,F3871,F3825,F3900,F5594,F7175,F3566,F3717,F3579,F3597,F3521,F3531,F3543,F3553,F3611,F3629,F3651,F3699,F3908)}
日志说明: 如上日志,可见,第1条是更饿,第2条并不是没持续性,而是它评分为0,导致它没激活;
1. 查下此处,前一个饿任务明明还在推进"H有皮果",为什么会被评分0分 (所有pFo都无效);
 分析1. 先查下此处挂0的原因: 为什么都无效了,如果有任务在推进中,但是个持续性任务怎么办?新root能快速复用到旧root的成果吗?
2. 然后看下,以前写的任务推进的持续性,能不能有效,帮助他持续推进下去...
 分析2. 以前为保证任务持续性,对root的竞争显然无效,应该在root推进了几层树时,相应的就加几层权,使之可持续;
修复: 在refreshCmvCacheSort()中改为调用score4Demand_Out()后,它不再是0分了,日志:`root(0/2):F7821[M1{↑饿-16}] 评分:10.86`;
回测: 它确实不再是0分了,但仍然没激活,因为它已经是isExpired状态,导致更饿发生后,就不会再激活了,它的一切工作记忆的推进进度也都白白浪费了 `此问题转n32p04`;

3201x-接31184结果: 无皮果动机和有皮果动机,都需要加训和试错;
//1. 加训无皮果RCanset: 路下出生,扔路上无皮果,上飞至,吃掉;
//      > 目标: 使之能稳定的激活上面习得的rCanset[无皮果,飞至,吃掉],然后生成无皮果hDemand;
//2. 加训有皮果HCanset: 生成无皮果HDemand后,扔有皮果,扔木棒去皮,h无皮果反馈成立,生成无皮果hCanset;
//      > 目标: 使之能稳定的激活上面的hCanset[有皮果,木棒,无皮果],然后生成有皮果的hDemand;
//3. 试错训练: 然后试下,这么多各种canset,是否应该多淌一淌,把一条可行的路慢慢淌出来;

明日: 别着急,一步步来,先看下训练项3,无皮果动机是哪来的,是不是rCanset[无皮果,飞至,吃];
结果: 这个表后来没怎么用,因为后来用(无皮果父任务,有皮果子任务,有皮果搬运子子任务 => 然后先搬运,再压破皮,再飞过去吃),这套流程来一节节推进的 (参考下面几节的手稿记录);

小结: 上面针对31183中,训练不顺的那些训练项,制定了更为细节的训练规划;

TODO测试项3: 测试RCanset有皮果反馈后,能不能继续推后进下一帧;

---

n32p02 多层子H任务嵌套时的H迁移

CreateTime 2024.06.09

起因: 在上节最后的测试中,发现多层H嵌套时,H的迁移应该只支持一层 (测得不支持多层H迁移问题);

1. 原先写的是H的scene必然是rCanset
2. 但其实H的scene可能是baseH,不一定就是rCanset;

示例: H任务在工作记忆中是会多层嵌套的,比如:

1. 无皮果的HCanset为[有皮果,压,无皮果]
2. 然后它的有皮果又有子H任务[路边有皮果,踢,路中有皮果]

问题: 以前H的迁移比R多一层,在这里来看,这是不对的,H不止是一层,它可能多出多层 (因为子H可能嵌套多层);

1. 本节主要分析并支持这种多层下H迁移的情况;

32021	回顾现有代码之: 多层hCanset合并为单层rCanset;
示图
说明	如图,H确实会嵌套,但它的成果会被打包成一个(合并)整体的rCanset;
总结	多层H的成果确实是一个rCanset,但成果之前,它确实是多个h嵌套 (即本表不妨碍本节的问题依然存在);

32022	回顾现有代码之: h迁移也是基于rScene树的;
说明	现有代码中,H的迁移也是基于RScene树来进行的,所以H也许不会有多层嵌套的问题;
解释	即无论H有多少层嵌套,它在长时记忆中都是场景树,比R多一层而已;
结果	本表可见,本节多层子H嵌套的问题压根不存在;

小结: 从32022的结果可见,本节的问题应该是不存在的,中止之;

---

n32p03 整理下：HE模型流程图

CreateTime 2024.06.15

32031	HE流程图
彩图
说明	https://www.bilibili.com/video/BV1Xw4m1e7RH/
注1	反馈由外循环推动(现实与智能体循环),意向性推动了内循环(认知与决策循环);
注2	识别与求解相对,识别是IN阶段的展开,求解是OUT阶段的展开;
注3	此图临时起意,细节上用的名词等并不严谨,但与HE代码的流程是一致的,不影响"表达和理解"其意;

小结: 最近试用了一下B站直播功能,分享了HE流程图,顺便把以上模型图画了下;

---

n32p04 调整"持续饿感"的"任务失效机制" : 调整为负mv反馈后任务不失效

CreateTime 2024.07.03

说明: 在32017-回测中,测得连续饿感在任务失效后,也没法激活,但其实它是连续饿感,并且还没解决,应该能继续推进任务的解决才对,本节针对此问题做改动与支持; 示例: 当饥饿任务还在解决中,就发生了更饿时,此时原饥饿任务应该继续解决,而不是直接计为isExpired状态就白白浪费掉;

32041	分析方案
分析	饥饿是持续性任务,疼痛不是,比如婴儿已经饿过了,还在找吃的,要不要标一下持续性 (把持续饥饿搞的更深入一些,而不止是隔时间就触发下)?
思路	持续饿感,在更饿发生后,说明它还没解决,正应该继续推进解决,而不是失效中断之;
方案	根据mv类型,转为是否为持续mv,如果是持续的,那么只要未解决,就永远不会失效(isExpired);
TODO1	写个方法,用于判断mv为持续性还是单发 (如:饿感为持续性,痛感为单发) T;
TODO2	pFo发生负价值反馈时: 单发价值=>已不可挽回计为失效 & 持续价值感=>发生后还会再发生不计失效 T;
TODO3	持续价值的pFo在到期后,发现已经有mv反馈(但它发生后还会发生),所以不可计为失效状态 (反之,一直没反馈,说明已经自然完成,可以计为失效) T;
回测	第1条 饿 评分-10.86 激活成功 {proto:F7926 pFos:(F7304,F7061,F3871,F3825,F3900,F5594,F7175,F3566,F3717,F3579,F3597,F3521,F3531,F3543,F3553,F3611,F3629,F3651,F3699,F3908)}
结果	根据以上回测日志可见,原饥饿root可以顺利激活了 T;

小结: 上表为本节主体,改后回测已ok

32042-测得`有皮果动机行为化前的反思`又不通过的问题 (参考32016)
说明: 如下,测得新的问题,虽然激活了,但它反思不通过,
//1. 它已经可以激活有皮果动机了,如下日志;
R0. I<F3825 F3986[↑饿-16,4果皮,4棒,4棒,4果,飞↑,4棒,4果,4棒,吃]> {0 = 0;} {9 = S0P16;5 = S0P19;1 = S1P20;10 = S0P2;6 = S0P16;2 = S0P19;7 = S0P16;3 = S0P19;8 = S0P16;4 = S0P19;} H3N2:(分:0.60) [CUT:0=>TAR:10]

//2. 但反思又失败了,看起来像是: 前期训练学认有皮果时跑了上百轮,有了太稳定会饿的副作用;
=============================== 5 subDemand ===============================
子任务数:1 baseFo:F3986[M1{↑饿-16},A3955(向90,距13,皮果),A3958(距89,向18,棒),A3961(向87,距27,棒),A3962(向90,距13,果),飞↑,A3970(向164,距71,棒),A3971(向90,距5,果),A3976(距73,向166,棒),A3979(吃1)]
	 pFo:F200[M1{↑饿-16},A197(向136,距101,皮果)]->{饿-16.00}
	 pFo:F387[M1{↑饿-16},A384(向23,距67,皮果)]->{饿-16.00}
	 pFo:F1351[M1{↑饿-16},A1348(距47,向147,皮果)]->{饿-16.00}
=============================== 5 行为化前 反思评价 ===============================
> F3986行为化前 的 子任务分:-11.20 > 当前任务分(饿):-10.86 =====> 未通过

方案1: 可以试下32016的解决方法应该还是有效果的;
  > 试了下,这方法倒是管用,就是跑着比较慢,毕竟在当时`30092-步骤1`时,对有皮果跑了200次,这副作用有点大,形成阴影了,看到皮果就认定了会更饿;
  > 所以: 这方法虽然管用,但有点麻烦,暂不考虑了;
方案2: 在反思时,可以把任务求解的进度分考虑入内,毕竟在DemandManager中root竞争时就用了进度总分;
  > 此方案简单可行也合理 `95% 选定`;
TODO1: 把原来refreshCmvCacheSort()中求含进度的任务总分,封装成一个方法(封装成了progressScore4Demand_Out)来计算含进度的任务分 `T`;
TODO2: 在actionRefrection行为化反思中,把任务分改为调用"含进度的任务总分",这样应该稳稳的反思能通过了 `T`;
回测日志如下:
日志1. > F3986行为化前 的 子任务分:-11.20 > 当前任务分(饿):-16.49 =====> 已通过
日志2. =============================== 5 行为化Fo ===============================
日志3. R行为化中间帧下标 (1/10) A3955(向90,距13,皮果)
回测说明: 经回测,方案2实践后,有皮果动机反思可以顺利通过了,主要是含了进度影响后,任务总分更迫切了 `T`;

小结: 上表是个行为化前反思不通过的BUG,调整任务为加上进度分影响后,ok了;

---

n32p05 学搬运

CreateTime 2024.07.05

本节接续32013的训练项6学搬运,把训练中遇到的问题或细节等在本节处理修复等;

32051	训练: 学搬运 (参考32013-训练项6)
训练项6	学搬运: 学会搬运 (学会踢坚果能使坚果位置变化);
步骤	FZ967,饿,等看到有皮果动机后,扔路边带皮果,踢到路上 x 5次;
重点日志1	flt1 A4006(向87,距12,皮果) (有皮果动机);
重点日志2	flt2 Canset演化> NewHCanset:F7772[M1{↑饿-16},A7764(向190,距0,皮果),踢↑,A7771(向94,距9,皮果)] toScene:F3986[↑饿-16,4果皮,4棒,4棒,4果,飞↑,4棒,4果,4棒,吃] 在1帧:A3955(向90,距13,皮果) (学会搬运);
注	步骤执行中,如果点击饿后,半天没皮果动机,那多等一会应该就有了 (它需要canset池自行做试错);
结果	将以上训练跑完后 T 存为FZ968;

---

n32p06 用搬运（一）

CreateTime 2024.07.06

本节接续32013的训练项7用搬运,把训练中遇到的问题或细节等在本节处理修复等;

32061	训练: 用搬运 (参考32013-训练项7)
训练项7	用搬运: 使用搬运 (主动有目的的踢坚果);
步骤	FZ968,饿,等看到距0有皮果动机后,扔距0带皮果 -> 然后看它自己把坚果踢到路上;

32062	测到BUG: 有皮果的hDemand生成后,70%执行不到hSolution的问题
调试	经调试,hSolution没能继续执行它的原因有好几种:
	第1种情况: 有时候是hDemand在TCPlan时,已经ActNo掉了,导致激活不到
	第2种情况: 有时候是TCPlan中,hDemand的baseRDemand同级竞争后,在TCScore中都是0分,导致二者执行到哪个随缘;
结果	干脆把TCPlan迭代下V2,它很久没迭代了,其实老以前的做法太老旧不适用了 转下节;
追加	后来在迭代TCPlanV2后回测此BUG好了 参考32073-回测;

总结：用搬运训练暂停，等下节把TCPlanV2写后，在下下节继续搞“用搬运”。

---

n32p07 迭代TCPlanV2

CreateTime 2024.07.11

TCPlan已经很久没迭代了,它当时的竞争设计,放在现在其实明显不足了:

1. 旧: 前几天尝试打日志观察它的竞争过程,原来是纯粹的"综合评分"来竞争的;
2. 新: 但现在像Canset池是支持实时竞争的 (我们用不着它那么复杂的去掉综合评分); 所以本节,思考一下,是否直接迭代下TCPlanV2,看重新设计一下它的竞争机制;

32071	初步规划迭代
分析	工作记忆中,大概就三种分枝: Canset池,R子任务,子H任务;
1	canset池有实时竞争功能,不需要TCScore再做综合评分;
2	R子任务间有进度分排序,也不需要综合评分做竞争;
3	子h任务在推进中的alg只一条,不需要竞争;
问题1	R子任务的负分仍然存在,用不用考虑到这些,否掉呢? (就像反思不通过,只是此处针对工作记忆整树来综合评定);
	> 如果这条有必要,那么还是需要综合评分;
	> 当然不需要每一条都综合评分了,而是把best做"整树反思"不通过(类似反思评价),即可;
问题2	R子任务用不用优先解决掉它, 比如:翻山前提前准备好防虎枪 T;
	> 感觉这种复杂的设想,其实借助最简单的Scene->Canset结构也是可解的;
	> 现在倒不必想这些,兴许到时候危险做为另外一个root,它的解就是准备好打虎枪;
	> 而原本的翻山任务,和危险任务,是两个root,压根不需要混合的做TCPlan规划一个解出来 (把事想复杂,往往难控制);
	> 思路: 1. 比如,我们把R子任务另起成一个Root,当它很强时(比如准备枪防止危险),自然会战胜它的源Root(翻山);
	> 2. 而这个另起的Root被解决后,源Root中自然也会因为传染唤醒机制,而变的不同(即不再有预测的危险);
	> 3. 翻山和安全其实也是竞争关系,如果是父子任务就不好竞争,但平级各当各的root好竞争 (比如为了安全不翻山);
	> 4. 并且解决安全后,翻山任务也可以继续推进了 (因为派生的安全任务有解了"有枪了,到时开枪吓跑老虎即可");
	> 5. 派生Root和普通Root不太一样: 派出任务的protoFo的后段是基于设想,而非普通Root是基于预测;
	> 所以: 这一条先不考虑,以后再支持,我们不优先解决R子任务 T;
	> TODO: 先把actionRegroup的反思算法关掉,等以后写的时候,再把建子任务改成建派生Root任务 T;
改动3	子任务(分枝叶)中有Finish或ActNo或传染掉时，不可激活。
	> 介入示例思考下,怎样让它又不激活无解的问题,又能不影响到像搬运坚果超时时的Canset推进;
	> 比如: 没钱时,不会再去买饭 & 步行去目的地超时了,仍会继续走下去;
总结	1. 本表通过近年来决策的变化,分析了3条TCPlanV1已经落后了的证据;
	2. 然后通过问题2跳过了R子任务,又把TCPlan简化了下;
结果	下一步,TCPlanV2的模型和实践转下表 T;

32072	模型图和代码实践
模型
说明	如上图,TCPlanV2是一个Root加多个Canset的结构,递归时,也是顺着这个结构一级级向回走;
	1. 如果单条失败就尝试下一条,找下一个baseDemand.bestCanset (重新实时竞争,得出最佳解);
	2. 如果单条成功就继续下一层,找下一个subDemand.bestCanset (继续实时竞争,得出最佳解);
	3. 如果全部失败就退至上一层,找上一个otherBaseDemand (重新实时竞争,得出另一个最佳解);
实践	结构较为简单,代码也清晰,所以直接看以上模型图和TCPlanV2的代码即可 T;
改进点1	当子枝叶全失败后,而当前bestFo是ActYes状态,才静默等待 (比如: 等饭熟,有苹果也会先吃一个垫垫);

32073-回测: 如下,经测每次生成hDemand后(A8616),立马在TCPlanV2后,可以执行到它的solution() `此问题参考32062`;
=============================== 9 hDemand ===============================
flt1 A8616(向140,距0,果)
TO上轮:成功 等待:0.0 下轮:7 消息:out 此帧需要HDemand来完成,已转为h任务
---------------------------------------------------------- START
* itemRoot -> 执行:F10124[↑饿-16]
  > item评分cansets竞争 -> 胜者:F3994[M1{↑饿-16},A3955(向90,距13,皮果),A3958(距89,向18,棒),A3961(向87,距27,棒),A3962(向90,距13,果),飞↑,A3970(向164,距71,棒),A3971(向90,距5,果),A3976(距73,向166,棒),A3979(吃1)]
    - itemHDemand -> 执行:A3955(4果皮)
      # item评分cansets竞争 -> 胜者:F8632[M1{↑饿-16},M1{↑饿-16},A8616(向140,距0,果),A3979(吃1),A8624(向334,距0,皮果),踢↑,A8629(向85,距9,皮果)]
        ⊙ itemHDemand -> 执行:A8616(4果)
planV2 success3 执行subHDemand的求解:A8616(4果)
---------------------------------------------------------- FINISH

---

n32p08 用搬运（二）

CreateTime 2024.07.13

在上上节中，测用搬运最终被TCPlanV2阻搁了，本节继续搞这一训练。

32081	训练: 用搬运 (参考32013-训练项7)
训练项7	用搬运: 使用搬运 (主动有目的的踢坚果);
步骤	FZ968,饿,等看到距0有皮果动机后,扔距0带皮果 -> 然后看它自己把坚果踢到路上;

32082	场景能提供的条件: 来引导推进测试
问题	无皮果动机,原本无皮果所在的Canset是能优胜的,但后来随着别的训练后,又没法优胜了(它其间又有几次S发生了);
分析	从无皮果动机->有皮果动机->距0有皮果动机,难道智能体正好依次让这几个所在的Canset优胜吗?
思路	这三步,必然没法都优胜,这种理想化情况是不现实的;
	那么: 有没有另外一种场景下,另外的几步也可行呢?那么难道我们也要让B场景下的这几步依次优胜?这也不现实;
线索	说白了,各种场景下,能让各自能优胜的情况是不同的,即关键在于各场景下能提供的外在条件不同;
方案	那么,让场景下能提供什么来决定即可 (比如: 并不是带皮果能优胜,而是我们这个场景有带皮果提供给智能体);
	说明: 我们不需要改代码,原本Canste池就是支持实时反馈的,并且随着实时反馈,实时竞争也能实时切换优胜Canset;
实践	训练用搬运时: 也许不需要激活距0带皮果,只要它在canset池中了,就可以扔一个,帮助他在实时竞争中胜出;
结果	经测试,这是有效的,见20240715-把坚果踢到路上让压破皮.mp4

32083	用搬运不稳定的问题 (一)
说明	在上表中,把搬运跑通了(但不稳定,有时它想不到搬运,有时能想到),本表查下原因;
分析	通过以下代码段1到代码段4,来分析此问题的原因,分析结果转32084继续;

32083-代码段1: 通过观察日志看能不能看出有什么问题;
=============================== 3 hSolution ===============================
目标:A3955(向90,距13,皮果) 已有S数:0
H0. I<F3991 F10282[4棒,吃,踢↑,↑饿-16,4果皮,4果皮]> {0 = 3;1 = 5;}  (null):(分:0.00) [CUT:3=>TAR:5] //这里输出的只有一例;

=============================== 3 行为化Fo ===============================
H行为化中间帧下标 (4/5) A10269(向110,距0,皮果) from时序:F10439[A10209(向172,距131,棒),A3979(吃1),踢↑,M1{↑饿-16},A10269(向110,距0,皮果),A10269(向110,距0,皮果)]

=============================== 4 hDemand ===============================
flt1 A10269(向110,距0,皮果)

=============================== 5 hSolution ===============================
目标:A10269(向110,距0,皮果) 已有S数:0
>>>>>> hSolution 无计可施

1疑点: 这里生成子H是不是应该限一下层级,总不能不断循环吧,不断循环下去,子H也变味了;
1解答: 不必理这个,实测了下,一般也就循环最多两三层;

2疑问: 并且当时记得H迁移是依赖RSceneTree的,那么是不是导致了?它迁移不了?或者多层后,还能迁移输出的结果很少?
2解答: 实测一般H有一两层嵌套,但hSolution输出才0到2条结果,H解太少了,但它的迁移应该是在正常工作的(不然一条都不会有);
2追加: 转`n32p12`,会给本问题一个合理的解释;

3疑问: 经调试发现,现在这些hDemand的root都是: [饿]->{更饿},其实在期间已经扔了有皮坚果,场景已经有了变化,但它还是在跑这个root;
3分析: 现在root的持续性很强,持续root是不会因更饿的发生而过期失效的;
3方案1: 试下当旧Root全被传染时,使之彻底跪掉,换下一个新Root上继续求解;
      > 方案1线索: 所以要分析下,在理性上全被传染后,看要不要把这个root彻底跪掉,而不是总在它上面尝试解决整个饥饿问题;
      > 方案1思路: 其实场景早就变化了,应该过渡到新R场景下,来尝试求解,应该更能找到准确些的解 (场景匹配度高,是解决方案准确的前提);
      > 方案1举例: 起初饿了是想做饭来的,但看到冰箱有剩饭其实只要加热就可以;
      >>> 此时: 我们想的不再是饿了怎么加热,而是在家里冰箱边饿了时有剩饭怎么加热;
      >>> 所以: 在任务的推进过程中,R场景的及时更新,也会有助于找到更切合场景的解;

3方案2: 其实[饿]->{更饿},只是真的没解,也许训练经历一次,就可以有解的啦
      > 方案2: 正据: 刚改了TCPlanV2,也许之前的训练Canset全挂在别的Root下了,只是改了TCPlanV2后,它只在[饿]->{更饿}下在求解而已;

3结果: 经以下几个代码段实测分析,总是用[饿]->{更饿}并不影响推进解决任务 `此处不算问题`;
      > 至于场景的变化,及时同步到canset推进反馈中即可,对Root的变化没啥要求;

32083-代码段2: 继续观察日志,收集`用搬运`不稳定的线索;

任务分:-11.17 + 最终进度分:-0.00 = 总分:-11.17 	 任务:F11175[M1{↑饿-16}]
任务分:-11.17 + 最终进度分:-5.79 = 总分:-16.96 	 任务:F11175[M1{↑饿-16}]
任务分:-11.17 + 最终进度分:-8.58 = 总分:-19.75 	 任务:F11175[M1{↑饿-16}]
任务分:-11.17 + 最终进度分:-0.00 = 总分:-11.17 	 任务:F11175[M1{↑饿-16}]
//说明: 如上日志,F11175太容易战胜别的任务了:
//  > 一来它有时有进度分,它必胜;
//  > 二来它即使没进度分,它一身评分11.17,也是最高分;

=============================== 28 hDemand ===============================
flt1 A8187(向213,距16,皮果)
TO上轮:成功 等待:0.0 下轮:15 消息:out 此帧需要HDemand来完成,已转为h任务
任务分:-11.17 + 最终进度分:-0.00 = 总分:-11.17 	 任务:F11175[M1{↑饿-16}]
任务分:-11.13 + 最终进度分:-0.00 = 总分:-11.13 	 任务:F11219[A11181(向85,距0,皮果),M1{↑饿-16},A11181(向85,距0,皮果),M1{↑饿-16}]
任务分:-9.72 + 最终进度分:-0.00 = 总分:-9.72 	 任务:F11184[M1{↑饿-16},M1{↑饿-16},A11181(向85,距0,皮果)]
任务分:-11.17 + 最终进度分:-0.00 = 总分:-11.17 	 任务:F11225[A11181(向85,距0,皮果),M1{↑饿-16},A11181(向85,距0,皮果),M1{↑饿-16}]
* itemRoot -> 执行:F11225[4果皮,↑饿-16,4果皮,↑饿-16]

//说明: 如上日志,多次发生饥饿,只有F11225侥幸胜利了,别的全败于F11175马下;

=============================== 28 rSolution ===============================
任务源:饿 protoFo:F11225[A11181(向85,距0,皮果),M1{↑饿-16},A11181(向85,距0,皮果),M1{↑饿-16}] 已有方案数:0 任务分:-11.17
R0. I<F3566 F3984[↑饿-16,4果皮,4棒,4棒,4果,飞↑,4棒,4果,4棒,吃]> {0 = 0;} {9 = S0P16;5 = S0P19;1 = S3P20;10 = S0P2;6 = S0P16;2 = S0P19;7 = S0P16;3 = S0P19;8 = S0P16;4 = S0P19;} H4N2:(分:0.67) [CUT:0=>TAR:10]

//说明: 如上日志,F11225战胜后,执行了rSolution,并且输出F3984的Canset结果;

=============================== 29 行为化Fo ===============================
R行为化中间帧下标 (1/10) A3955(向90,距13,皮果) from时序:F3984[M1{↑饿-16},A3955(向90,距13,皮果),A3958(距89,向18,棒),A3961(向87,距27,棒),A3962(向90,距13,果),飞↑,A3970(向164,距71,棒),A3971(向90,距5,果),A3976(距73,向166,棒),A3979(吃1)]

=============================== 30 hDemand ===============================
flt1 A3955(向90,距13,皮果)
TO上轮:成功 等待:0.0 下轮:16 消息:out 此帧需要HDemand来完成,已转为h任务

//说明: 如上日志,想得到距13皮果,用场景中现有的距0皮果去`踢搬运`即可;

32083-代码段3: 继续观察日志,收集`用搬运`不稳定的线索;
* itemRoot -> 执行:F11175[↑饿-16]

//说明: 如上日志,F11175战胜了别的Root;

=============================== 21 hSolution ===============================
目标:A3955(向90,距13,皮果) 已有S数:0 任务层级:2
取HCanset候选集: 从hScene:F4119(I) 的在4帧开始取,取得HCanset数:2/2
	(F8236[↑饿-16,4果皮,4果皮,踢↑,4果皮,4棒,4棒,4果],F8250[↑饿-16,4果皮,4果皮,踢↑,4果皮,4棒,4棒,4果,飞↑])
	 item场景(I):F3629[M1{↑饿-16}] 取得候选数:0
fltx1 此H的sub到root结构:
︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹︹
ReasonDemandModel: F11175[M1{↑饿-16}]-> (普 | ActYes)
   ↑
TOFoModel: F3987[M1{↑饿-16},A3955(向90,距13,皮果),A3958(距89,向18,棒),A3961(向87,距27,棒),A3962(向90,距13,果),飞↑,A3970(向164,距71,棒),A3971(向90,距5,果),A3976(距73,向166,棒),A3979(吃1)]-> (普 | ActYes) 唤醒
   ↑
TOAlgModel: A3955(向90,距13,皮果) (普 | ActYes)
   ↑
HDemandModel
︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺︺
第2步 H转为候选集:2 - 中间帧被初始传染:0 = 有效数:2
第5步 HAnaylst匹配成功:2
第6步 H排除Status无效的:2
第7步 H排除Infected传染掉的:2
H0. I<F4119 F8236[↑饿-16,4果皮,4果皮,踢↑,4果皮,4棒,4棒,4果]> {0 = 0;} {1 = S2P0;} (null):(分:0.00) [CUT:0=>TAR:7]
H1. I<F4119 F8250[↑饿-16,4果皮,4果皮,踢↑,4果皮,4棒,4棒,4果,飞↑]> {0 = 0;} {1 = S1P0;} (null):(分:0.00) [CUT:0=>TAR:7]

//说明: 如上日志,但它的Canset最终也输出H皮果了,并且求到了HCanset踢皮果的解 (不过CUT=0,TAR=7);

=============================== 23 行为化前 反思评价 ===============================
任务分:-11.17 + 最终进度分:-8.58 = 总分:-19.75 	 任务:F11175[M1{↑饿-16}]
> F8236行为化前 的 子任务分:-7.65 > 当前任务分(饿):-19.75 =====> 已通过

=============================== 23 行为化Fo ===============================
H行为化中间帧下标 (1/7) A8187(向213,距16,皮果) from时序:F11216[M1{↑饿-16},A8187(向213,距16,皮果),A8191(向192,距0,皮果),踢↑,A8196(向107,距9,皮果),A8202(距87,向18,棒),A8214(距26,向93,棒),A8215(向107,距9,果)]

//说明: 如上日志,它轮到行为化A8187有皮果了: 这里关键在于,没有干干净净的[距0皮果,踢,距13皮果];
//线索: F11175总是胜利,应该不是问题,但没有生成抽象的踢经验,才是问题;

32083-代码段4: 通过H任务的生成,观察日志变化;
1. flt1 A3955(向90,距13,皮果)
2. flt1 A10269(向110,距0,皮果)
3. flt1 A3958(距89,向18,棒)
4. flt1 A3955(向90,距13,皮果)//这个和第1个循环了;
5. flt1 A8187(向213,距16,皮果)
6. flt1 A3958(距89,向18,棒)
7. flt1 A8187(向213,距16,皮果)//这个和第5个循环了;
8. flt1 A3955(向90,距13,皮果)//这个和第1个,第4个循环了;

//说明: 如上日志,感觉它左突右试,但因为Canset太具象,导致总是难反馈到;
//1. 一是想要的,与现在能给的,要匹配上 (比如想要距0皮果,立马就能反馈到,现在场景里有);
//2. 二是要多生成absCanset,这样排除杂项后,才能干净利落的推进Canset解决任务;
//3. 如上日志,许多H任务是有循环的,应该避免循环这种无意义的增加层;

32084	用搬运不稳定的问题 (二)
简介	从以上几个代码段来分析,大致就是各种混乱收束的不够,导致用搬运能不能顺利跑起来,非常不稳定;
说明	经过上表代码段1-代码段4的分析,将分析结果总结到此表:
1	Canset不够抽象,杂项较多,导致左突右破,难以成功;
	回顾: 在30152中,其实遇到过类似Canset太具象杂项太多的问题,最后的方案也是做连续视觉,只是当时时机尚不成熟;
	分析: 这个看起来需要长时间积累,短时间很难把杂项剔除干净;
	思路: 但我们不能总指挥它,即使前期也应当能自己试错后跑通,然后随着跑通的次数变多,自行剔除掉杂项;
	解答: 即前期经验本来就有杂项,允许它多想多试错即可,而通过多试错后 => 可以抽象剔除杂项,并且不再需要想太多,精准直击目标;
2	场景中即使有坚果,也无法及时反馈到Canset中 (视觉不连续);
	正据: 看来,只有连续视觉,能让它快速推进和接受反馈,让canset们活起来,而不是一嵌套一个子任务却搞半天全是没反馈;
	所以: 为了使工作记忆能快速响应起来 转n32p10 正式开始做连续视觉;
3	H一直在嵌套了好多层,导致有重复H求解的情况 (同一个H目标,套娃求解) (参考代码段4) T;
	比如: 比如找奶油做蛋糕,又找蛋糕取上面的奶油;
	解答: 在这种有循环的情况下,应该打断H嵌套 (对于重复的,不必生成子H任务,实时竞争里直接过滤掉,不做为bestCanset输出);
	实践: 可以考虑到realTimeCansets实时竞争中,把curFrame已经有baseHDemand重复的,直接pass过滤掉 T;
结果	1不急,等2成了自然能好,3已经改了 第2条-转n32p10继续搞 T;

---

n32p09 "搬运,去皮,飞至,吃掉": 连起来跑通

CreateTime 2024.07.15

本节原本计划连起来跑跑,但后来因为上节用搬运不稳定的问题,转下节先解决连续视觉,然后等用搬运稳定后,再来测连起来跑吧;

---

n32p10 连续视觉

CreateTime 2024.07.16

在n32p08时,测得: 视觉提供和视觉需要之间的矛盾: 说明: 即我前一秒触发看到了坚果,后一秒TO思维才需要坚果,我面前明明有坚果,但反馈不上

1. 现在场景的输入,和思维的速度,是不同步的,
2. 它应该会有先后问题, 即: 提前看到了,后面才需要这个反馈的;
3. 即使有: 传染机制,这个应该也有问题 (它就是在需要时反馈不到); 结果: 先解决32083的问题,完后看下用搬运训练是否顺利,如果不顺利,或者遇到任何确实需要连续视觉的地方,此处再继续; 注: 其实连续视觉这事提过许多次了,但需求都没有明确下来,它往往是看起来需要,但不做也没绝对的影响到训练无法推进,所以一直没搞;

32101-做连续视觉的起因:
起因1: 在32084-1 & 32152中,遇到了Canset因太具象杂项过多,导致其推进困难,而解决方法之一就是连续视觉,助其推进;
起因2: 参考32084-2,因为现在的Canset一切就绪,就是各种嵌套一堆子任务,但却没几个反馈进来,Canset也没能快速推进下去;
起因3: 即使现在场景中早就有一个有皮果在那儿了,它也没视觉,没反馈,导致工作记忆中尽是些半天没推进一帧的Canset;

32102	连续视觉都需要改什么之: input与TI循环着跑;
TODO1	在TI线程加上触发连续视觉 T;
	说明: TC.commitInput有三处,然后输入前需要MainQueue,输入后需要TIQueue,导致它很难写成while单循环;
	所以: 我们可以写成AITimer触发器,那三处TI执行,分别各自打上runing状态,当三个runing都为false时,才跑下次触发即可;
结果	改完TODO1后,可以顺利看日志,它已经具备连续视觉了;

32103	连续视觉都需要改什么之: 瞬时记忆长度会很长的问题;
TODO2	在瞬时记忆长度限制4的规则: 相邻疑似同概念帧计做一条 (根据相似度或抽具象关系程度判断) T;
	实测: F12715[A12660(向176,距0,皮果),A12660(向176,距0,皮果),A12660(向176,距0,皮果),A12660(向176,距0,皮果)]
	说明: 如上日志,在支持连续视觉后,连续好多帧,都是一模一样的A12660;
	分析: 概念识别应该执行,然后如果前后两帧识别结果matchAlgs的交集程度很大,应该计为一帧吗?
	比如: 有一只狗走过来,距离远时没什么,靠近后危险,狗还是那只狗,概念识别也没什么区别,只是时序上识别和预测不同;
	思路: 整个狗走近的过程,要记录吗?按道理来说,其实是需要记录的,只是在概念的感知上,没那么大差异而已;
	方案: 把瞬时记忆限制4条,加外规则: 相邻matchAlgs交集率高于30%的计为一条 (如: 木木果果果木飞 = 4条);
结果	改完TODO2后,经回测新的保持四条不同概念规则ok T;

---

n32p11 用搬运（三）

CreateTime 2024.07.20

上节改了连续视觉,本节再测下用搬运,看反馈能不能都及时跟上,使canset的推进能更顺利的推进;

32111-回归测"用搬运"训练
1. 本表训练方式: 看工作记忆需要什么,我们就提供什么,看连续视觉能不能及时提供给它;
2. 测试日志说明: flt1是生成hDemand flt2是feedbackTOR反馈到了 flt3是输出"用搬运"踢行为成功

//1. 此处生成了距0皮果需求;
flt1 A3955(向90,距13,皮果) from:F3991[M1{↑饿-16},A3955(向90,距13,皮果),A3958(距89,向18,棒),A3961(向87,距27,棒),A3962(向90,距13,果),飞↑,A3970(向164,距71,棒),A3971(向90,距5,果),A3976(距73,向166,棒),A3979(吃1)]
flt1 A10269(向110,距0,皮果) from:F13609[A10209(向172,距131,棒),A3979(吃1),踢↑,M1{↑饿-16},A10269(向110,距0,皮果),A10269(向110,距0,皮果)]

//2. 此处扔距0皮果后,也反馈成功了;
flt2 R feedbackTOR反馈成立:A3955(向90,距13,皮果) 匹配:1 baseCansetFrom:F3991[↑饿-16,4果皮,4棒,4棒,4果,飞↑,4棒,4果,4棒,吃] 状态:CS_Besting
flt2 H feedbackTOR反馈成立:A10269(向110,距0,皮果) 匹配:1 baseCansetFrom:F10282[4棒,吃,踢↑,↑饿-16,4果皮,4果皮] 状态:CS_Besting
flt2 H feedbackTOR反馈成立:A10269(向110,距0,皮果) 匹配:1 baseCansetFrom:F10282[4棒,吃,踢↑,↑饿-16,4果皮,4果皮] 状态:CS_Besting

//3. 此处它输出了踢行为;
flt3 踢↑

//4. 此处距9皮果反馈也成功了;
flt2 R feedbackTOR反馈成立:踢↑ 匹配:1 baseCansetFrom:F10179[↑饿-16,4果,吃,4果皮,踢↑,4果皮,4棒,4棒,4果,飞↑,4棒,4果,4棒,吃] 状态:CS_Besting
flt2 R feedbackTOR反馈成立:A8629(向85,距9,皮果) 匹配:1 baseCansetFrom:F10179[↑饿-16,4果,吃,4果皮,踢↑,4果皮,4棒,4棒,4果,飞↑,4棒,4果,4棒,吃] 状态:CS_Besting

//5. 此处生成了木棒需求 (乌鸦想让它压破皮);
flt1 A3958(距89,向18,棒) from:F3991[M1{↑饿-16},A3955(向90,距13,皮果),A3958(距89,向18,棒),A3961(向87,距27,棒),A3962(向90,距13,果),飞↑,A3970(向164,距71,棒),A3971(向90,距5,果),A3976(距73,向166,棒),A3979(吃1)]

//6. 问题: 但扔出木棒后,它没反馈到木棒;
//方案1: 试下,在木棒反馈失败时,也把后面的流程走了 (去皮后,上飞,吃掉),然后看它能不能触发canset类比抽象,把木棒抽象下;
//方案2: 不行就把被动视觉也打开吧先,毕竟现在1s的视觉间隔有点久,有时还没看见无皮果呢,已经反射反应吃掉了;
//结果: 方案2经实践可行,将训练结果存为:FZ969;
//问题: 但期间很少执行到absCanset类比,并且整个任务求解过程也并不那么规律,下表针对每一步solution都盯下日志,看盯细节方式,能不能把整个求解过程捋顺当些 `转32112`;

小结: 上表制定了,先降低难度试下: 即边盯它的H需求,边顺着让现实世界满足它, 然后看下整个工作记忆的思考过程,能不能满足"用搬运"?

32112	细盯每一步求解过程: 捋顺求解过程;
关注点1	关注一下Canset在接受反馈后的,cutIndex及时推进,并影响到Canset的实时竞争;
关注点2	关注下absCanset,使更抽象更稳定的解能慢慢在竞争和经历中优胜劣汰的浮现出来;

小结: 上表分析了当前训练的重点关注点: 一是Canset的推进,二是Canset的竞争;

32113	RSolution的结果中,P很大,S很小,这比较可疑,查下有没问题
比如	R0. I<F3531 F3991[↑饿-16,4果皮,4棒,4棒,4果,飞↑,4棒,4果,4棒,吃]> {0 = 0;} {0 = S1P0;9 = S0P16;5 = S0P21;1 = S3P23;10 = S0P2;6 = S0P16;2 = S0P21;7 = S0P16;3 = S0P21;8 = S0P16;4 = S0P21;} H5N0:(分:1.00) [CUT:0=>TAR:10]
说明	它怎么这么多P?不应该啊,这玩意儿S一个没,P却有16个?查下原因,应该是SP有点重复的计数了;

小结: 上表发现可疑点: S很小P很大,但还没具体查,随后查后再更新此总结;

32114	提升工作记忆可视化
作用	可视化可以(方便调试)
方案1	能不能把每一层工作记忆canset拼起来,拼成一个,然后把cutIndex也打印成一个,这样能更直观的,看到它想要什么,要到哪了;
方案2	工作记忆是不是也应该打印出编号来: 方便观察它的变化: 每一层的枝叶打个编号(比如第3层第5个Canset计为:3-5-Fxxx);
方案3	直接把root->sub这一条TCPlan激活的工作记忆线打成一条flt日志 本方案更直观,很简单就可实现;
抉择	方案2比方案1好,它直观的表达了每一层枝叶的进度和子枝叶,方案3更好,每一枝叶的pointerId就是它的编号 T 已实践;

小结: 上表用一条日志的简单方式,实现了工作记忆可视化,等以后需要更多的可视化时再说,目前这么做就够用了;

---

n32p11b 迭代-学Canset触发机制(更易发)

CreateTime 2024.07.2x

本节把NewRCanset,NewHCanset,AbsRCanset,AbsHCanset四处构建,改的学Canset更易发;

32115	提升抽象程度
问题	现在的AbsCanset执行太少了,应该提升下;
比如	经调试看到有时RCanset有两个棒,然后才压破皮,看能不能抽象一下?让这种太细节的具象抽象掉;
调试	见32115-代码段1: 所有激活的Canset都很具象;
线索	查为什么Canset类比触发的少? (如果每反馈成功，canset实时竞争都大几率变一条,这导致类比太少?);
方案1	如果besting经常因此变成bested状态,那么bested是不是也应该参与类比抽象？
	> 经实测,第1层Root稳定,第2层RCanset略稳定,第3层后面就完全不稳定了,随时会变化,即使最终反馈了,也可能已经bested了;
	> 所以方案1的经常变的问题是存在的,只是此方案要继续深入分析下 转32117-Canset同效类比;
方案2	要不要给Canset评分也加上进度分,使之像Root竞争时一样能稳定激活和推进 转32116;
	> 说明: 因为只有Canset稳定了,就更容易触发类比抽象 (因为会一直是besting状态);
结果	本表方案1转了32117,方案2转了32116 T;

32115-代码段1: flt1表示每一次行为化日志 (比如下面第一条表示正在行为化R任务的解RCanset=F3991,当前行为化帧=A3955);
//说明: 由下日志可见,每一条Canset都很具象,不够抽象;
flt1 A3955(向90,距13,皮果) fromR:F3991[M1{↑饿-16},A3955(向90,距13,皮果),A3958(距89,向18,棒),A3961(向87,距27,棒),A3962(向90,距13,果),飞↑,A3970(向164,距71,棒),A3971(向90,距5,果),A3976(距73,向166,棒),A3979(吃1)]
flt1 A3958(距89,向18,棒) fromR:F3991[M1{↑饿-16},A3955(向90,距13,皮果),A3958(距89,向18,棒),A3961(向87,距27,棒),A3962(向90,距13,果),飞↑,A3970(向164,距71,棒),A3971(向90,距5,果),A3976(距73,向166,棒),A3979(吃1)]
flt1 A15068(距0,向106,皮果) fromH:F15425[M1{↑饿-16},A15068(距0,向106,皮果),A15068(距0,向106,皮果),A15079(向20,距70,棒),踢↑,A15085(距24,向80,棒),A15086(向92,距11,皮果),A8504(距24,向88,棒),A15092(向92,距11,果)]
flt1 A5601(距87,向17,棒) fromR:F15432[M1{↑饿-16},M1{↑饿-16},A1829(距33,向140,皮果),A5601(距87,向17,棒),A5606(距26,向86,棒),A4153(向88,距12,果),飞↑,A5620(向170,距111,棒),A4031(向83,距0,果),A5629(向172,距113,棒),A3979(吃1)]
flt1 A5601(距87,向17,棒) fromR:F15432[M1{↑饿-16},M1{↑饿-16},A1829(距33,向140,皮果),A5601(距87,向17,棒),A5606(距26,向86,棒),A4153(向88,距12,果),飞↑,A5620(向170,距111,棒),A4031(向83,距0,果),A5629(向172,距113,棒),A3979(吃1)]
flt1 A4148(距77,向19,棒) fromR:F15459[M1{↑饿-16},A4134(向88,距12,皮果),M1{↑饿-16},A1829(距33,向140,皮果),A4148(距77,向19,棒),A4152(距24,向86,棒),A4153(向88,距12,果),飞↑,A4169(向173,距135,棒),A4170(向84,距0,果),A4178(距138,向174,棒),A3979(吃1),飞↑]
flt1 A5601(距87,向17,棒) fromR:F15432[M1{↑饿-16},M1{↑饿-16},A1829(距33,向140,皮果),A5601(距87,向17,棒),A5606(距26,向86,棒),A4153(向88,距12,果),飞↑,A5620(向170,距111,棒),A4031(向83,距0,果),A5629(向172,距113,棒),A3979(吃1)]
flt1 A4148(距77,向19,棒) fromR:F15459[M1{↑饿-16},A4134(向88,距12,皮果),M1{↑饿-16},A1829(距33,向140,皮果),A4148(距77,向19,棒),A4152(距24,向86,棒),A4153(向88,距12,果),飞↑,A4169(向173,距135,棒),A4170(向84,距0,果),A4178(距138,向174,棒),A3979(吃1),飞↑]

32116	Canset类比太少问题-方案2: Canset加上进度分,避免太多变
问题	Canset如果太多变的话,它就没法更好的触发类比抽象;
方案	把Canset也加上进度分加,让原本有优势的,变的更有优势;
实践前	先验证一下Canset确实因为反馈和进度,导致了变化太多,Canset一直变;
反思	感觉进度分,可能不是个好的解决方案,一来不行就是不行被actNo掉,二来整个canset池应该是同权的(同时会有一批推进一帧);
结果	加进度分感觉有点治标不治本,即使进度分使它稳定了,因为太具象导致某帧不可行,还是有Canset稳定的问题 T 先搞下表;

32117	Canset类比太少问题-方案1: 把Canset改成同效类比
回顾	以前SceneFo一直是同效(同mv指向)来触发类比的,而Canset现在类比太少,也可以同理解决下;
方案	在RCanset有效果时(无负mv反馈)计为同效,在HCanset有targetAlg反馈时计为同效,同效触发Canset类比;
说明	其实现在大致也是同效类比的,只是加了besting的判断;
TODO1	可以先在代码核实下,哪些不是同效触发类比,改一下;
	1. 经查,现在R任务的有效判断有问题,转32118;
	2. 经查,现在H任务的有效判断看起来没啥大问题 转32119 实际核实下代码;
TODO2	包括已经判断同效后,还在做besting状态判断,或者别的什么判断门槛都可以取缔下 转3211a;
TODO3	方便调试: 可以类比时,把抽象层级记录到foNode里,然后使用时把抽象层级打出来方便调试 T 先不搞;
	> 这一条暂时不做,毕竟abs抽象不抽象,通过:概念是抽层还是交层 或 时序元素杂不杂,这些也可看出来;

小结: 这三张表主要做:Canset不够抽象问题,最终集中在32117,对方案1进行实践;

32118	New&AbsRCanset触发机制有问题 (参考32117-TODO1);
现代码做法	pFo的中间帧或末帧,没反馈时(即pFo中断了),调用pushFrameFinish(),进行New&AbsRCanset;
现做法问题	事实上,pFo的中断,不一定就是问题解决了,如下两种情况 (1是没用判断成有用,2是有用判断成无用):
情况1	中间帧中断,可能表明,即使没这一帧,它依然可能有"负mv"发生 (即: 没用判断成有用)
	比如: 原本pFo是[狗,叫,咬,疼],现在成了[狗,咬,疼],虽然狗没叫,但不表示这有效,它依然咬且疼了;
	思路: 所以应该改成,以判断rDemand被解决为标准,而不是中间帧中断为标准;
情况2	末帧即使没中断(发生负mv反馈),也不表示RCanset无用 (即: 是有用判断成无用);
	比如: 还没做好饭,不表示做饭的RCanset解决不了饥饿需求,它只是还在做,而你在做的过程中你更饿了而已;
	实例: 现在往往超过8s已经更饿了,后才解决的饥饿问题,而此时即使解决了,也触发不到New&AbsCanset,这显然不对;
方案	应该改下判断机制,判断R任务被有效解决的方式改一下,现在的做法有以上两个问题,是不对的;
	判断机制: (对R有效) = pFo被解决 = rDemand被解决 (所以rDemand任务解决,即有效,可触发New&AbsRCanset);
TODO1	对于持续R任务: 比如饥饿R任务现在是连续饥饿状态,所以只能以饥饿状态的减弱为判断 (即正mv输入) T;
TODO2	对于非持续R任务: 当它的所有pFo全没反馈负mv时,再为其触发New&AbsRCanset (即所有pFo没有负mv输入) T;

32119	New&AbsHCanset的触发机制也核实下有没问题 (参考32117-TODO1);
经核实	现在NewHCanset全是在feedbackTOR反馈成立的时候,才会调用,这个触发机制没有问题 T;
经核实	现在AbsHCanset是在整个hCanset推进完成时才会触发,这个有问题,如果hCanset.Target提前完成,也应该类比抽象;
	说明: 即AbsHCanset应该支持targetAlg的提前反馈完成,而不必非要一帧帧推进过去;
TODO1	feedbackTOR时,提前判断下对每个hCanset的targetAlg是不是匹配了,如匹配则调用下hCanset的类比抽象 T;
	细节: hCanset的targetAlg匹配,也就相当于hScene(也就是rCanset)的actIndex匹配;
	所以: 改由rCanset.actIndex来触发看起来代码逻辑更简约些 (直接匹配到时,把所有激活过的hCanset全类比抽象一下);

3211a	把NewAbsRHCanset的不必要条件全取缔掉
目标	目标是让无论NewRHCanset还是AbsRHCanset都能频繁学起来,而不是零星几条;
分析	可以把New&AbsCanset算法的: cansetStatus和status判断取缔掉,改成canset池前10条都参与类比什么的;
NewH	看现在代码,NewHCanset没啥问题,只要CutIndex反馈成立,现在除了CS_None会拦截不跑,别的全会跑NewHCanset;
AbsH	看现在代码,AbsHCanset没啥问题,只要HTargetAlg反馈成立,现在除了CS_None会拦截不跑,别的全会跑AbsHCanset;
NewR	看现在代码,NewRCanset没啥问题,只要Demand确定R任务解决了,就不会有任何拦截的生成NewRCanset;
AbsR	改下代码,除了CS_None外,别的全进行RCanset类比抽象 T;
结果	四种构建Canset,有三种不用改,而需要改的一种:AbsRCanset已把不必要的条件过滤取缔了 T;

小结: 上三张表32118,32119,3211a主要实践:迭代使学Canset更易发 (调整触发机制 和 减少触发所需条件);

---

n32p12 HCanst学和用-知识结构整理

CreateTime 2024.07.29

在32083-代码段1中,在工作记忆中demand只有两层时,木棒皮果的H解,有大量只有: 0条或1条的情况 (参考32083),本节分析下这个问题的原因,给出解释(因为看起来它不是问题,所以只给出解释,而不是修复);

32121	问题回顾 (参考32083-代码段1-2疑问);
问题	当时实测看到,hSolution往往只有0到2条结果,非常少;
学时	经查,现在的step2_FeedbackThenCreateHCanset()中,只会给RCanset挂HCanset,而HCanset不会再嵌套HCanset;
用时	而hSolutionV3中,也是借助R场景树,在RCanset下取HCanset,而不是嵌套多层H取HCansetFrom的;
正据1	这么做无可厚非,因为多层HScene,早就脱离了当前场景,现在只搞一层RCanset和一层HCanset的做法没啥问题;
正据2	而现做法,每次思维循环都另从RCanset中取HCanset,也很灵活,相当于把不嵌套的长时记忆,生成工作记忆的可以嵌套;

---

n32p13 回测-学Canset触发机制(更易发)

CreateTime 2024.07.30

在n32p11b中,迭代了学Canset触发机制(更易发),本节回测之;

32131	回测学Canset触发机制
说明	回测下四个”学Canset”改进了触发机制,重新训练下后几步(学各种Canset),打日志看能不能更容易学到;
试下	或者在原来的基础上,直接训练试一下;

32132	BUG: AbsRCanset经常类比出空概念(现在空概念应该没什么用了,不应该出现),查下原因;
调试日志1	(mIsC成立): alg类比 ===> M1{↑饿-16} : A3955(向90,距13,皮果) = A9585()
	> 打了断点,发现FZ968已经有这个问题了,FZ967时还没事;
调试日志2	(mIsC成立): alg类比 ===> A4467(向92,距12,果) : A3967(飞↑) = A8471()
	> 打了断点,发现FZ965已经有这个问题了,FZ964时还没事;
原因	如上日志,经测发现M1(饥饿)和A3955(皮果)判断mIsC成立,导致的;
查1	打日志查下,这个错误的抽具象关联是哪生成的;
	测试: 先回退到没问题的记忆,然后再跑跑后面的训练步骤,看能不能复现;
查2	如果这个关联是在知识模糊的初期阶段产生的,那么可以考虑及时加入末尾淘汰机制 (遗忘机制 或 只激活前80%机制);
结果	索性把913之后的步骤重新训练下,转下表进行FZ97的训练;
	> 在训练过程中,观察一下Canset有没更频繁的执行,以及还有没抽具象关联错误的问题;

---

n32p14 训练FZ97

CreateTime 2024.08.02

在上节末,测得抽具象关联有错误,本节重新进行训练,观察能不能复现,重新进行FZ974之后的训练 (训练步骤参考n32p01b); 追加: 在本节训练FZ97过程中,此关联错误的BUG未复现,再观察一段时间,如果还没有,就不用管了;

32140	本次训练主旨特点
原则	本次训练与上次不同: 上次主要进行完美递归父子任务,而这次是在多向推进中,左突右进找出突破口

小结: 32140为本节测试方式点明了大致方向

32141	在FZ913基础上接着继续后面的步骤-训练项1 (参考32013)
训练项1	测下newRCanst,absRCanset,newHCanset,absHCanset四个都能执行到 在31183完成过,此处重训练下;
	> FZ974: 跑三四次路下出生,饿,路上扔带皮果,扔棒去皮,手动飞至,触发吃掉,存为FZ974;
	> 结果1: 前4次训练,快跑了下,然后NewRCanset,AbsRCanset,NewHCanset都执行到了;
	> 结果2: 跑5和6次时,慢跑了下(有了木棒HDemand后再扔木棒),然后AbsHCanset也成功了,并且这两次都是它自行上飞吃坚果的;
	> 下一步计划1: 训练项2和3应该没必要了,现在的训练不再要求那么理想化的几层任务嵌套 (参考32082-思路);
	> 下一步计划2: 而我们要在非理想化的情况下,也能够推进下去,所以直接跳过2和3,执行训练学搬运;
	> 下一步计划3: 因为本次测试主要针对多向推进,在左突右进中找突破口,所以无皮果和有皮果动机不测了,下面直接测学搬运;

小结: 32141测试了四个Canset构建 (且都通过了)

32142-BUG: 查下传染机制是不是有问题:
问题: 在上表训练项1完成后,尝试进行训练项2,结果发现,试错机制似乎有点问题,一直在试错H棒(如下日志),可是试一次不就行了?它为什么没被传染掉,会一直反复试;
说明: 中间帧超时未反馈,但没传染
日志: 如下日志,A4101出现了N次,但其实它应该已经被传染了,不应该一次次的激活 (但这里却这么多次激活了);
原因: 经查,因为frameActYes帧等待超时触发后,状态为ActYes才会传染,而此时它也可能是WithOut状态(被别的子任务向root传染成WithOut状态的);
TODO1: 把frameActYes触发后,改成只要不是OuterBack状态则会传染 (除非在feedbackTOR中已改成OuterBack状态);
TODO2: 在hDemand无解时(WithOut),如果targetAlg已经是OuterBack状态(已反馈),则不传染成WithOut状态;
回测: 发现修了TODO1和TODO2后,还是有问题;
再查: 经调试,发现未触发的原因,并不全是状态问题,因为RCanset在besting后,触发器要3s左右,而3s内它已经又变成bested了;
线索: 即,Canset并没有持续性推进(很快变成bested了),导致它没等到触发就被打断了;
  1. 有反馈时: 在前面一两节中,我们在优化学canset触发机制时,已经改了:它`有反馈时`,即使任务csStatus和bestStatus怎样,都能反馈到;
  2. 无反馈时: 本表遇到的问题是,它`无反馈时`,还是应该保持besting的,因为说白了: **没有持续推进,就不会知道它是否真的不可行**;
所以: 还是先查下,为什么它变成bested了,能不能保持其besting状态,再调试如下:
再查: 经查,每一次生成H棒后,在TCPlan中它都稳定激活了,只是这个H棒在hSolution中,都没找到解,导致这个任务立马就WithOut噶了;
线索: 只在FZ974中训练了6次饥饿时带皮果去皮吃掉,所以木棒动机可能压根没出现过,或者即使出现也没feedbackTOR反馈上过,无解挺正常的;
思路: 那么我们有3个方案,可以来解决此问题;
方案1. 没解就学个解: 能不能加训下,使`H棒`学到解 (有个念想也可以,比如:每次绿灯时,汽车总会冲过来) `5%`;
      > 方案1是在绕大圈(先有解,再解不了,再传染),所以方案1虽也不错,但我们不必绕此大圈;
方案2. 本就不必有解: H无解本身就应该触发传染,它都WithOut了,直接调用传染即可 `20%`;
      > 方案2更直观直接简单(即无解时,直接传染) (在H任务无解时(WithOut),直接调用传染);
方案3. 不管有没有解: 无论H是否无解(即使无解,变成了bested状态),在frameActYes()中,下一帧的SP和传染依旧执行 `95%`;
      > 原则: **成功有途,失败无途**,只要失败了,不必为失败找任何借口,直接计S和传染即可;
      > 方案3更直白简单,因为下一帧无论是否转为WithOut无解,或者因无解转成bested了,它都应该照样执行SP和传染`无解: 即=S,即=传染`;
抉择: 最终选定方案3,即是否无解转成bested状态,不影响下一帧的frameActYes()触发;
TODO3: 把frameActYes()中触发后,判断besting状态的逻辑删除掉即可 (参考方案3&原则) `T`;
flt1 A4101(距90,棒) fromR:F5212[A4101(距90,棒),A4098(距12,果),飞↑,A4096(距0,果)]
flt1 A5069(向172,距185,棒) fromR:F5211[A5042(向84,距14,果),A5056(向171,距172,棒),A5042(向84,距14,果),M1{↑饿-16},A5069(向172,距185,棒),A5042(向84,距14,果),飞↑,A5077(向77,距6,果)]
flt1 A5214(向172,棒) fromR:F5215[A5066(距11,果),A5067(向171,棒),A5066(距11,果),M1{↑饿-16},A5214(向172,棒),A5066(距11,果),飞↑,A5213(向80,果)]
flt1 A4101(距90,棒) fromR:F5212[A4101(距90,棒),A4098(距12,果),飞↑,A4096(距0,果)]
flt1 A5069(向172,距185,棒) fromR:F5211[A5042(向84,距14,果),A5056(向171,距172,棒),A5042(向84,距14,果),M1{↑饿-16},A5069(向172,距185,棒),A5042(向84,距14,果),飞↑,A5077(向77,距6,果)]
flt1 A4101(距90,棒) fromR:F5212[A4101(距90,棒),A4098(距12,果),飞↑,A4096(距0,果)]
flt1 A5069(向172,距185,棒) fromR:F5211[A5042(向84,距14,果),A5056(向171,距172,棒),A5042(向84,距14,果),M1{↑饿-16},A5069(向172,距185,棒),A5042(向84,距14,果),飞↑,A5077(向77,距6,果)]
结果: 最后只是把传染时的一些不必要状态要求取消掉了而已 (TODO1看起来必要,但最后是改了TODO3后才彻底好的);
回测: 如下日志可见,现在木棒在传染后,就不会再出现了(等待传染的期间还是有可能重复出现的,比如:A4852),等一会是可以全部及时传染掉的,并且在试错一会后,发现木棒是无论如何不可行了,它也转向找皮果 (有了皮果动机);
flt1 A4101(距90,棒)
flt1 A3976(距31,向123,棒)
flt1 A4852(向172,距183,棒)
flt1 A4852(向172,距183,棒)
flt1 A4852(向172,距183,棒)
flt1 A4072(距42,向144,棒)
flt1 A4148(向91,距13,皮果)
flt1 A3955(距31,向216,皮果)
下步: 本表修复完成,回测ok,并且有了`皮果动机`,下一步回归FZ975继续训练;

小结: 在尝试跑一下训练项2时,测到传染触发机制的BUG,在32142中修好了;

32143	在FZ913基础上接着继续后面的步骤-训练项2 (参考32013)
训练项2	学搬运: 学会搬运(踢坚果);
	> FZ975: 跑三四次饿,等看到有皮果动机后,扔路边带皮果,踢到路上,扔棒去皮,飞至吃掉,存为FZ975;
	> 重点观察: 1.生成有皮果动机 2.学会得到有皮果的搬运HCanset;
	> 然后测下: 用搬运: 使用搬运;
结果	在训练3次后,它可自行踢坚果到路上,且在去皮后也可自行飞过去吃掉,存为:20240809-自行踢坚果到路上和飞吃.mov;

小结: 在32143中跑了下训练项2,学会搬运,并且经测试: 它也会自行搬运了;

---

n32pxx TODO备忘

CreateTime 2024.07.07

1. 2024.07.07: 以瞬时记忆做初始唤醒 (这个可能不需要支持,因为以前的前段已经有瞬时的支持了,那么这个前段必然会出现在工作记忆中,所以它也是可以做为初始唤醒作用的,而工作记忆中的初始唤醒现在就是支持的);
2. "埋怨"功能没写，它帮助聚焦到某cutIndex是有意义的。（应对sp不稳定帧有奇效）