Dr. Denis

@matthew-reynolds your solution sounds plausible. It seems we are resetting the `rt_active_goal_` from multiple threads. This is not good.

@bailaC can you also check this in the assigned interfaces method? See the first comment, point Nr. 3

Can you make print also with "interface.get_name() + interface.get_interface_name()"

I propose the following order: - constructor() - init() - on_configure() - command_interface_configuration() - state_interface_configuration() - on_activate() - update() - on_deactivate() - on_cleanup() - on_shutdown()

Yeah, I also had no idea, and although I looked at this message a few times, I didn't read its header. Actually, a ROS newcomer I was helping pointed me...

> So the bug is actually in joint_trajectory_controller for using system time Yes this is correct. Actually the error is using `node->now()`. That is the reason why you can set...

This is still the case. First is to find where this occurances happen.

> Would it be enough if the velocity loops around the wheels where closed? I think this is how most people are using it.

@matthew-reynolds could you look at this? You resolved a similar issue in ros_control repo

The tests are still flaky (see #154 builds). But I found out why! We have timing issues. Probably is the runner CPU on maximal load and therefore limits/thresholds are not...