Encoder connected to sim-encoder

More
07 Aug 2019 03:34 - 07 Aug 2019 03:42 #141563 by Nico2017
Hi all,
I am trying to simulate one of my position feedback with a simulated encoder. I therefore connect a sim-encoder phases pins to an encoder component phases pins. I have noticed that I get a small jitter. The sim-encoder velocity is nice and smooth as it is linked to a pos-cmd then I got a encoder.N.velocity which present a small square (discret) oscillations around the target value. 232 to 238 mm/s for the target speed of 235mm/s.

Is there a way to totally get rid of this jitter on the encoder velocity signal? I guess this is related to all my threads speed compared to the count rate.

In my ini file:
BASE_PERIOD = 100000
SERVO_PERIOD = 100000
TRAJ_PERIOD = 100000
In my hal file:

loadrt threads name1=very-fast-thread period1=50000 fp1=0

And then I put, to simulate a 100 pules encoder with a 200mm circumference encoder wheel :

addf encoder.ipdate-counters very-fast-thread
addf encoder.capture-position servo-thread
setp encoder.0.position-scale 2 #400 counts per revolution of 200mm circumference encoder wheel: 400/200=2

addf sim-encpoder.make-pulses very-fast-thread
addf sim-encoder.update-speed servo-thread
setp sim-encoder.0.ppr 100
setp sim-encoder.0.scale 200

My maximum velocity is about 240mm/s which gives 240/200 * 400 counts / s = 480 counts / s so 1 count takes 1/480 of a second so about 0.002s or 2 ms. So even my slowest thread being actually at 100000ns =0.1ms is 20 times faster than my expected counts rate. So I am surprised to still have a small jitter while I actually have my threads frequency at least 20 times the expected count rated where only 2 is recommended.

Increasing the threads frequencies (ie decreasing their period) to those values did decrease a lot this jitter but I am eventually getting closer and limited by the computer max jitter: Would you think that using a ddt on the encoder raw count then a scale over it (or the other way around) would give a smoother signal?

Many thanks in advance for your thoughts and help.

Nicolas
Last edit: 07 Aug 2019 03:42 by Nico2017. Reason: Typo correction

Please Log in or Create an account to join the conversation.

More
07 Aug 2019 04:29 #141570 by Nico2017
Hi again,
I tried the ddt over the rawcounts pin and I think I observed something related.

The ddt of the rawcounts is acutally going to jigger a lot from the value 0, when no count has been registered between two time step and the max velocity when the rawcounts is updated from one value to another between two time steps.

It looks that the jigger I got on the encoder velocity pin is actually syncrhonized the same signal where I did the ddt on the rawcounts then scale. So I suspect the encoder velocity to be based on a ddt but there is on top of it a filter or another process which does not put back the velocity value to zero when the rawcounts stay the same between two time steps. This process somehow let the velocity pin fluctuating between two values.

I have not had a look inside the encoder component yet as I am not familiar with C. But definitely worth to have a look as I would like eventually to write my components to.

Nicolas

Please Log in or Create an account to join the conversation.

More
07 Aug 2019 14:29 - 07 Aug 2019 14:30 #141613 by PCW
The encoder component does velocity estimation to get higher resolution than is
possible with straight counts/sample_time DDT. Basically it works by synchronizing
the sample period with the counts so that instead of using counts/sample-time,
(which might be 1,0,0,0,1,0,0,0 if moving slowly etc) it uses counts/time_between_counts.
The time resolution depends on the base thread period.

Mesa and other hardware encoder counters do this also but of course use a
hardware timer to measure the time difference between counts.
Last edit: 07 Aug 2019 14:30 by PCW. Reason: format a bit better
The following user(s) said Thank You: Nico2017

Please Log in or Create an account to join the conversation.

More
08 Aug 2019 19:53 - 08 Aug 2019 19:54 #141700 by Nico2017
Hi,
thank you for your answer. So would it be possible with this velocity method evaluation to get rid of the jitter, small oscillation or is it inherent to the counting method? If we can get rid of it, it there a minimum condition on the thread period regarding the pulse/rate?

I am just trying to get the best velocity signal as I might be ending up using it in a PID loop in position control but using the feedback-deriv input pin so the velocity speed feedback. Therefore I would like to avoid oscillation in my feedback signal but would like to have it as precise as possible as much as I can.
Thank you,

Nicolas
Last edit: 08 Aug 2019 19:54 by Nico2017.

Please Log in or Create an account to join the conversation.

More
08 Aug 2019 20:27 - 08 Aug 2019 20:28 #141702 by PCW
There is always going to be some jitter from 2 sources

1. Time resolution when measuring count-->count times
This is a bigger factor with the software encoder since the
time resolution is limited by the base thread rate

2. Quadrature fidelity
For cases with only 1 count or less per sample, the actual width of
the quadrature pulses and their deviation from perfect 90 degree phasing
cause a direct velocity estimation error.
(this error gets divided by the number of counts per sample so is most apparent at lower speeds)

There are partial workarounds for this error but neither the software
encoder component nor any of the LinuxCNC hardware encoders
that I know of implement these schemes
Last edit: 08 Aug 2019 20:28 by PCW.

Please Log in or Create an account to join the conversation.

More
13 Aug 2019 17:39 #142055 by andypugh
Note also that the sim-encoder will have quadrature error from the same source as the encoder counting error, the granular nature of the base thread.

I can't think of any practical use for sim-encoder with real hardware.
The following user(s) said Thank You: Nico2017

Please Log in or Create an account to join the conversation.

More
13 Aug 2019 19:17 #142076 by Nico2017
Hi Andy,

I was just putting a sim-encoder to simulate my future encoder which is going to be connected, just connecting the phase pins between my sim-encoder and encoder components. Although do you think that the fact I am using a sim-encoder is increasing the jitter on my encoder velocity output signal too where the real system, with an encoder system itself will just suffer from the jitter of the encoder?

Thank you,

Nicolas

Please Log in or Create an account to join the conversation.

More
13 Aug 2019 21:58 #142083 by andypugh

Nico2017 wrote: Although do you think that the fact I am using a sim-encoder is increasing the jitter on my encoder velocity output signal too


Yes, I think that is likely.

If you swap the order of the two addf lines in the HAL you will probably see the noise get better, or worse.
The following user(s) said Thank You: Nico2017

Please Log in or Create an account to join the conversation.

More
14 Aug 2019 04:33 #142106 by Nico2017
Hi I tried swapping the order, without any noticeable results.

I will get my encoder quite soon so would be able if the real one plugged on the shaft actually gets a better result.

I am also trying to create a PID position loop based on the encoder information, I am just then wondering if it is a good idea to use the velocity of the encoder as a feedback-deriv of my PID component if I still got jitter onto it.

Thank you,

Nicolas

Please Log in or Create an account to join the conversation.

More
14 Aug 2019 04:54 - 14 Aug 2019 04:56 #142107 by PCW
Any velocity estimation will have jitter but consider how bad jitter is with just dp/dt

( Without any low pass filtering, any dp/dt velocity calculation when the count rate
is lower than 1 count per sample will give a series of 1/dt and 0 velocities! )
Last edit: 14 Aug 2019 04:56 by PCW.
The following user(s) said Thank You: Nico2017

Please Log in or Create an account to join the conversation.

Time to create page: 0.090 seconds
Powered by Kunena Forum