RobocupRescue 2021.1.27

今天深入探索了细节调试的重要手段——日志与step结合使用。
在Kernel GUI界面注意到了某个agent后，点击它查看它的ID，然后在logs文件夹中找到相应的日志，当前只有警察和消防有详尽的日志。
消防agent有包含本身属性的xxx.logs和buildingdetector的日志，以及commandexecutor的日志；警察agent有包含本身属性的xxx.logs和policeoffice的日志，以及commandexecutor的日志。

找到日志后在kernel GUI界面点击step，可以很好地追踪某个智能体在每个周期的情况。

上面三张张图片是berlin这张地图下前13个周期内ID为38524528的消防的日志。而再上面的第一张图中显示已经有三座建筑着火，但detector的日志里显示无论是全图还是簇内，着火建筑数目都是0。

而在joao这张图下，着火建筑从第4周期更新为2（实际为大于3个），到第七周期更新为5个（实际为7个）。
消防1643941687未被卡住，目标始终为空。而消防站不分配目标，这也应该是executor接收不到任务消息的直接原因。
而结合linesight视图下消防1643941687的视线和其位置，以及所有消防和警察的视线和着火建筑位置之间的关系（下图浅蓝色视线是某警察的视线）：
下图是消防1643941687的视线，视线左边的红点就是他。
下图是另外一个消防的视线，

第七周期内，中间三个连续的着火建筑在第一周期就出现，早已在消防1643941687的视线中出现。
而在第八第九周期，世界模型中的着火建筑分别更新为6个和7个，符合了实际情况。因为这两个新更新的着火建筑分别在一个救护车和一个居民的视线内。故我推测是着火建筑出现在人的视线（不只是消防的而是所有agent的包括居民）内，消防的世界模型才陆续更新，且一定小于等于上一周期视线内的着火建筑数。

我继续向下step，到第12周期，着火建筑实际变为8个，13周期变为9个，期间世界模型都没有更新。而在16周期实际着火建筑变为14个，世界模型更新为8个。


列成表格：

周期	实际个数	视线内个数	世界模型个数
7	7	7	5
8	7	7	6
9	7	7	7
10~12	8	7	7
13	9	7或8	7
14	9	7或8	7
15	9或更多	8	7
16	14	10	8
17	15	12	8
18	15	12	10
19	21	15	12
20	27	小于20（数不明白了）	12
21	27	/	13
…	27	…	13
25	28	/	14

基本可以证明上面粗体文字描述的推断大致成立。至于延迟更新的原因和具体数据，暂时不必深究。
这可能就是“视线”这一概念的重要用处之一。