[Dprglist] PID-tuned Clock in Python?

Thu Feb 18 15:40:09 PST 2021

David, I see your pedantic and raise by downright nitpicky,

David wrote: "Right tool for the job, as the old guys use to say."

Agree. Much of the academic and startup robotics community has decided that
linux is very often the right tool. The question is what is the job?

Murray wrote: But that's not solving the problem, which is having a very
accurate millisecond timing loop."
and then: "assume an imprecise clock ... that would make our code more
complicated"

Disagree. My teams and I haven't seen a precise timing loop since 2014. In
fact under Android our loop times are downright gnarly. Get into the habit
of normalizing all time-sensitive calculations to actual elapsed time and
it becomes second nature. This tends to work for anything that sits in the
time domain of the kind of robot physical motions we'll experience in hobby
/ educational robotics.

I'm not talking about low level bit banging, ISRs or TOF calcs - or
anything like that. If you're trying to solve those kinds of things with
the same general purpose processor you use for robot governance and
behaviors, maybe the goal is the problem. This is where we look to
dedicated (smart) sensors and comms chips. The trend in that direction is
inexorable.

Now, if you started out with microcontrollers, might as well use all their
capacity. But they may be more suited to isolated lone-robot applications
and maybe not as much to highly interconnected environments. There may be
conflicting use cases at play here.

But we don't always follow our own use cases. The real truth is that we
start with what we are comfortable with (or what we have to use), and stick
with it until it proves insufficient. Hard to argue with that approach.
Getting started with anything goes a lot further than waiting for the
perfect hardware combo to appear before ye.

RTC's are a baby red herring. RTOS is the papa red herring. Unless, maybe,
if you're landing on Mars...

Otherwise, [wise-guy voice] don't worry about it.

On Thu, Feb 18, 2021 at 4:08 PM Murray Altheim via DPRGlist <
dprglist at lists.dprg.org> wrote:

> On 19/02/21 6:03 am, John Swindle via DPRGlist wrote:
> > Going back to a previous topic regarding jitter in timing intervals.
>
> Hi John,
>
> I was trying to find a paragraph of text that I saw a few days ago on some
> web page about how the combination of Linux and Python simply couldn't
> provide the kind of precise timing guarantees one can expect on a
> microcontroller, and I certainly don't contest that notion, i.e., this
> mirrors my own experience.
>
> Just to reiterate the issue (and I hope I've got all this correctly), Linux
> is a time-sharing operating system that cannot guarantee precise timing at
> an application level, even when the hardware it is running on (e.g., a
> Raspberry Pi or Intel 5.3GHz i9) has an accurate system clock, and may even
> have access to an RTC -- noting that an RTC provides an extremely accurate
> long-term clock but typically provides resolution only down to a second,
> not milli- or nanosecond. I.e., an RTC is a bit of a red herring.
>
> So running on a time-sharing OS means that any given application can't be
> guaranteed that it will be able to create precise time intervals at a
> nanosecond or millisecond level, since the application's code is sharing
> system resources with the system itself as well as other applications.
>
> One of those applications is the base Python/CPthon interpreter, which is
> an imperfect handler of timing, given its imperfect control of internal
> threading.
>
> So an application can ask the system clock for the number of milliseconds
> or nanoseconds since the Epoch (1 Jan 1970), and the number returned will
> be accurate, but if the application itself is running a timing loop it
> will be polling the system clock limited by its time share, not the system
> clock. So effectively, the loop will falter but know it's faltering by
> being able to compare its time with the system clock.
>
> > Why can't parameters used in calculations be scaled by the actual
> > sample interval? I understand 50ms is chosen because it gives
> > optimum control without undue overhead. When the actual interval is,
> > say, 47ms, why not scale the time-related parameters to 47/50 of what
> > they nominally are, just for that interval? If the next interval is
> > 74ms, scale the parameters to 74/50. Is this impractical? Is the
> > uncertainty of measuring the time interval too large? This is, if
> > Python says the time interval is 47ms, is the error, say, +/- 10ms?
>
> So given our understanding of the limitations of timing loops within a
> Python application running on Linux (i.e., not the operating system's
> internal clock), we can assume that with two levels of "indirection" any
> clock loop will run imprecisely.
>
> So a 50.00ms loop in Python will return values like 50.01ms, 51.3ms,
> 49.1ms, etc., and during a surge where another application pulls a lot
> of system resources the values might run 54.33ms, 57.56ms, etc. In other
> words, imprecise, intermittently and unpredictably so. You suggested
> that over a longer period, say several minutes, the average may be close
> to 50.0ms but that's not necessarily a safe assumption since the
> cumulative values are subject to cumulative error, and that error can
> be high. One can compare the value with the (accurate) system clock,
> or even with an RTC. But that's not solving the problem, which is having
> a very accurate millisecond timing loop.
>
> So the other alternative would be to write code to simply assume an
> imprecise clock and capture the per-loop error. The problem is that we
> haven't escaped the basic problem of "being in situ" with our code. And
> that would also make our code more complicated. A PID controller is
> itself already rather tricky to tune. Having an imprecise clock doesn't
> make that any easier.
>
> I'm looking into another alternative, since my KR01 has an Itsy Bitsy M4
> on board that is currently not being used. I'm thinking of using it as
> an external clock, triggering a GPIO pin as an interrupt on the Pi.
>
> Cheers,
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com>                       = =  ===
> http://www.altheim.com/murray/                                     ===
> ===
>                                                                     = =
> ===
>      In the evening
>      The rice leaves in the garden
>      Rustle in the autumn wind
>      That blows through my reed hut.
>             -- Minamoto no Tsunenobu
>
> _______________________________________________
> 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/20210218/560f7e3b/attachment.html>