跳到主要内容

其它使用与实时性问题

示教器设置在实时模式下是否生效​

实时模式下，多数示教器中的运动和安全参数不生效（如加速度项）。常见仍生效项：

  • 碰撞检测（碰撞后下电停止）
  • 关节限位
  • 基坐标系
  • 力控参数（阻抗控制下）

点位跟随示例无法编译​

follow_joint_position 与 torque_control 示例依赖 xMate 模型库，需要打开宏配置。

cmake -DXCORE_USE_XMATE_MODEL=ON

非 CMake 工程需添加宏：XMATEMODEL_LIB_SUPPORTED。

实时模式运动慢​

  • 问题1 ：在用SDK开环下发控制指令的时候（1ms调用），发现下发的指令和实际执行之间存在滞后，且运行时间越长，滞后越明显。
  • 问题2：跟随慢了

原理介绍-实时主循环通信流程​

进入周期性主循环前会先清空通信缓存，避免残留数据干扰；每个周期内先完成状态侧接收与更新，再向控制器发送一条本周期指令。流程概览如下。

等待超时时间的原理​

发送指令的周期受接收状态数据的周期控制，若默认超时时间1ms，可能存在未等待到状态数据更新，就发送的指令的情况，导致平均指令发送周期小于1ms，也就是发快了。

解决办法​

实时模式接收状态数据默认的等待超时时间是 1ms ，v0.7.0版本已改为0.3ms。根据现场实际的网络情况，可以在可执行文件同目录下，增加配置文件 xcoresdk_config.json来设置超时时间，以适应实际情况和优化实时效果。若设备网络情况较好，并出现控制一段时间后，发送的运动指令有延迟执行的现象，可适当将超时时间调大，设置范围为 1∼4ms ，具体的 json 文件格式如下：

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

闭环控制时获取控制器反馈数据延迟​

原因​

sdk实时线程在不绑定核心不设置线程优先级的情况下，全凭cpu调度，容易被定时器、中断、桌面任务等更高优先级的任务阻塞，从而导致sdk接收xcore的状态数据超时。

解决办法​

  • 上位机核隔离 如测试使用的是i5-12500cpu，共有6个性能核，12个逻辑cpu，本次测试将sdk的实时线程绑在cpu3上运行，因为cpu2和cpu3公用一个物理核，所以做核隔离的时候同时隔离cpu2和cpu3，让调度器常规任务(中断、定时器等)在其他cpu上运行。 alt text 对应指令：
    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增加绑定cpu核、设置线程优先级的接口（v4.0版本支持）
    rtCon->setControlLoop(callback, 80, true); 
    rtCon->setCpuAffinity(3);

修改之后运行程序，能看到_do_loop线程绑定在cpu3上运行，不会乱跳了，且priority也成功设置成了80(通过sdk接口设定的)，并且从数据来看sdk侧阻塞的现象明显改善了。 alt text