[Dprglist] PID-tuned Clock in Python?

[Iron Reign]

Pretty much, yes to your question. Though typically the hi-res clocks (not
RTCs) are pretty darn accurate. That's completely different from loop times
being regular/consistent to the nth degree. RTOSs strive mightily to
guarantee a very regular loop time or a certain responsiveness. But the
more complex your system, the less "guaranteed" that is. There are just too
many things going on.

I think if you give up the notion that your loop times need to be regular
and bite the bullet on normalizing your time-based sensor readings before
doing anything else with them, you'll find it very liberating. Free
thyself! That notion belongs to the microcontroller domain. You might find
that your robot becomes much more resilient to handling responsiveness
hiccups.

That said, at some point you may find yourself wanting a
synchronized global clock reference and timestamps accompanying sensor
readings if you have multiple deeply buffered sensor streams that need to
be correlated in time. But that can often be profiled. As an example,
webcam frames coming through a vision pipeline can be laggy compared to
encoder readings and if you are trying to fuse the data, you need to
correlate the readings from the same era.

But that's a natural emergent "feature" as you scale how widely distributed
any system becomes. I'm just pointing out that if you're on Linux or
something similar, you're already on that spectrum. Roll with the
consequences.


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

> On 19/02/21 12:40 pm, Karim Virani wrote:> [...] 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?
>
> Hi Karim,
>
> As I just wrote (your message came in just as I sent my response to David),
> we all have a differing set of experience, interests, requirements and work
> habits. Mine is that I want to be able to ssh in to my robot, do my coding
> and testing on it, push to github from it, and often even operate the robot
> remotely. This requires ssh and an active WiFi connection. In the future I
> hope to be able to operate the robot entirely without WiFi, but for now,
> that's both how I work and how I control my robot. And secondly, even given
> its difficulties, I'm at this point am trying to focus on using Python,
> for personal and professional reasons, and so far for the most part I'm
> enjoying not regretting that decision.
>
> > 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. [...]
>
> I don't really have any disagreement with your disagreement. I tried to
> answer some of those concerns in my message to David.
>
> So I have just one question, out of curiosity:
>
> > RTC's are a baby red herring. RTOS is the papa red herring. Unless,
> maybe,
> > if you're landing on Mars...
> What do you mean by RTOS being the papa red herring? Just that we all
> need to stop assuming accurate clocks?
>
> 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/6dd6967a/attachment.html>