[Dprglist] KD01 Rotate in Place video

John Swindle swindle at compuserve.com
Tue Jan 26 19:33:55 PST 2021

I always wondered why anyone had a lead pipe laying about. Clueless.

-----Original Message-----
From: Murray Altheim via DPRGlist <dprglist at lists.dprg.org>
To: dprglist at lists.dprg.org
Sent: Tue, Jan 26, 2021 7:24 pm
Subject: Re: [Dprglist] KD01 Rotate in Place video

On 27/01/21 1:33 pm, John Swindle via DPRGlist wrote:
> Murray,
> Good diagnostic tests.
> I am clueless about Python, but, Yes, your timestamps show 
> something you didn't intend. I've read the rationale of 
> Python and some of the code documentation, but I still can't
> read and understand a single line of it.

Hi John,

I guess your mileage may certainly vary as regards Python. I've
been programming in many languages since the late 1970s and came
to Python rather late, but I can't share your feelings about it.

Worries about performance aren't so much a concern when running
on the CPUs we do nowadays. A Raspberry Pi runs at 1.4GHz, the
ARM Cortex M0-4 processors are running from 48MHz up to 120MHz
range, the Orange Pi is a 2.0GHz quad-core, the NanoPi Fire
runs 8 cores at 1.4GHz. So we're no longer dealing with the
16MHz of older Arduinos. I'm not suggesting that throwing metal
at a problem is a good way to solve performance issues, but the
bottleneck in 2021 isn't likely to be the Python interpreter,
certainly not on a small robot.

For myself, I've really enjoyed working with it as a language
and a developer "ecosystem", and have found it very quick to
learn. Coming from over twenty years as a Java infrastructure
developer I thought I might miss Java but actually almost prefer
Python for projects where it makes sense (e.g., not for large
infrastructure systems). And I like the syntax, nowadays even
more than Java. But I also realise this kind of thing is
entirely down to taste/aesthetics.

The one real driver for me is that I'm using mostly Adafruit,
Pimoroni and PiBorg hardware on my robots, all of which are
supported by Python libraries. The choice of language was a
simple matter of accepting that robots using this kind of
hardware would be programmed in Python.

> When I read that Python is still an interpreted language with
> very slow execution rates and non-deterministic rates, I quit
> learning about it. It's OK for things where time doesn't matter,
> like web pages or bulk transfers, but not for real-time things.
> Maybe I'm overlooking a real-time Python.

My one real issue with Python is its threading implementation,
which while looking a lot like (and influenced by) Java isn't
really a true multi-threading system. I've had to work around
that. For single threaded applications the choice of Python
would make very little difference performance-wise.

My own issues could also be down to my style of programming, as
I am using multi-threading, in particular for the PID loops.
It's entirely possible the timing issues are due to that, or
due to me running on Linux on a Raspberry Pi (a time-sharing OS)
rather than natively on a microcontroller. I am considering
running my robot's Python OS on an RP2040 to see if this makes
any difference.

> So, I wonder if the lack of 50ms repeatable intervals is due
> to the way Python works, and not your fault.

Well, I wouldn't say that's impossible but at this point I'm
putting this down to some fault on my part.

> When I see stuff like this in my code, I try to force the 
> interval by using a timer that I trust, or a loop that tunes 
> itself, kinda like a PLL. PITA.

As things stand, the PID call function returns the last value
set if called prior to the normal interval, so there's an element
of self-healing in the code now. In this case the value returned
would be 0.0 as the robot had been at rest. And in looking more
carefully at the code, it's not even clear that the timing is
the cause of the surge. I'm still digging...

In other words, trying to figure out what's happening is all a
bit of an Agatha Christie novel.

> Sorry to beat a dead horse, but wiggling the output gears 
> might not tell you anything. The ratios may be so high, and
> there may be gear types in the gearbox that cannot transmit
> power backwards to the motor. The output shafts could be 
> tight, and there could still be lots of gear slop on the 
> input shaft. If you can spin the motors by manually spinning
> the wheels, then disregard this.

The OSEPP motors I'm using have a 1:45 gear ratio, and yes, I can
spin the motor by turning the wheels. So I'm sticking with the
problem being entirely software. Mrs. Peacock in the conservatory
with the candlestick. Or the lead pipe. Or maybe Colonel Mustard
in the kitchen with the revolver.



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20210127/67121136/attachment.html>

More information about the DPRGlist mailing list