the policy change block in control_loop refuses a change while a mode switch is in flight, because the switch is about to rebuild everything the change was derived from. the mode switch block does not refuse a switch while a policy change is in flight, and the same reasoning runs the other way.
a change is derived from the params that are running when it lands. its load runs on a thread for most of a second on the board. a switch accepted inside that second goes home, and at the end of the ramp loads the other mode's bundle and publishes the new mode. then the load lands, and since nothing is mid ramp any more it is applied: policy_params, policy_cfg, the controller, the published policy names and the slot report all go back to the old mode. state.mode is not part of that write, so robot.mode keeps reporting the new mode over policies, files and a controller that are the old one. the pad's belief follows what it was told, so from there the next d-pad hold asks in the wrong direction too.
the test drives the loop with no runtime, so the load lands within a tick and the window is the gap between the thread starting and the loop polling it. it trips on main on the first try, three runs out of three: "robot.mode says Roller and the walk slot is alpha_walking.onnx".
same block, one more door of #159. the policy change is not refused during a shutdown sit either, and a change to the network driving takes the mode switch's path home, which from inside the sit stands the robot up at gain until the sit timer cuts the torque. the sit needs the sitstand network so a test cannot reach it, same as the last time, and the gate is two lines beside the one above.
on main at 5984efb.
the policy change block in
control_looprefuses a change while a mode switch is in flight, because the switch is about to rebuild everything the change was derived from. the mode switch block does not refuse a switch while a policy change is in flight, and the same reasoning runs the other way.a change is derived from the params that are running when it lands. its load runs on a thread for most of a second on the board. a switch accepted inside that second goes home, and at the end of the ramp loads the other mode's bundle and publishes the new mode. then the load lands, and since nothing is mid ramp any more it is applied:
policy_params,policy_cfg, the controller, the published policy names and the slot report all go back to the old mode.state.modeis not part of that write, sorobot.modekeeps reporting the new mode over policies, files and a controller that are the old one. the pad's belief follows what it was told, so from there the next d-pad hold asks in the wrong direction too.the test drives the loop with no runtime, so the load lands within a tick and the window is the gap between the thread starting and the loop polling it. it trips on main on the first try, three runs out of three: "robot.mode says Roller and the walk slot is alpha_walking.onnx".
same block, one more door of #159. the policy change is not refused during a shutdown sit either, and a change to the network driving takes the mode switch's path home, which from inside the sit stands the robot up at gain until the sit timer cuts the torque. the sit needs the sitstand network so a test cannot reach it, same as the last time, and the gate is two lines beside the one above.
on main at 5984efb.