[Dprglist] KD01 Rotate in Place video
John Swindle
swindle at compuserve.com
Tue Jan 26 16:33:11 PST 2021
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.
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.
So, I wonder if the lack of 50ms repeatable intervals is due to the way Python works, and not your fault.
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.
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.
Good luck.
John Swindle
-----Original Message-----
From: Murray Altheim via DPRGlist <dprglist at lists.dprg.org>
To: dprglist at lists.dprg.org
Sent: Tue, Jan 26, 2021 4:32 pm
Subject: Re: [Dprglist] KD01 Rotate in Place video
Hi John,
It looks like the surge is entirely software and not related at all to
hardware, motors, gears or caster. It happens on the test bench with
the robot not actually moving, and just to check if the gearboxes are
under any tension I wiggled the wheels when they come to rest to jiggle
the gearboxes -- this has no effect, the surge still occurs.
It looks like the surge is due to either the PID controllers maintaining
state or the PID loop somehow not getting called on time. I'll describe
this in more detail below.
Just to clarify what the manual velocity test actually does, it performs
this sequence:
a. accelerate from zero to target velocity, same direction on both
motors (i.e., rotate in place). First cycle counter-clockwise.
b. cruise for 5 seconds
c. decelerate to zero
d. wait 5 seconds
e. spit out PID state data (then reset)
f. accelerate from zero to target velocity, same direction on both
motors (i.e., rotate in place). Second cycle is clockwise.
g. cruise for f seconds
h. decelerate to zero
The Python code can be found at:
https://github.com/ifurusato/ros/blob/master/manual_velocity_test.py
Upon returning from rotating counter-clockwise to clockwise (or vice-versa) that
first acceleration at (f) from 0 to 1 to 2 to 3 (eventually to 50) the PID
controllers aren't actually starting a stateless transition. I.e., to be clear
if we only do one of the two acceleration-cruise-deceleration cycles (either a-c
or f-h) the surge doesn't occur. So I started resetting the PIDs by clearing out
any state variables at (e), but sadly this didn't cure the woes.
Looking at the console output when starting up at (f) we see:
2021-01-27T11:24:26.135.905504Z : pid:port : INFO : __call__ dt: 0.0501
2021-01-27T11:24:26.148.790836Z : pid:stbd : INFO : __call__ dt: 0.0501
2021-01-27T11:24:26.186.000347Z : pid:port : INFO : __call__ dt: 0.0501
2021-01-27T11:24:26.198.897362Z : pid:stbd : INFO : __call__ dt: 0.0501
2021-01-27T11:24:26.225.871086Z : main : INFO : accelerating to set point: 50.00...
2021-01-27T11:24:26.226.798534Z : pid:port : INFO : reset ===============
2021-01-27T11:24:26.227.556705Z : pid:stbd : INFO : reset ===============
2021-01-27T11:24:26.228.170633Z : main : INFO : set point: 0.00 ; velocity: 0.00 / 0.00;
2021-01-27T11:24:26.236.160994Z : pid:port : INFO : __call__ dt: 0.0087
2021-01-27T11:24:26.236.850977Z : pid:port : INFO : __call__() last output: 0.00
2021-01-27T11:24:26.249.022245Z : pid:stbd : INFO : __call__ dt: 0.0209
2021-01-27T11:24:26.249.667406Z : pid:stbd : INFO : __call__() last output: 0.00
2021-01-27T11:24:26.286.290646Z : pid:port : INFO : __call__ dt: 0.0588
2021-01-27T11:24:26.299.113750Z : pid:stbd : INFO : __call__ dt: 0.0710
2021-01-27T11:24:26.329.402447Z : main : INFO : set point: 1.00 ; velocity: 1.00 / -1.00;
2021-01-27T11:24:26.336.445808Z : pid:port : INFO : __call__ dt: 0.0502
2021-01-27T11:24:26.349.218369Z : pid:stbd : INFO : __call__ dt: 0.0501
2021-01-27T11:24:26.386.672974Z : pid:port : INFO : __call__ dt: 0.0502
2021-01-27T11:24:26.399.346352Z : pid:stbd : INFO : __call__ dt: 0.0501
2021-01-27T11:24:26.431.238651Z : main : INFO : set point: 2.00 ; velocity: 2.00 / -2.00;
2021-01-27T11:24:26.436.789513Z : pid:port : INFO : __call__ dt: 0.0501
2021-01-27T11:24:26.449.603558Z : pid:stbd : INFO : __call__ dt: 0.0503
2021-01-27T11:24:26.486.915588Z : pid:port : INFO : __call__ dt: 0.0501
2021-01-27T11:24:26.499.716043Z : pid:stbd : INFO : __call__ dt: 0.0501
2021-01-27T11:24:26.533.149719Z : main : INFO : set point: 3.00 ; velocity: 3.00 / -3.00;
it's clear that the normal 'dt' delay of 0.501 (50ms, 20Hz) PID calls are for
some reason suddenly coming in at 0.0087 (about 9ms), then 0.0209, 0.0588,
0.0710, until coming back to their 50ms normal. I tried going clockwise first,
then counter-clockwise; it does the same thing. The test is entirely repeatable:
it will happen like this every time, and that timing error is always there.
I'm at this point attributing the surge to this timing error (i.e., the calls not
occurring at 50ms intervals), and continue to investigate why this is occurring.
It's not due to threading or anything like that; it's clearly my code's fault.
Cheers,
Murray
On 26/01/21 9:12 pm, John Swindle via DPRGlist wrote:
> The slight surge is likely due to windup. The gears were at limit when the first rotation stopped, so the second rotation would have a delay and then a jerk.
>
> Also, the caster has to rotate, and that creates an effect that the control system might not know about.
>
> Suggest a windup preamble in all motor commands.
>
> I am not a mech eng, but I joined DPRG to learn relevant mechanical things, and I've learned more than I expected.
>
> Later,
> John Swindle
>
>
> -----Original Message-----
> From: Murray Altheim via DPRGlist <dprglist at lists.dprg.org>
> To: dprglist at lists.dprg.org
> Sent: Mon, Jan 25, 2021 1:52 am
> Subject: Re: [Dprglist] KD01 Rotate in Place video
>
> I've just updated the KD01 Rotate-in-Place Test video on YouTube, which now
> performs a bit better than the previous version: the KD01 accelerates properly
> up to speed counter-clockwise, maintains that for 10 seconds, then decelerates
> to a stop, then does the same thing clockwise:
>
> KD01 Rotate in Place Test
> https://youtu.be/HICrQzAZPow
>
> The position of the robot at the end of the test is about 4cm from its initial
> position, which isn't too bad all things considered. There is a noticeable
> surge when the robot starts again clockwise after a pause. I'm not sure what
> this is caused by -- nothing in the code is indicative -- but I'm overall
> happy with the result. I think it helped that I ran the test this time on
> some smooth particle board.
>
> The NZPRG Python robot code can be found at:
>
> https://github.com/ifurusato/ros
>
> with the rotate-in-place test file at:
>
> https://github.com/ifurusato/ros/blob/master/rotate_in_place.py
>
> The KD01 is a differential drive robot that uses a Raspberry Pi with a
> PiBorg ThunderBorg motor controller, an OSEPP drive train and hall effect
> motor encoders, a tiny Adafruit Mini PiTFT 135x240 Color display that I
> use as a console window, which includes two small buttons I've wired up
> to initiate/control the test. The rear caster is an OSEPP wheel installed
> into the frame of a commercially-available caster.
>
> Cheers,
>
> Murray
>
> On 23/01/21 4:04 pm, Murray Altheim via DPRGlist wrote:
> > Sometimes it's important to prove one is making progress. Not that this is
> > advancing the science at all but I've just posted a video showing the KD01
> > differential drive robot rotating in place using its PID controllers: [...]
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com> = = ===
> http://www.altheim.com/murray/ <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 <mailto:DPRGlist at lists.dprg.org>
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
--
...........................................................................
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/20210127/b98795be/attachment-0001.html>
More information about the DPRGlist
mailing list