Real-time trajectory interpolation allows a Python-based sensor-integrating application to real-time control a Franka Emika robot. Application development in Python is much faster and easier than in C++.
When robot motion generation for a processing task is dependent on real-time sensor feed-back from the processing tool, the motion must be, by it’s nature, generated at the temporal micro to meso level in real-time. Some open robot controllers allow real-time trajectory feeding at the micro level. These are obvious candidates for such real-time sensor-based motion applications.
If a given application only requires real-time trajectory generation at the meso level, interpolation may be utilized for alleviating the application from the micro real-time requirement of the robot controller. This, in turn, opens for freedom of choice of the application platform, framework, or programming language.
The temporal micro level of control in a robot is 1 ms or lower, down to the control of current in the servos at the order of 10 µs or 100 µs. Good contact control under stiff conditions require 1 ms, or better, in the sensor to servo control loop. However, for tolerant control under compliant conditions and moderate speeds, 10 ms may suffice. We may define the meso level of real-time control from 10 ms to 1 s. Macro level real-time control is at the level of 1 s and above. The macro level may adequately be called real-time task generation.
Based on Cubic Hermite Splines, a smooth real-time trajectory interpolator have been developed and implemented in C++ addressing the direct need of the robot controller. This “trajectory frequency scaler” ensures the micro level requirement of the robot controller, while only imposing a meso level real-time requirement to the application-oriented sensor-based motion generation.
The interpolator is an independent, network-connected process with long life-time, maintaining the robot controller operative in it’s real-time modus of operation over several application runs.
An example process: Cutting of meat is a fairly complex physical process, but the interaction is also fairly compliant and with good real-time tolerance. Hence the sensor integration for the motion generation may adequately be performed at the meso level.
With only a meso level requirement for the sensor to servo control loop, one may switch from the complexity of C++ code to something much more flexible, such as the interpreted language Python, for developing the entire control application. The robot controller itself, however, may still need to be fed 1 ms interpolated trajectory points.
The maintained operation of the robot controller modus by the interpolator plays a major role with respect to experimentation and development, since restarting the robot controller system is a process which generally requires some amount of manual interaction and waiting time.
A software program have been developed which utilizes Cubic Hermite Splines for generating a smooth trajectory at a resolution of 1 ms, which is fed in real-time to the robot controller. At the other end, this program listens for a network connection from an sensor-based application motion generator, which is required to real-time feed a trajectory at the meso level of resolution; 10 ms to 100 ms. For sufficiently smooth application trajectories this software is performing well.
The software has not yet been taken into application use. Experiments with using it in a Python-based motion generation framework shows that the principle is sound.
Network communication glitches may distort the communication to the robot controller. This may lead to divergence between the generated trajectory and the actual robot position. This again leads to large accelerations in the robot arm, exceeding the allowed limits. Avoiding and handling such network commutnication glitches is the current focus of activity.
Avoiding or minimizing glitches is achieved by using adequate computing and network hardware and optimizing the real-time performance of the software.
Handling the glitches is a matter of “picking up” the robot in it’s actual state afterwards, and smoothly transitioning it back to the planned trajectory under execution.
By: Morten Lind