autome

Hello @SteveMacenski. Sorry for the late reply. Now thinking back, maybe using `

After removing _sign *_ from this [line](https://github.com/ros-planning/navigation2/blob/97068787fb35894a098f9c4600b5a06c7dddf43b/nav2_regulated_pure_pursuit_controller/src/regulated_pure_pursuit_controller.cpp#L344), it works perfectly. Looks like this bug was introduced by this [PR 2979](https://github.com/ros-planning/navigation2/pull/2979). The above PR seems to be testing for ackermann while...

Yeah. Probably the reason is some misconfigured setup. Okay 👍 I will submit the PR.

To add, this error behaviour is easy to simulate when comparing output if 15W and MAXN mode. For now to mitigate this issue, I am using different thread and looping...

From my testing, this issue only occurs with high CPU usage (over 50%). To add more details: - I am using two `add_event_detect` for two encoders running inside docker container...

It seems like ROS1 TEB uses `ros::Time()` instead of `plan_pose.header.stamp` in ROS2. https://github.com/rst-tu-dortmund/teb_local_planner/blob/0e839074c3407ff9ee2206a49567a20bd49fd8cc/src/teb_local_planner_ros.cpp#L718 How about changing it similar to ROS1 method?

This seems to be ported to crystal long time ago from this [PR](https://github.com/rst-tu-dortmund/teb_local_planner/commit/34a9a32c8cdf756204f819fe2efe1f126040ad2d) by @vinnamkim Hey @vinnamkim , if possible can you explain your decision for changing the lookup time...

Hi @apeng-yp I had similar error and found that it usually occur with planner creating in-place rotation. This is because deltaT estimate is zero on following line. https://github.com/rst-tu-dortmund/teb_local_planner/blob/0e839074c3407ff9ee2206a49567a20bd49fd8cc/include/teb_local_planner/g2o_types/edge_velocity.h#L106 Can you...