Skip to main content

Other usage and real-time topics

Do teach-pendant motion/safety settings apply in real-time mode?​

Most do not, including acceleration-like items. The arm behaves closer to a pure actuator: valid commands execute; invalid ones trip errors and power-off, with few extra soft limits. Items that often still apply:

  • Collision detection (power-off after collision)
  • Joint limits
  • Base frame
  • Force-control parameters (under impedance control)

Callback “real-time” behavior​

Each cycle is roughly: receive one controller status → send one command. The controller sends status in real time, but the host does not have to run in a hard real-time thread, so cycles may not be strictly 1 ms; timing follows the controller’s send cadence.

follow_joint_position / torque_control examples do not compile​

These samples need the xMate model library and the CMake option:

cmake -DXCORE_USE_XMATE_MODEL=ON

For non-CMake projects, define XMATEMODEL_LIB_SUPPORTED.

Real-time motion feels slow​

  • Issue 1: With 1 ms open-loop commands, ~20 ms lag between command and execution.
  • Issue 2: Following feels sluggish.

Mitigation: The default wait for status is 1 ms. Add xcoresdk_config.json next to the executable to tune timeout for your network. If the link is good but commands drift late over time, increase timeout slightly. Allowed range 1–4 ms:

{
  "rt": {
    "_timeout_": 2
  }
}

Delay receiving controller feedback in closed-loop control​

Cause​

Without CPU affinity or thread priority, the SDK real-time thread relies entirely on the OS scheduler and can be preempted by higher-priority work such as timers, interrupts, and desktop tasks, causing the SDK to time out when receiving xCore status data.

Mitigation​

  • Host CPU isolation

    In testing with an Intel Core i5-12500 (6 performance cores, 12 logical CPUs), the SDK real-time thread was pinned to CPU 3. Because CPU 2 and CPU 3 share the same physical core, both were isolated so routine scheduler work (interrupts, timers, etc.) runs on other CPUs.

    alt text

    Corresponding commands:

        sudo sed -i's/isolcpus=3/isolcpus=2,3/'/etc/default/grub
        sudo sed -i's/nohz_full=3/nohz_full=2,3/'/etc/default/grub
        sudo sed -i's/rcu_nocbs=3/rcu_nocbs=2,3/'/etc/default/grub
        sudo sed -i's/irqaffinity=0-2,4-11/irqaffinity=0-1,4-11/'/etc/default/grub 
        sudo update-grub echo "ubuntu - rtprio 99" | sudo tee -a /etc/security/limits.conf
        sudo reboot

  • SDK APIs for CPU affinity and thread priority (supported since v4.0)

        rtCon->setControlLoop(callback, 80, true); 
        rtCon->setCpuAffinity(3);

    After these changes, the _do_loop thread stays pinned to CPU 3 instead of migrating, priority is set to 80 (via the SDK API), and SDK-side blocking is noticeably reduced.

    alt text