[Dprglist] PID-tuned Clock in Python?
Murray Altheim
murray18 at altheim.com
Thu Feb 18 18:21:30 PST 2021
On 19/02/21 1:40 pm, Iron Reign wrote:
> Murray wrote: >> What do you mean by RTOS being the papa red herring? Just that
>> we all need to stop assuming accurate clocks?
> > Pretty much, yes to your question. Though typically the hi-res
> clocks (not RTCs) are pretty darn accurate.
Do you know of a hi-res hardware clock for the Raspberry Pi? All
I've ever been able to find is the RTCs, which are plentiful.
> 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.
Understood.
But when there's almost nothing going on, an Arduino-compatible's
micros() function is pretty accurate, certainly accurate enough
for my purposes at apparently about 4µs error (which is a number
I found regarding a 16MHz Arduino; on the 120MHz M4 it might be
better). I'm still investigating:
A smarter way to write micros()
http://micromouseusa.com/?p=296
How to precisely measure microseconds with STM32
https://www.carminenoviello.com/2015/09/04/precisely-measure-microseconds-stm32/
[Any microsecond timer in C compatible with a Cortext M4 would be
welcome... seems a lot of "opinions" out there.]
> 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.
I don't currently have the need to correlate data as I'm not trying
to accumulate it, in the sense of keeping it for later analysis. My
robot gets drunk when my 50ms clock gets pulled waaay off, but is
fine in the +/-2ms range. So it's pretty tolerant, just not when its
Clock gets resource-starved and hits 70ms rather than 50ms. I'm not
sure if trying to adjust everything on the robot for those 70ms
periods is as good as finding a more accurate way to generate the
clock cycles.
For background, my ros* has a Python class called Clock that generates
TICK events at 50ms (20Hz) and TOCK events every 20 TICKs (@ 1 sec).
The Clock class has a loop, but of course that loop is running on
Python on Linux, hence the problem. Those TICK events are the timing
backbone of my message bus architecture: they get received by pretty
much anything that used to be its own Python thread, before I discovered
that threads in Python aren't like those in Java. So that means that
if those TICKs come through accurately everything will be Just Fine.
With that notion of having an RTOS (e.g., a 120MHz Itsy Bitsy M4) doing
nothing except providing an accurate 50ms/20Hz clock pulse as an
output on a pin, and capturing that pulse on a Raspberry Pi's GPIO pin
(treated as close to an interrupt as possible on a Pi) as an improved
alternative to my Clock class, well, that seems to be something worth
at least exploring. If the overhead in doing that is timewise-consistent,
great, if not, then it's of no help at all, just added complexity.
I've got the Itsy Bitsy velcroed onto my KD01 and will try that out.
I haven't quite given up yet...
Cheers,
Murray
* I'll use lowercase to not confuse *my* ros with the better known ROS
...........................................................................
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
More information about the DPRGlist
mailing list