[Dprglist] straight lines

[Paul Bouchier]

Doug, Re your statement about David probably using a P controller with
Kp=1, he made it very clear at last RBNV that he is not using a
proportional controller; that he adds & subtracts a speed offset from each
wheel's setpoint that is a constant, irregardless of the magnitude of
angular error. i.e. Kp=0. He mentioned the amount of offset as being around
10-15% of full speed, though I imagine it's adjustable. The point is it has
constant magnitude, regardless of the magnitude of the angular error.
Cheers
Paul

On Sat, Jan 15, 2022 at 9:22 AM Doug Paradis <paradug at gmail.com> wrote:

> Paul,
>     Regarding the method of reading encoders. I suggest that you try pulse
> timing instead of pulse counting for low encoder ticks per period.  The
> following is a quote from the article at
> https://www.motioncontroltips.com/how-are-encoders-used-for-speed-measurement/,
> "With the pulse timing method, a high-frequency clock signal (like the
> system clock) is counted during one encoder period (the pitch, or
> interval between two adjacent lines or windows). The number of cycles of
> the clock signal (m), divided by the clock frequency (f), gives the time
> for the encoder period (the time for the encoder to rotate through one
> pitch)."
>
>   I suspect that if you look into the details of David 's code, he is
> actually using a P controller to correct the heading error with a Kp of 1
> (or a scaled value) but doesn't call it a P controller. In other words, the
> "rotation" is something like rotation = delta encoder counts (i.e.,
> rotation = Kp (delta encoder counts, where Kp = 1).
>
> Regards,
> Doug P.
>
> On Sat, Jan 15, 2022 at 5:32 AM Paul Bouchier via DPRGlist <
> dprglist at lists.dprg.org> wrote:
>
>> David - going back to your description of how you manually turned the
>> wheel a little bit when the speed was supposed to be zero, and the integral
>> of speed error built up until it overpowered you and drove the wheel back
>> to where it started - I'm confused because I don't understand how you must
>> be calculating speed for that to be true. A naive implementation of
>> speed-measurement would be to count the number of encoder counts in each
>> 40ms tick. So when you manually moved the wheel, let's imagine there were a
>> few ticks when a few counts were detected, then no more counts in any
>> subsequent ticks. Speed should be zero after motion stops, so where's the
>> error to integrate and cause corrective force to build up over time? Put
>> another way, there was a speed error a few seconds ago but now there's no
>> speed error; when does that error "go away", and when does the PID loop
>> stop remembering it and trying to fight against it?
>>
>> This is relevant to my current concerns with Mowbot, since it was
>> discovered at Tuesday's meeting that the low rate of encoder ticks on
>> Mowbot means I'll only see 2 or 3 counts per tick (hard to control), so I'm
>> thinking about adopting Pat's approach (which he gave up on) of measuring
>> the period between count incrementing. Pat - I'm also wondering why you
>> gave up on that approach and changed encoders to one that has more counts -
>> was there some basic flaw in the approach?
>>
>> Thanks
>>
>> Paul
>> _______________________________________________
>> DPRGlist mailing list
>> DPRGlist at lists.dprg.org
>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20220115/c2a0bc33/attachment.html>