[Dprglist] straight lines

[Doug Paradis]

Paul,
    The overflow time for micros() is ~70 minutes. If you use unsigned long
variables for past_time and this_time there is a simple way to handle the
overflow (I have to do an internet search everytime I do this to get it
straight). If millis() works go with it, but I might experiment with
micros() also.
Regards,
Doug P.

On Sat, Jan 15, 2022 at 12:50 PM Doug Paradis <paradug at gmail.com> wrote:

> Paul,
>     You most likely know this, but in case it is not high on your mind
> right now,  two points about millis() and micros() functions of the Arduino
> environment / Atmega chips when using interrupts:
>
> 1.  If you use millis() in an ISR, It will not increment while in the ISR.
> So don't make multiple calls to millis(). The value will not change from
> the first call (i.e., the value when entered the ISR).
>
> 2.  If you use micros() in an ISR and attempt to do delta timing, You have
> a chance of missing the TIMER0_OVF_vect and getting flaky results. Since
> you are using the micros() value that was the value when you entered the
> ISR, if the ISR goes on for too long you miss the overflow interrupt of
> timer0.
>
> The above are because the functions involve interrupts in their code, and
> you are basically calling an interrupt inside an interrupt. Atmega boards
> like the Uno and the Mega generally do not use nested interrupts. I hope
> this makes sense.
>
> Regards,
> Doug P.
>
>
>
> On Sat, Jan 15, 2022 at 11:40 AM Paul Bouchier <paul.bouchier at gmail.com>
> wrote:
>
>> Doug - Thanks for the suggestion about micros() instead of millis(). The
>> minimum edge-to-edge period is 12ms, and at 1/4 speed is 48ms. So millis()
>> would give better than 10% accuracy at full speed, and I wouldn't have to
>> deal with micros() rolling over every 70 minutes. That said, maybe I should
>> go for maximum accuracy. Do you think I need it?
>>
>> Paul
>>
>>
>> On Sat, Jan 15, 2022 at 9:36 AM Doug Paradis <paradug at gmail.com> wrote:
>>
>>> * micros()
>>>
>>> On Sat, Jan 15, 2022 at 9:34 AM Doug Paradis <paradug at gmail.com> wrote:
>>>
>>>> Paul,
>>>>     I would use micro() instead of millis().
>>>> Regards,
>>>> Doug P.
>>>>
>>>> On Sat, Jan 15, 2022 at 9:33 AM Paul Bouchier <paul.bouchier at gmail.com>
>>>> 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
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20220115/c261d8bd/attachment.html>