[Dprglist] PID-tuned Clock in Python?

[Murray Altheim]

On 19/02/21 10:58 am, David Anderson via DPRGlist wrote:
> Howdy,
> 
> Not to be overly pedantic...

Hi David,

I wouldn't accuse you of that. The subject we're talking about
has not been resolved, so there's still stuff to talk about. I
don't think that could be considered pedantic.

> But another solution to these timing problems is to use a
> micro controller that is not running Linux to do your real 
> time stuff. The STM32 Nucleo board I'm using with an RTOS 
> has a context switch time which is reliably less than 10 us 
> (which is actually the least I can measure).

As I just responded to John, and in furthering our ongoing topic
of robots containing master and slave (controller and sub-controller)
hybrids, it's also possible to have a Linux master controller that
provides higher-level functionality, like a command line, remote ssh,
support for machine learning, live-streaming video for telerobotics
(which I've done and want to continue to do), multiple cameras,
programming in Python (for those who either prefer, use libraries
of, or otherwise want to learn the language), and farm out the RTOS
stuff to sub-processors.

There's also a substantial number of not-so-old-guys and gals who are
simply more comfortable learning Python but not C/C++. As someone with
experience in well over a dozen languages, I'm actually *enjoying*
working with Python. YMMV, of course.

A few days ago I was chatting with a work colleague who's done some
commercial as well as personal robotics, and he's capable of
programming in C/C++, Python, and FPGA coding on a Terasic DE2, and
while he says he "hates" Python it's still his main language for
actual implementation. BTW, it seems almost everyone hates the
programming language they use daily because they're constantly
exposed to its failings and limitations, like that potential romantic
partner who seems really interesting until you live with her/him
and realise they also leave hair plugging up the shower drain.

But to be clear, this is both a Linux and a Python issue, as while
it's possible to run Micropython or CircuitPython on a microcontroller,
we'd lose the time-sharing OS but still have the Python threading
issue. So we need to be on C/C++ on a microcontroller, which is you
must admit rather limiting, not in what you can do with the robot so
much as in *how* you do it. And if you want ROS or machine learning
on the robot you're going to need more than that.

> I understand the arguments for using Linux.  I've been using
> it both at work and home since the early 1990s.  But not on
> robots.  If the argument is that it makes robotly things
> easier, I'm not sure anyone's experience bears that out.
> 
> Right tool for the job, as the old guys use to say.

I agree. But if the right tool for the way I work means that I want to
have a command line and be able to ssh into my robot so I can code and
test right on the platform, and commit the code to github right from the
robot (i.e., that's how I work), then that's not going to happen on a
microcontroller. We all have varying requirements and work habits.

I don't disagree with your fundamental point, but I think the subject of
hybrid controllers on robots is likely the real answer here. We're already
doing that with our increasingly-complex sensors, that themselves have
their own internal processors, some simple, some amazingly complex, like
cameras-as-sensors like the Pixy2 or rice-grain sized LIDARs and Optical
Flow Sensors.

I'm still working towards that hybrid, trying to figure out the best way
to communicate signals from sensor groups (like my Integrated Front Sensor,
which has six lever switches and five analog IR sensors, and sends all its
information back to the Pi via I2C) back to the Pi, so I leave the higher
level functions to the Pi and lower to the RTOSs. My current issues are
due to trying to do RTOS stuff on the Pi. Admittedly.

As I mentioned to John, I'm considering taking my otherwise unused Itsy
Bitsy M4 or some other very small microcontroller and writing a timer
loop into it, then wiring its output into a GPIO pin as an interrupt,
then using *that* as my timing loop since it'd be entirely independent
of the system load on the Raspberry Pi (and therefore reliable). I'd
looked into Real Time Clocks for this but unfortunately their resolution
is typically 1 second and have no millis() or micros() support. This
solution I believe can give me a ~5uS accuracy.

I realise this is a bit bass-akwards to what one would do solely with a
microcontroller, but if my requirements include remote access (ssh) and
Python, and access to github, then the Pi is in the mix and this may be
a viable solution. Otherwise I'm going to have to entirely change my work
habits and start hooking up a USB cable to my robot to program and control
it, which makes it hard to drive around with the cable attached. And I
can't do all the things I want solely with a single microcontroller.

I hope you all managed to catch the Perseverance Rover successfully landing
on Mars about an hour ago. Pretty amazing!

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