my robotic project is running at every 1ms and the processes are taking about 0.9ms. I am running PID so my max clock rate is 1kHz. About half of the processing time are taken by SPI peripherals, IMU and encoders. Is there any recommendation on how I can run faster PID sampling rate?
-
$\begingroup$ Why do you need a higher sample rate? $\endgroup$– Daniel JourJul 17, 2015 at 23:12
-
$\begingroup$ You have to change sensor reading time. Sample time bounded to sensors. PID sample rate has no matter. Try assembly language to shorten. Also can you share your hardware specifications. $\endgroup$– acsJul 19, 2015 at 21:21
-
$\begingroup$ @Daniel I wanted to experiment. And hope it improves performance. $\endgroup$– drerDJul 20, 2015 at 22:28
1 Answer
Increasing the sample rate probably isn't going to buy you much if you can't do something useful. That is, if you don't update the control signal (e.g., motor current) at the same high sample rate, then I don't think you're going to gain much. Similarly, if your IMU or other sensors don't update at the higher frequency, polling them at a higher frequency isn't going to get you much either.
You need high frequency feedback, high frequency output, and the headroom to process at those high frequencies. If you could increase the PID sample rate, if you're still relying on the 1kHz process to provide the output then you haven't gained much. However, note that the input frequency doesn't matter too much; at a bounding very low frequency input the controller would interpret the reference like a step input, but you still get PID control/stability.
What I would suggest is either going with a faster processor or (preferred) splitting PID off into its own processor. Use a "master" to interface with the user, generate a reference signal, then pass that reference off to the PID controller. Doing this frees up the PID controller to handle only the relevant feedback (sensors) and outputs (motors).
For example, say you are running a quadcopter. The master controller gets the motion control input from the pilot, but also gets periphery input from the pilot, for things such as maybe camera gimbal control, camera control, lighting/display control, audio, heartbeat messages, feedback vehicle parameters to the pilot, etc.
Of all of these things, parse the motion refernce (pitch/roll/yaw/thrust etc.) and pass that off to the PID control chip.
Now the PID control chip gets the motion reference at the 1kHz input, but the reference doesn't need to update very quickly. The PID control chip can now focus only on polling the IMU/compass/other sensors, calculating reference-feedback errors, and modifying the outputs.
-
$\begingroup$ could you elaborate on "reference doesn't need to update very quickly"? or direct me to some other place where I can look into the validity of such implementation? $\endgroup$– drerDJul 17, 2015 at 19:00
-
$\begingroup$ It's just a step response. Say you get control reference signals every 1ms (1kHz) but your PID runs every 0.1ms (10kHz), then you essentially have a 10 sample step followed by another 10 sample step - PID will still work to control to the input. This is akin to breaking down a system response as a summation of impulse responses. $\endgroup$– Chuck ♦Jul 17, 2015 at 21:35