Running the Adeeb Robot Controller on Linux

This is the second video in our controller series. It walks through deploying the Adeeb Robot Controller on Linux and using it to command servo position and velocity through the Python API — driving an Adeeb Delta Robot from configuration to first coordinated motion.

Prerequisites and hardware setup

The hardware is identical to the previous video: a mini PC running Linux, a servo drive, and a Yaskawa servo motor. The controller talks to the drive over EtherCAT, so the same EtherCAT slave information (ESI) files apply — ESI files describe each EtherCAT slave and are supplied by the drive vendor.

The Adeeb Robot Controller is available for Linux, Windows, and macOS from the downloads page. The trial build runs for two hours per session; after two hours you restart it. This walkthrough uses the Linux build only.

Downloading and inspecting the release

Download the Linux archive and extract it. The extracted folder contains:

• The controller binary — the server process you run.
• An AI model for image-to-text conversion (part recognition).
• Sample configuration files.
• ESI (EtherCAT slave information) files describing each slave.
• The deterministic Linux Ethernet driver used for EtherCAT.
• Python example scripts, including arc — the module that exposes all helper APIs — and the demo script used at the PACK EXPO booth.

The arc module name stands for Adeeb Robot Controller. Every example imports it with from arc import *.

Configuration

Open the Delta robot config file. The top of the file matches the format from the previous video — the Delta library is an extension of that base — and then adds robot-specific sections.

Axes

The config defines five axes. The first four drive the Delta robot; the fifth is the conveyor. Each axis exposes:

• Gear ratio — for a rotational axis, the number of motor revolutions required to produce one joint revolution. This is typically greater than one.
• Encoder offset — the encoder position at which the joint position should read zero.

Axes are rotational by default, with units of degrees. Set the linear flag to true to make an axis linear, with units of millimeters — as the conveyor axis is configured. A negative gear ratio flips the polarity of the axis motion. For the conveyor, the gear ratio depends on the conveyor pulley radius and the drivetrain, and must be set so motion resolves correctly in millimeters and millimeters per second.

Delta group and kinematics

The four Delta axes are bound into a group configured as a Delta robot. The group carries the base radius, base offset, and the rest of the kinematic and dynamic parameters used for torque calculations. These values come from the mechanism manual, which includes a labeled diagram and is available on the downloads page.

End effector

Configure the end-effector by pointing it at the slave that carries the I/O controlling it, the bit offset that I/O uses, and the engage and eject delays. This build uses a vacuum end-effector, which has both an engage and an eject signal. The eject signal is optional — a gripper that only exposes a single signal can omit it.

Camera

The camera position is defined relative to the world frame and is critical to pick accuracy. The robot is normally left at the origin, so robot and world frames coincide. Because Adeeb Robotics turnkey Delta solutions ship with the camera fixed-mounted on the robot, this position rarely changes — though you may need to calibrate the rotational angle RZ slightly if the mount is not perfectly aligned at installation.

For bench work without a camera, set the fixed image path to run in simulation mode. The controller feeds the supplied still — for example, the captured frame from the PACK EXPO demo stand — to the AI tool so it has parts to track. The image does not update, but it gives the recognition pipeline real parts to detect.

The conveyor is configured with its width, length, and position relative to the world frame. In this setup the conveyor sits at 90°, because the x-axis points to the left.

Container and parts

The container defines where picked parts are laid out — in the demo, the table surface. Set its width, length, and height; the auto-run functionality then lays out the maximum number of parts that fit. Part dimensions (width, length, height) tell the robot to stop above a part rather than crash into it when the part has thickness.

Cycling (auto-run)

The cycling section drives the zero-programming auto-run script. You specify the group, conveyor index, container index, and part index to operate on, plus:

• A speed percentage — motion speed relative to the robot’s maximum capability.
• The conveyor pickup timeout — how long to wait when a part is not immediately found.
• The conveyor speed — required for conveyor tracking.
• The cycle type — conveyor to container or container to conveyor.
• Start and done signals.

