[Notes] Reading Notes on [Adaptive Robot Control – mxautomation J. Braumann 2015]

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?