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.
* Re-added UR script - for custom UR Script execution
* Restarting the driver when robot closes the connection on script error.
The pipelines work in the way that if the connection is
is closed by the control PC, it will not be re-established. This
happens for example if you use the URScript topic and upload
script that does not compile. The robot will then close the
connection, the pipeline will close and any subsequent
uploads will fail and noone realises there is a problem.
While we could re-establish the connection, I think much better
solution is to shutdown the driver in such case. This is much more
resilient behaviour as it will clean up any inconsistent driver state.
We can utilise "respawn" feature of ROS launch and restart such
driver automatically (launch files are updated as part of that change).
On top of "production" stability, it allows for much nicer development
workflow - you can use URScript topic for development of new scripts
and have the driver restart every time you make mistake.
Without it, any mistake requires restarting the driver manually.
