As described in #80 , the robot suddenly falls down in the simulation, because a significant spike in IO time delays the generated control inputs. This is fixed by using asynchronous IO as described here. This fixes #80 .
After this fix, the robot seems to be able to walk for almost 2hrs at vel_y_desired = 0.3m/s, after which tracking performance gradually degrades and makes the robot eventually fall down.
However, the reason for falling down seems to be Gazebosim itself, as multiple experiments suggest the controller has no problem walking at very high position values, compared to Gazebo, which consistently gives worse results starting from t=~100min. This was tested by offsetting the reported position value and starting the robot at pos_y = 2500m and 7500m.
As described in #80 , the robot suddenly falls down in the simulation, because a significant spike in IO time delays the generated control inputs. This is fixed by using asynchronous IO as described here. This fixes #80 .
After this fix, the robot seems to be able to walk for almost 2hrs at vel_y_desired = 0.3m/s, after which tracking performance gradually degrades and makes the robot eventually fall down. However, the reason for falling down seems to be Gazebosim itself, as multiple experiments suggest the controller has no problem walking at very high position values, compared to Gazebo, which consistently gives worse results starting from t=~100min. This was tested by offsetting the reported position value and starting the robot at pos_y = 2500m and 7500m.