# Making a robot go in a straight rate - sampling rate for motor PID

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
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?

• 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? Oct 19, 2018 at 19:27
• 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. Oct 20, 2018 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.

Instead of using encoders, have you considered using a gyroscope sensor (which is very cheap and simple), an example is on (where the video shows you just how excellent the MPU6050 gyroscope sensor worked): https://www.instructables.com/How-to-Make-a-Robot-Car-Drive-Straight-and-Turn-Ex/

The reason I suggest this is because encoder has a few limitations:

1. assumes the robot is symmetrical
2. assumes the terrain is flat
3. As you found encoder gets a sample every 50ms, whereas MPU6050 can get one every 3ms.

Since MPU6050 can take so much more samples, you do not even need PID control. You can just use the simpler proportional control, which only requires you to tune one variable instead of three in PID.