Cycling will not begin until the start signal sees a rising pulse, and it emits a pulse on the done signal each time a container is filled or emptied. Note that there is a start/done handshake for every container, not just once per run. Conveyor-to-container is the common case: parts move from the conveyor into the container, and a new cycle starts once the container is full. The auto-run implementation is the last script in the examples folder.

Launching the controller server

The controller runs as a server that the Python scripts talk to over a socket. It needs two terminals.

In the first terminal, launch the server with sudo and point it at your config file. Root privileges are required because the server accesses the Ethernet driver for deterministic optimization:

sudo ./robot-controller --config delta-robot.config

Startup takes a few seconds. On success, the server reports the IP address and port it is listening on. Every config change requires relaunching the server. Python-script changes do not — the script only talks to the already-running server.

Connecting via the Python API

In the second terminal, change into the Python scripts directory and run the PACK EXPO demo:

python pack_expo_demo.py

Every arc call is a request to the server: it sends over a socket (the axis APIs map to REST endpoints over HTTP) and waits for the response. A typical script imports the helpers, initializes the controller, and declares the labels it will plot.

Each joint axis is bound to an index within the EtherCAT network. Axes need not be ordered the same way as the network slaves, but matching them is far simpler — hence the ordering 0, 1, 2, 3, 4. The index setting controls whether an axis is real or virtual:

• Omit the index and the axis is virtual.
• Provide an index that does not exist on the network and the axis is also converted to virtual, with a prompt printed to that effect.
• Provide a valid index and the controller drives the real motor.

Commanding motion

The script configures motion profiles, then serves on and moves the group:

Call	Purpose
set_group_speed_percent	Group speed as a percentage of the maximum achievable values.
set_axis_speed	Trapezoidal velocity-profile limits (and jerk) for an axis — the profile bounds, not the instantaneous speed. The controller supports jerk-limited trajectories.
servo_on (group)	Defaults to group index 0.
servo_on (axis)	Requires an explicit axis index — axis APIs provide no default, since the index is rarely 0.
Conveyor commands	Default to index 0, since there is typically one conveyor.

Bring up the conveyor by commanding a velocity move on the conveyor axis at the configured conveyor speed. Units are millimeters per second, because the conveyor is a linear axis. With the axis in velocity mode, pass the conveyor speed to the conveyor-tracking API — the controller does not usually drive the conveyor itself, so it must be told the belt speed for tracking.

The motion sequence is:

1. Home the robot and wait until the motion completes.
2. Cyclically move parts by label, either conveyor-to-container or container-to-conveyor, placing each at an explicit I, J, K index within the container.

The container is effectively the table in this demo, positioned by the container config. Parts are picked in label order and, when returned, dropped onto the conveyor at random positions. The full pick-and-place demo is roughly 30 lines once the experimentation code is uncommented.

Watch the velocity limits

When the demo runs as configured for the booth, the group speed percentage is set to 250 — too high for this bench setup, producing 2000B errors. As documented in the manual on the downloads page, 2000B indicates the velocity limit has been reached. Lower the speed (the video drops it from 250 to 10) and relaunch the script. The robot speed must also stay matched to the conveyor speed; a conveyor speed too high relative to the robot will likewise error out.

The demo recognizes parts labeled to spell “Adeeb” — the “D” is omitted because the edge of that letter sat too close to the part edge for reliable image-to-text reading. With the speed lowered, the script streams live position, velocity, and torque from the motor and cycles continuously, behaving as though a full robot is attached even when only the single motor is present.

Next steps

• Pair this controller with the EtherCAT master on Linux walkthrough to set up the network and ESI files.
• Dig into individual moves in the axis motion commands article.
• Review the full Adeeb Robot Controller and Adeeb Delta Robot product pages.
• Grab the trial build from the downloads page or request a demo.