Hey,
I am working on controlling a UR5 robot using RTDE and aiming to update the input_double_register values at a 500 Hz rate (every 2ms). I’ve adapted this servoJ control example to include input_double_registers 0-5 and timestamps in the state recipe, which are then logged to a CSV file.
I’ve noticed that the input registers are not consistently updated every cycle as expected. I’ve shown a plot, but the duplicates aren’t very obvious in it. Looking over the log, I see there are duplicates of the input_double_register values which are the set point joint angles, suggesting that updates aren’t occurring at the intended frequency. It seems inconsistent, as the registers sometimes increment properly with new values at each 2ms cycle.
I’ve set the servoj command in the URP program to 2ms. I have about 600 joint angles, so I would expect the total time to take about 1.2 seconds, but the timestamps show it is taking about 1.7 seconds. Timing is important for my application, so it would be great if anyone knew why this might be occurring. I might be missing something or misunderstanding the process since I’m new to this.
Maybe same problem as described here:
Maybe. When the duplicates of the input register values occur, the timestamps and actual_q values have been updated which I assume they wouldn’t if this were the issue. If this issue were due to missing output packets caused by too much computation load, would it affect the total time for the path? I’ve also checked that the speed_scaling remains at 1 throughout.
I found that the timing issue seems to be due to the index of the setpoint joint angles incrementing by 1 regardless of the actual time elapsed between packets. I was expecting to read and write at 2ms intervals, but if packets are skipped and the actual interval before writing the next packet is, for example, 8ms, then the index needs to be adjusted accordingly. However, it appears that the input_double_registers are still not being updated consistently at each interval with duplicates occurring.