Revision history [back]

After checking the CPU usage, which is stable to 46% with 2 vnc opened (the graph is plotted by the ros master, which is a regular pc) I tried changing PID parameters as @AndyZe suggested. Well I solved everything setting the Kd term from 0.01 to 0 and leaving Kp and Ki terms same as before. All the spikes in the control_effort, which I thought were generated by the encoder itself, are now disappeared and the pid works smoothly and stably over time.

Then I tried to modify the parameters as @AndyZe suggested, but I found no local minimum with a Kp higher than the Ki, the motors keep oscillating around the setpoint, with very small convergence. I changed the windup_limit too, but lowering it to 10 create a phase shift between the desired and the commanded velocity, which doesn't stabilize on the desired value from a certain point. The new setting which can promptly follow the setpoint are: Kp = 0.4, Ki = 5.5, Kd = 0.0.

I think the reason behind this strange tuning parameters should be sought in this specific hardware configuration: the combination of Arduino poor time handling and a low step encoder introduces fast varying measurements due to the large quantization step; the faster measurements are taken the greater quantization step becomes. Using a filter to take an average of the speed introduces delay which again lead to oscillation and instability.

After checking the CPU usage, which is stable to 46% with 2 vnc opened (the graph is plotted by the ros master, which is a regular pc) I tried changing PID parameters as @AndyZe suggested. Well I solved everything setting the Kd term from 0.01 to 0 0 and leaving Kp and Ki terms same as before. All the spikes in the control_effort, which I thought were generated by the encoder itself, are now disappeared and the pid works smoothly and stably over time.

Then I tried to modify the parameters as @AndyZe suggested, but I found no local minimum with a Kp higher than the Ki, the motors keep oscillating around the setpoint, with very small convergence. I changed the windup_limit too, but lowering it to 10 create a phase shift between the desired and the commanded velocity, which doesn't stabilize on the desired value from a certain point. The new setting which can promptly follow the setpoint are: Kp = 0.4, Ki = 5.5, Kd = 0.0.

I think the reason behind this strange tuning parameters should be sought in this specific hardware configuration: the combination of Arduino poor time handling and a low step encoder introduces fast varying measurements due to the large quantization step; the faster measurements are taken the greater quantization step becomes. Using a filter to take an average of the speed introduces delay which again lead to oscillation and instability. instability.

After checking the CPU usage, which is stable to 46% with 2 vnc opened (the graph is plotted by the ros master, which is a regular pc) I tried changing PID parameters as @AndyZe suggested. Well I solved everything setting the Kd term from 0.01 to 0 and leaving Kp and Ki terms same as before. All the spikes in the control_effort, which I thought were generated by the encoder itself, are now disappeared and the pid works smoothly and stably over time.

Then I tried to modify the parameters to fine tune the PID as @AndyZe suggested, but I found no local minimum with a Kp higher than the Ki, the motors keep oscillating around the setpoint, with very small convergence. I changed the windup_limit too, but lowering it to 10 create a phase shift between the desired and the commanded velocity, which doesn't stabilize on the desired value from a certain point. The new setting which can promptly follow the setpoint are: Kp = 0.4, Ki = 5.5, Kd = 0.0.

I think the reason behind this strange tuning parameters should be sought in this specific hardware configuration: the combination of Arduino poor time handling and a low step encoder introduces fast varying measurements due to the large quantization step; the faster measurements are taken the greater quantization step becomes. Using a filter to take an average of the speed introduces delay which again lead to oscillation and instability.

After checking the CPU usage, which is stable to 46% with 2 vnc opened (the graph is plotted by the ros master, which is a regular pc) I tried changing PID parameters as @AndyZe suggested. Well I solved everything setting the Kd term from 0.01 to 0 and leaving Kp and Ki terms same as before. All the spikes in the control_effort, which I thought were generated by the encoder itself, are now disappeared and the pid works smoothly and stably over time.

Then I tried to modify the parameters to fine tune the PID as @AndyZe suggested, but I found no local minimum with a Kp higher than the Ki, the motors keep oscillating around the setpoint, with very small convergence. I changed the windup_limit too, but lowering it to 10 create a phase shift between the desired and the commanded velocity, which doesn't stabilize on the desired value from a certain point. The new setting which can promptly follow the setpoint are: Kp = 0.4, Ki = 5.5, Kd = 0.0.

I think the reason behind this strange tuning parameters should be sought in this specific hardware configuration: the combination of Arduino poor time handling and a low step encoder introduces fast varying measurements due to the large quantization step; the faster measurements are taken the greater quantization step becomes. Using a filter to take an average of the speed introduces delay which again lead to oscillation and instability.instability. In the end, the integral component of the PID uses values from past measurements to correct the error, acting like a filter which introduces lower delay and which lower the gap between measurements.