I'm trying to build a robot/rover based on Raspberry Pi 3 At the moment I'm straggling with a basic driving in a straight line.

I'm in a process of tuning my PID code andI'm not sure what sampling rate should I choose.

These are the specs of the motors:

Voltage: DC 6V
Speed: 210 rpm
Encoder motor end: 11 signals
Rated voltage: DC 6V
No-load speed: 210RPM 0.13A
Max efficiency: 2.0kg.cm/170rpm/2.0W/0.60A
Max power: 5.2kg.cm/110rpm/3.1W/1.10A
Stall torque: 10kg.cm 3.2A
Retarder reduction ratio: 1 : 34
Hall resolution: hall x ratio 34.02 = 341.2PPR

When the robot moves at the desired speed I get 20 encoder signals if I take a sample every 100ms and I get 10 if I sample every 50ms.

My question is what is the reasonable frequency to collect the encoder counts?
At 50ms I get higher frequency, so my PID adjustments can occur more frequently, but I get only 10 signals, so the resolution seems to be a bit low.
At 100ms I get 20 ticks which should provide more consistent stats, but then maybe adjustments are not happening fast enough.

Is there any rule of thumb for choosing a sampling rate for PID when driving a robot rover?

  • $\begingroup$ Are you running the motor controller on RPi? And is the encoder connected directly to it's inputs? Do you have a realtime system there? $\endgroup$
    – mactro
    Oct 19 '18 at 19:27
  • $\begingroup$ Yes, I am. Encoder is connected directly to GPIO pins and is using interrupts to detect encoder ticks. It's running Raspbian system on it, so not a realtime system. $\endgroup$
    – Leonti
    Oct 20 '18 at 2:33

There are probably some very strong theoretical results about the sampling frequency required to control a system. In the absence of a better answer, I have:

When considering sample rate from a scientific or mathematical perspective, the guidelines are a bit more involved and beyond the scope of this blog post. Still, it’s generally accepted best-practice for the sample rate to be based on frequency or time-based components of the process data. Basic formulas propose the use of data that is either 5-10 times faster than the Process Time Constant or 3-5 times faster than the Process Dead-Time.

There's a couple of links in the quote to define process time constant and process dead time.

In general, faster is probably better. If you state significantly changes on the order of milliseconds, then you should provide control updates faster than that. In my experience (ground and maritime robotics), 10Hz has usually been sufficient.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.