[Dprglist] Assisting PID odometry with an IMU

John Swindle swindle at compuserve.com
Sat Jan 23 10:18:33 PST 2021


Possible source of oscillation: Will Kuhnle warned me to not put encoders on the wheels or on the output shaft of the gearbox, else the windup and unwrapping of the gears would cause oscillation and gearbox damage. Analog controls such as PID need to be before the gearbox. I may have misunderstood, and I may be misrepresenting the admonition Will gave me, but it does sound right to me.
Bob Pease wrote about PID tuning and how it is no different than fuzzy logic in the sense that one can be transformed into the other with exactly the same response.
I thought someone posted a PID tuning algorithm long ago here. I don't care about it very much, so I haven't looked for it. I think maybe Will or Ron made a presentation on it. It doesn't require tweaking. It chooses the correct settings merely based on the system's response.
If you can kick the thing, you can measure its impulse response and made a filter without doing any tuning. I think the reason that isn't done more often is that it's nearly impossible to give the thing a good impulse kick. But it's definitely what the large FIRST teams do. Their very heavy, very tall robots fling themselves across large arenas and stop with no wiggling even though their frames are not completely rigid. I know at least one team does this with frequency response plots.
None of this requires ML or AI, and ML and AI do not make it better, easier, faster, or cheaper.
Later,John Swindle

-----Original Message-----
From: Carl Ott via DPRGlist <dprglist at lists.dprg.org>
To: Murray Altheim <murray18 at altheim.com>
Cc: DPRG <dprglist at lists.dprg.org>
Sent: Sat, Jan 23, 2021 7:57 am
Subject: Re: [Dprglist] Assisting PID odometry with an IMU


Hi Murray,
regarding PID tuning of your heading loop -
have you tried to examine the heading loop step response?
For example - what happens if you place your robot on that turntable at your desk -turn on the PID loop so that the robot tries to maintain a constant heading, without any forward motion -then give the turntable various disturbances - especially abrupt step-function changes - where you slew the table 30 or 40 degrees, with the slew-rate change in table rotation speed as high as possible (ie. zero to max turn-rate as quickly as possible, then max turn-rate to zero as quickly as possible).
If you had a super-beefy motor you could automate turn-table rotation to make a repeatable test-bed.  Otherwise you could just do it by hand.
The robot should try to re-orient itself to maintain the same heading even as you rotate the table underneath it.
As you observe the robot response - look to see if the heading correction overshoots and rings before it settles on the correct heading, or if it just takes 'forever' to finally creep to the right heading / if it ever even reaches the right heading.
OR - on a stable surface without the turntable complication -perhaps you could do an even better step-response test by adding a tiny bit of code...
what about adding a software motor drive enable/disable switch, one that you could toggle wirelessly from your laptop?   
   - Give the robot a 'zero' heading set-point with the PID loop and motor drive on - 
   
   - let it settle on that heading.
   
   - Then turn the motor drive off, 
   
   - but leave the PID loop on.
   
   - Then manually turn the robot something like 45 degrees and take your hands off of it.
   
   - At this point, you have introduced a large step error - 
   - and you're about to ask for the maximum possible slew rate response - a step response
   
   - Then turn the motor drive back on, 
   
   - and watch the robot's 'return-to-zero' behavior.
   
   - At first you could iterate steps 1..4 and dial-in PID values just by eyeballing the step-response.
   
   - Your goal is to have the robot 'return-to-zero' as quickly as possible, without overshooting
   
   - But to really dial things in, you could use a video to accurately look for overshoot and measure timing.   


- Carl


On Sat, Jan 23, 2021 at 1:28 AM Murray Altheim via DPRGlist <dprglist at lists.dprg.org> wrote:

Hi Doug,

My initial question was asking what might be the algorithm for
handling the rug bumps. Finding a Python library that handles this
is great, but I must admit I was still a bit adrift as to how to
actually incorporate it into my robot's behaviour. It'll take me a
bit of time to digest what you've written, and try it out in code
on my robot, but you've actually answered that question, i.e., how
to work out how to take that IMU error and incorporate it into the
robot's motor outputs.

Thanks very much for that!

One of the things I keep getting reminded of is that while there's
a lot of focus on fancy sensors and such (but of course!), some of
the more "basic" stuff in robotics is actually pretty tricky to get
right. Precise navigation and odometry is quite difficult, which is
what makes it all the more impressive to see done well.

Cheers,

Murray

On 23/01/21 7:17 pm, secretary at dprg.org wrote:
> Murray,
> 
> One approach is to take the theta value from the IMU instead
> of calculating it from the encoders, and then adding the 
> heading error to the summing node of the negative feedback loop.
> 
> Taking the theta value form the IMU:
> 
> /* accumulate total rotation around our center */
> /*theta += (left_inches - right_inches) / WHEEL_BASE; */
> 
> /* replace theta value with IMU yaw value */
> theta = read_IMU_yaw();  /* make sure that the units and orientation are correct */
> 
> /* and clip the rotation to plus or minus 360 degrees */
> theta -= (float)((int)(theta/TWOPI))*TWOPI;
> 
> Now the theta value is from the IMU and should show the impact of
> your rug/floor disturbance.
> 
> The next part is to add the heading error (heading error = heading
> target – theta) to the input summing node of your negative feedback
> loop. The heading error is zero when you are going in the right 
> direction, elsewise it will have either a negative or positive 
> value. It will be summed in with your reference value (desired 
> speed in this case) and the -feedback value (PID error). If you 
> view it in terms of your PID error, it is like you are changing 
> the reference value.
> 
> I hope this helps.
...........................................................................
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

_______________________________________________
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/20210123/6d9672bd/attachment.html>


More information about the DPRGlist mailing list