Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #518816

Re: PID loop frequency

Show all headers | View raw

On 09/10/2018 23:44, bill.sloman@ieee.org wrote:
> On Tuesday, October 9, 2018 at 11:03:39 PM UTC+11, Chris Jones wrote:
>> On 09/10/2018 17:30, Fitzgerald wrote:
>>> On 10/05/2018 05:04 PM, Chris Jones wrote:
>>>> On 06/10/2018 00:07, Fitzgerald wrote:
>>>>> I'm working on a digital PID motion controller. The target/goal is to
>>>>> move at (very) constant velocity. Position feedback is from a linear
>>>>> encoder with quadrature output. The input to the controller is a
>>>>> linear ramp (i.e. constant velocity) and the PID changes the motor
>>>>> output to minimize the error. The system works, but I'm looking to
>>>>> improve its performance at low velocities.
>>>>>
>>>>> At low velocities there are only a few pulses from the encoder per
>>>>> servo cycle. In the error signal I can clearly see this quantization.
>>>>> If I lower the frequency of the servo cycle; the controller
>>>>> performance increases (i.e. smaller velocity variations).
>>>>>
>>>>> Two questions:
>>>>> - Is there a method to determine optimal servo frequency?
>>>>> - Would it be beneficial to separate the controller in two control
>>>>> loops; an inner velocity loop and an outer position loop. Perhaps
>>>>> with both running at different frequencies?
>>>>>
>>>>> Any pointers to good documentation are appreciated.
>>>>
>>>> Maybe do reciprocal counting - measure the time between transitions of
>>>> the encoder, and from this time difference generate a velocity
>>>> estimate (and run the PID) on every edge from the encoder, with
>>>> variable timesteps.
>>>
>>> I'll see if I can implement and test this easily; may be worth a shot
>>> but I don't expect much of it.
>>>
>>> Measuring the time between the encoder edges doesn't seem a good
>>> solution as the time between encoder edges varies due to manufacturing
>>> errors in the encoder, see [1].
>>>
>>> [1] https://www.embeddedrelated.com/showarticle/444.php
>>
>> Whatever algorithm you use, if the encoder is inaccurate, the controlled
>> motion will be inacurate.
> 
> Moire fringe encoders average over a bunch of lines on both the moving array of slots and the two fixed arrays of slots that extract the in-phase and quadrature outputs.
> 
> The two fixed arrays of slots are written onto the same substrate so they stay 90 degrees out of phase even if the mounting gets jogged - this isn't guaranteed and idiot systems have been known to miss this, but such systems aren't popular.
> 
> You only need one single point light source to illuminate the back of the moving array, so it casts fairly sharp shadows on the two fixed arrays. Two photodetectors - one behind the in-phase array and the other behind the quadrature array - pick up the light that gets through both.
> 
> This averages over of the order of ten slots in each set of arrays, so you aren't counting discrete edges but rather the sum over the order of ten or so sets of edges. You can play with the dimensions and the optical set up to get more, if necessary.
> 
>> The only way I can see out of this is to
>> average over a long time period (or a lot of pulses so a long distance)
>> as you may be doing now, or with heroic effort, you could characterise
>> and store in memory the positional error of each edge on the encoder,
>> and use that later to correct for the encoder's manufacturing errors.
> 
> You shouldn't ever be able to see the error on an individual edge.
> 
>> Using a good encoder might be easier. Averaging over a long time period
>> will mean that short-term perturbations will not be corrected as well as
>> with a faster control loop.
> 
> You obviously aren't limited to time averaging. Moire fringe detection normally does an appreciable amount of spatial averaging, and you could fudge it to do more if that turned out to be helpful.
>   
>> With your existing algorithm, if you are just looking at the number of
>> edges that you have counted at each sampling instant, then your error in
>> the position estimate at each sampling instant can be up to +/- 90
>> degrees of the quadrature waveforms,
> 
> The edges coming out of a moire detector aren't all that sharp (and can be made less sharp by playing with the optics).
> 
>> in addition to any error in the encoder manufacturing.
> 
> The gratings are made by a photographic process, and could be spectacularly accurate.
> 
>> If you also timestamp the edges using hardware
>> each time they occur, and then figure out the velocity from the time
>> between edges, you should be able to get rid of most of the first part,
>> so that you know pretty much exactly where in the encoder cycle you are
>> at the time instants where an edge is detected. Only the manufacturing
>> errors (and imperfections due to finite clock frequency of your logic)
>> remain. I would suggest it might be a lot easier and more robust to use
>> an FPGA than a microcontroller to do this though.
> 
> It usually is, but is it worth the trouble?
>   
>> Given the choice, an encoder with a much finer pitch of lines, or one
>> with analogue sine and cosine outputs fed to ADCs may be a better
>> option, if a fixed sampling rate is preferred.
> 
> There are a lot of different ways of making position encodes.
> 
> <https://www.laserfocusworld.com/articles/print/volume-32/issue-10/departments/design-and-applications/diffractive-techniques-improve-encoder-performance.html>
> 
> Some of them do a lot of spatial averaging. Don't waste time reinventing the wheel.
> 

