Choosing pigpiod sample rate? Pi PWM vs pigpiod PWM?
Posted: Sun Aug 09, 2015 8:06 pm
I set up pigpiod to start at boot via the crontab entry:
@reboot /usr/local/bin/pigpiod
This runs the pigpiod at the default sample rate of 5 uSeconds.
With no events and no clients, pigpiod loads my Raspberry Pi B+ at roughly 9% CPU.
The pigpiod docs show possible sample rate options of 1,2,5,8,10 for pigpiod -s <sample_rate>.
Are these the only values possible, and how do I choose a sample rate?
My time critical events:
1) Wheel Encoders:
Each Wheel Encoder has 32 edges per revolution at 1.019 rev/sec at max speed, is approximately 33 events per second or roughly 30 millisecond events.
The maximum out of sync the wheel encoders could be is just short of one edge which should result in about a half inch in 10 feet,(I think), (0.24" difference in translation at 5.4" wheelbase)
It would seem that if I can detect a 333 uSec difference in the encoder events (100 times/second), I should get very straight travel. There are so many variables, wheel wobble, diameter difference, actual turning wheelbase, and probably more.
If there are control delays, and motor response delays, and detection delays, the jitter in the system is bound to be fairly high also.
So if the only choices of sample rate are 1-10, then 10 uSeconds is clearly the rate even though it would seem to be overkill by a factor of 30
2) PWM for servos
The SG90 has a deadband of 7-10 uSeconds and requires a pulse width of 500-2400 uSeconds or 800-3000 uS.
(one place said 800uS = 0 deg. and 3000uS = 180 deg)
I think that means that the servo will not notice differences of less than 10 uSeconds.
1900 to 2200 uSeconds of pulse width range divided by the dead band probably means I can request 190 to 220 different servo positions.
Something like 85-110 left of center and 85-110 right of center, so I can point my range sensor with one to two degree precision.
I read that the maximum beam width for my Sharp IR sensor is about 16cm at midrange of 30" or 5 degrees wide.
I think that means I should take readings about 2.5 degrees apart, which would seem to match the pointing precision with a 10uSec dead band servo.
If the PWM for the servos comes from pigpiod bit-banging the GPIO lines, what sample rate do I need to get this 10uS precision?
3) PWM for DC motors
Maintaining a straight path with the 32 event encoders would seem to mean I want a speed error controllable to the precision of the encoders.
I assume the motor control should count a few wheel encoder events to get a speed for each wheel, and then modify the input to the motor.
I don't know what the motors' angular velocity "dead band" is. I think most people run their bots with 8bit velocity commands,
and some at the low value are useless because the bot doesn't start moving until some minimum power/"velocity" command.
This seems like it is a slow process compared to the wheel encoders which are 30 times slower than the servo demands.
BUT - I read that the PI has a built in PWM on two pins. I had planned these for the DC motors, but if the DC motors are the less demanding, perhaps the Pi should control the tilt/pan servos and the pigpiod should bit-bang the motor PWM which would reduce the event load on the pigpiod by a factor of 30.
I'm so confused now.
@reboot /usr/local/bin/pigpiod
This runs the pigpiod at the default sample rate of 5 uSeconds.
With no events and no clients, pigpiod loads my Raspberry Pi B+ at roughly 9% CPU.
The pigpiod docs show possible sample rate options of 1,2,5,8,10 for pigpiod -s <sample_rate>.
Are these the only values possible, and how do I choose a sample rate?
My time critical events:
1) Wheel Encoders:
Each Wheel Encoder has 32 edges per revolution at 1.019 rev/sec at max speed, is approximately 33 events per second or roughly 30 millisecond events.
The maximum out of sync the wheel encoders could be is just short of one edge which should result in about a half inch in 10 feet,(I think), (0.24" difference in translation at 5.4" wheelbase)
It would seem that if I can detect a 333 uSec difference in the encoder events (100 times/second), I should get very straight travel. There are so many variables, wheel wobble, diameter difference, actual turning wheelbase, and probably more.
If there are control delays, and motor response delays, and detection delays, the jitter in the system is bound to be fairly high also.
So if the only choices of sample rate are 1-10, then 10 uSeconds is clearly the rate even though it would seem to be overkill by a factor of 30
2) PWM for servos
The SG90 has a deadband of 7-10 uSeconds and requires a pulse width of 500-2400 uSeconds or 800-3000 uS.
(one place said 800uS = 0 deg. and 3000uS = 180 deg)
I think that means that the servo will not notice differences of less than 10 uSeconds.
1900 to 2200 uSeconds of pulse width range divided by the dead band probably means I can request 190 to 220 different servo positions.
Something like 85-110 left of center and 85-110 right of center, so I can point my range sensor with one to two degree precision.
I read that the maximum beam width for my Sharp IR sensor is about 16cm at midrange of 30" or 5 degrees wide.
I think that means I should take readings about 2.5 degrees apart, which would seem to match the pointing precision with a 10uSec dead band servo.
If the PWM for the servos comes from pigpiod bit-banging the GPIO lines, what sample rate do I need to get this 10uS precision?
3) PWM for DC motors
Maintaining a straight path with the 32 event encoders would seem to mean I want a speed error controllable to the precision of the encoders.
I assume the motor control should count a few wheel encoder events to get a speed for each wheel, and then modify the input to the motor.
I don't know what the motors' angular velocity "dead band" is. I think most people run their bots with 8bit velocity commands,
and some at the low value are useless because the bot doesn't start moving until some minimum power/"velocity" command.
This seems like it is a slow process compared to the wheel encoders which are 30 times slower than the servo demands.
BUT - I read that the PI has a built in PWM on two pins. I had planned these for the DC motors, but if the DC motors are the less demanding, perhaps the Pi should control the tilt/pan servos and the pigpiod should bit-bang the motor PWM which would reduce the event load on the pigpiod by a factor of 30.
I'm so confused now.