[Dprglist] My PID problem solved
Murray Altheim
murray18 at altheim.com
Thu Jan 28 15:31:17 PST 2021
On 29/01/21 11:43 am, David Anderson via DPRGlist wrote:
> Murray,
>
> A quick-and-dirty test to see if the encoders are behaving
> properly. I do this when first set up, and then whenever
> any changes are made.
>
> 1. Keep a running total number of encoder counts on each
> wheel (as opposed to the velocity) and print those totals
> in realtime to your nifty onboard display. > [...]> I've found this simple test can uncover a lot of potential problems.
Hi David,
I don't disagree with any of your suggestions. I actually was
doing most of those things and had several tests to demonstrate
my motor encoders were working okay. I'd even gone so far as to
calculate (and test) this kind of thing, resulting in the ability
to begin to calculate values in SI units for velocity, e.g.:
494 encoder steps per rotation (maybe 493)
68.5mm diameter tires
215.19mm/21.2cm wheel circumference
1 wheel rotation = 215.2mm
2295 steps per meter
2295 steps per second = 1 m/sec
2295 steps per second = 100 cm/sec
229.5 steps per second = 10 cm/sec
22.95 steps per second = 1 cm/sec
1 rotation = 215mm = 494 steps
1 meter = 4.587 rotations
2295.6 steps per meter
22.95 steps per cm
and this was reliable enough (at least within a reasonable error
range) that I hardcoded the values into a Geometry class:
https://github.com/ifurusato/ros/blob/master/lib/geometry.py
There's a log output on the Decoder class that spits out the step
counts and calculated velocity from a test class, e.g.:
2021-01-29T11:05:46.575.283289Z : motor:stbd : DEBUG : stbd: +6837 steps; velocity: 11.07
2021-01-29T11:05:46.581.825256Z : motor:stbd : DEBUG : stbd: +6838 steps; velocity: 11.07
2021-01-29T11:05:46.589.429855Z : motor:stbd : DEBUG : stbd: +6839 steps; velocity: 11.07
2021-01-29T11:05:46.598.232031Z : motor:stbd : DEBUG : stbd: +6840 steps; velocity: 10.06
It was actually setting the log level to DEBUG on the Decoder class to
see if the callback triggered from the encoders was still somehow coming
in when the motors were at rest (ot wasn't) that clued me in to the
problem, which was entirely due to my not thinking through the fact
that I was relying on those continued callbacks to calculate motor
velocity; when the callbacks stop arriving (like when the motors are at
rest) the velocity calculations would stop and the output on the log
just continued to spit out the last value. My little Eureka moment!
I'm reminded of how at the peak of activity I'd heard that the Microsoft
Word team was about 1800 people, and many of the problems with the software
wasn't down to any lack of intelligence or even due diligence on the team's
part -- they were some of the more brilliant and well-paid engineers in the
industry -- it was due to the complexity of the project getting beyond the
ability of any management to handle it. Throwing more money or people at
the problem only made things worse. This can happen when the complexity of
any project rises above the level where it can be managed. This is a good
reason to try to keep one's projects as simple as possible.
With a team of one (me) there are times when the complexity of my project
is simply beyond my ability to (in its entirety) grok. And therefore there
are times I simply can't see the forest for the trees. Stepping back and
trying to think logically, along with lots of good logging and metrics,
is what led me to the solution. If there's any takeaway, it's in writing
good tests, lots of logging and console output, and building things
incrementally, and perhaps, using modules. Keeping the size of any
individual file (or class) small.
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
More information about the DPRGlist
mailing list