[Dprglist] straight lines

[Paul Bouchier]

Thanks Doug. What you describe is what I meant when I wrote I'm thinking
about adopting Pat's approach (which he gave up on) of measuring the period
between count incrementing.   The encoder ISR would run each encoder
transition and put the current value of millis() into a queue for
consumption by an odometer task. This would allow the task to compute the
most recent speed and delta-distance. I didn't express it very well :-(

On Sat, Jan 15, 2022, 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/648297ef/attachment.html>