Reading sources:
1.Johannes Braumann, Sigrid Brell-Cokcan, Adaptive Robot Control (ARC )
Note:
building upon an as of yet unnamed interface from KUKA that utilizes
generic UDP packets to communicate with and control KUKA robots.
use every network-capable device to stream info to the robot and process the return data
While the problem of Windows not being a real-time capable operating system persists, the integrated buffer
give us a much larger leeway(余地) so that brief communication issues do not have an impact on the robot’s tool
path or the stability of the communication. However, the buffer also prohibits any hard-real-time applications, i.e. processes
where millisecond reaction times are needed.
kuka|PRC core solver builds its mathematical and geometric calculations upon
OpenNURBS.
ARC does not have to offer any simulation capabilities by itself, but only accepts data,
interfaces with the robot, and visualizes the position data that gets sent back from
the robot - keeping the software slim and highly performant while allowing the user
to simulate other projects in KUKA|PRC without disturbing the dataflow.
4 interaction strategies:
1.Default Mode
This is the most basic mode whose purpose is simply to transfer commands to the robot.
Once commands are connected to the ARC component they are immediately processed and
sent to the robot. While the robot is already moving, additionally commands are streamed until
the interpreter’s buffer has reached its defined capacity. From then on, executed commands are
culled(剔除) from the buffer and replaced with new commands.(溢出的水就扔掉不要了) If the data
from the ARC components is changed, it immediately wipes the robot’s buffer and starts streaming
new commands.
Adaptive Mode:
In comparison with default mode, adaptive mode users a much shallower buffer that contains only the
bare minimum of commands to cover brief lags(落后时间) in the Ethernet communication. While usually robot
programs only allow the user to set a speed override, adaptive mode attempts to keep the entire robot job
completely parametric for as long as possible.(What does it mean?) Only when a command is committed to
the robot ‘s buffer it cannot be changed anymore. This allow us to incorporate sensoric feedback to continuously
inform the fabrication process and all its parameters.
Iterative mode:
In iterative mode, the ARC behaves mostly like default mode with a similarly larger buffer, but does not accept any
new commands until the robot signals that it is ready for the next iteration, i.e. when the previous commands have
been processed and an optional timeout has passed. The main applications is therefore to switch between fabrication
and evaluation. Essentially, the user only has to define a single operation such as “pick up here and drop off there”
and a set of global rules regarding the placement. Then the robot performs an operation, sensor data – e.g. from a 3D
camera – is processed, and the next iteration adjusted according to the captured data.
Real-time mode:
Similar to the adaptive mode, real-time mode uses a shallow buffer to reduce the reaction time to a minimum within ARC’s
framework. However, while adaptive mode works with the entire parametric toolpath, real-time mode generates each command
on the fly by taking the current robot position, calculating the diff to the target position and then adjusting it according to the
preset step-values. So if the target, e.g. based on live motion capture data, were to move, with a step size set to 5mm and a
buffer to 5 positions, the robot would continue for 25 mm before reacting to the change.
Problem:
- What’s UDP communication?