[Dprglist] straight lines

[Pat Caron]

Hi Paul, I gave up on this approach as I was at a loss on how to get the
velocity calculated by the tick period to equal zero when the wheels were
stopped.  I was also using some Banebots reducers that were extremely noisy
for an indoor bot.
...Pat

On Sat, Jan 15, 2022 at 10:33 AM Paul Bouchier via DPRGlist <
dprglist at lists.dprg.org> wrote:

> 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
>>>
>> _______________________________________________
> 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/53f0b7f7/attachment.html>