The refactored version of this driver benefits from optimalisations so selecting a build type with optimalisations enabled is important.
Only if the user hasn't configured a build type do we do this to prevent overriding whatever was already configured.
Squashed commits:
* Avoid updating ros_control controllers on pipeline timeout
* Revert "Avoid updating ros_control controllers on pipeline timeout"
* Do not update controller_manager until RTPackets have been received
* Mark handles as initialized after actually doing it rather than just before
* Improve readability
Pre-refactor version of URScript topic used to automatically append newline when not the last character of the message however that was not the case for the new version.
Low Bandwidth Trajectory Follower has now much less comments
and debugging information - which means that it will parse on UR robot
in around 400 ms instead of 700 ms. It also has an adjustment loop
in case the robot does not reach any of the trajectory points specified.
It will catch-up at every trajectory point sent by MoveIt and will try
to get as close as possible to the desired pointi (it will check if all
joints are within MAX_JOINT_DIFFERENCE from the desired positions)
Safe Trajectory Follower implements different approach for controlling
the robot. Rather than calculate the interpolation steps in the driver
and send the small interpolated steps over the network to the URScript
program with 500Hz frequency, the coarser MoveIt trajectory is sent
(with few Hz) and the interpolation steps are calculated by the
URScript.
The algorithm for time progress has also built-in protection against
any delays induced by load on the driver, network or URControl - it
will never "catch-up" dangerously when such delay are introduced,
It will rather pause and wait for the next small interpolation step
instructions and re-start the move slower - never skipping any
interpolated steps.
Those changes make Safe Trajectory Follower much more resilient to
network communication problems and removes any superficial requirements
for the network setup, kernel latency and no-load-requirement for the
driver's PC - making it much more suitable for research, development
and quick iteration loops. It works reliably even over WiFi.
