Rotate yaw computation

[RajeshDM]

I'm not 100% this is an issue but when extracting the real observation and converting it from thor angle to grid angle - it is done at line :

https://github.com/zkytony/thortils/blob/b98480eba45a90311e501ceef621c3b80282c3c7/thortils/grid_map.py#L70

The function is returning 90 - thor_yaw. I was wondering - shouldn't this be (90 - thor_yaw ) % 360 because if thor_yaw is more than 90 this value becomes negative and robot's real observation will have negative yaw. But the transition model update has a (value%360 ) and that will never be negative - so there's a chance real observation will have negative yaw but the expected observation model will never have negative yaw - there seems to be a mismatch there.

Please let me know what you think about it.

[zkytony]

I assumed the agent observes its view pose. I believe that when real observation is received, the view pose in it is directly used for belief update. Even if the yaw in the observation is negative, it doesn't affect planning because as you said, the transition only outputs positive angles. So the mismatch here doesn't affect planning.

It's true that the mismatch may cause the search tree produced in the previous step to not be reusable. But since the observation space is large and the tree is sparse, such mismatch should happen quite often. The online planner would recompute a new search tree for the next action, and that's totally fine in principle.

[RajeshDM]

I assumed the agent observes its view pose. I believe that when real observation is received, the view pose in it is directly used for belief update. Even if the yaw in the observation is negative, it doesn't affect planning because as you said, the transition only outputs positive angles. So the mismatch here doesn't affect planning.

It's true that the mismatch may cause the search tree produced in the previous step to not be reusable. But since the observation space is large and the tree is sparse, such mismatch should happen quite often. The online planner would recompute a new search tree for the next action, and that's totally fine in principle.

Makes sense. It is the reusability that gets affected - the tree is cleared since it thinks the real_observation does not match any current observation so plan from scratch again. . Thank you for clarifying