The OP raised the issue of the encoder having inaccuracy in its edges, 
and posted a link to an article that speculates about this.

I said that this was not a good reason not to measure the time between 
the edges, and I suggested that if it is a problem, rather than my 
work-arounds, "Using a good encoder might be easier". I guessed that he 
might say that he no longer has a choice about the encoder, and so I 
also discussed ways to mitigate it.

I know about the spatial averaging in the moire fringe type encoders, 
but I assume that there will be some residual imperfection in spite of 
this, and I treat the encoder as a black box with whatever errors it 
has, for the purposes of this thread.

Back to sci.electronics.design | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-05 16:07 +0200
  Re: PID loop frequency bill.sloman@ieee.org - 2018-10-05 07:53 -0700
    Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:08 +0200
      Re: PID loop frequency bill.sloman@ieee.org - 2018-10-09 00:11 -0700
  Re: PID loop frequency Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-10-05 10:58 -0400
    Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:12 +0200
  Re: PID loop frequency bitrex <user@example.net> - 2018-10-05 10:58 -0400
    Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:18 +0200
  Re: PID loop frequency Chris Jones <lugnut808@spam.yahoo.com> - 2018-10-06 01:04 +1000
    Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:30 +0200
      Re: PID loop frequency bill.sloman@ieee.org - 2018-10-09 00:21 -0700
      Re: PID loop frequency Chris Jones <lugnut808@spam.yahoo.com> - 2018-10-09 23:03 +1100
        Re: PID loop frequency bill.sloman@ieee.org - 2018-10-09 05:44 -0700
          Re: PID loop frequency Chris Jones <lugnut808@spam.yahoo.com> - 2018-10-10 00:01 +1100
            Re: PID loop frequency bill.sloman@ieee.org - 2018-10-09 07:33 -0700
  Re: PID loop frequency Lasse Langwadt Christensen <langwadt@fonz.dk> - 2018-10-05 08:49 -0700
  Re: PID loop frequency Jon Elson <elson@pico-systems.com> - 2018-10-05 13:59 -0500
  Re: PID loop frequency Hul Tytus <ht@panix.com> - 2018-10-05 19:52 +0000
    Re: PID loop frequency Jon Elson <elson@pico-systems.com> - 2018-10-05 15:46 -0500
      Re: PID loop frequency George Herold <gherold@teachspin.com> - 2018-10-05 18:05 -0700
      Re: PID loop frequency Hul Tytus <ht@panix.com> - 2018-10-06 18:49 +0000
    Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:38 +0200
  Re: PID loop frequency DJ Delorie <dj@delorie.com> - 2018-10-05 16:19 -0400
    Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:48 +0200
  Re: PID loop frequency tabbypurr@gmail.com - 2018-10-05 14:33 -0700
    Re: PID loop frequency Jasen Betts <jasen@xnet.co.nz> - 2018-10-06 02:14 +0000
      Re: PID loop frequency bill.sloman@ieee.org - 2018-10-05 19:49 -0700
        Re: PID loop frequency Klaus Kragelund <klauskvik@hotmail.com> - 2018-10-06 01:19 -0700
          Re: PID loop frequency bill.sloman@ieee.org - 2018-10-06 03:26 -0700
            Re: PID loop frequency George Herold <gherold@teachspin.com> - 2018-10-06 11:56 -0700
            Re: PID loop frequency Klaus Kragelund <klauskvik@hotmail.com> - 2018-10-08 06:27 -0700
              Re: PID loop frequency Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-10-08 10:22 -0400
                Re: PID loop frequency Klaus Kragelund <klauskvik@hotmail.com> - 2018-10-09 14:46 -0700

csiph-web