[Dprglist] straight lines

[David P. Anderson]

Paul et al,

This is not correct.  What I  attempted to make "very clear" is that the 
STEERING of the robot does not use a proportional controller, but rather 
a linear controller with a deadzone.  That all happens above the level 
of the two PID controllers, which obviously DO incorporate a 
proportional term, the "P" in "PID."

I obviously need to think about my communication skills, as I "very 
clearly" did not explain this well.

cheers!

dpa


On 1/15/22 11:08 AM, Paul Bouchier via DPRGlist wrote:
>
> */[EXTERNAL SENDER]/*
>
> 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 
> <mailto: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/
>     <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 <mailto: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 <mailto:DPRGlist at lists.dprg.org>
>         http://lists.dprg.org/listinfo.cgi/dprglist-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/81119edc/attachment.html>