[Dprglist] straight lines

Sat Jan 15 11:24:26 PST 2022

Paul,
    Reading over what I typed before I noticed I might have been a bit
unclear. If using micros(), any delta time calc should be done outside of
the ISR (i.e., keep the ISR short).
Regards,
Doug P.

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

> 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/915fc01d/attachment.html>