RSI low pass filter

    Hello,

    I am using RSI for relative path correction. My KRC5 receives the correction data from a triangulation distance sensor via the RSI Ethernet object.

    Could anyone explain to me how the low pass filter in RSI works? I am using IPO Mode, which means that I send the correction data to the robot every 12ms. That would result in a frequency of data of 1000ms/12ms=83,33Hz.

    Does that mean that the low pass filter on the robot can only filter out frequencies that are below the 83hz? Or is there some other magic going on? :grinning_squinting_face:

    I am new to RSI or rather new to robot programming in general and can’t wrap my head around the signal processing parts yet.

    Appreciate your help!

    Greetings!

  • 95devils July 22, 2023 at 12:21 PM

    Approved the thread.
    • Best Answer

    Not exactly. You are correct that any input that changes with a frequency higher than about 41Hz (Nyquist limit) is going to be very hard to capture correctly. But that's not what the LP filter is for.

    The LPF is most often used to remove noise from the signal before passing it into the PID and/or CORR objects. Almost every sensor signal is going to have some degree of high-frequency noise. If that signal was input to PID or CORR objects "raw", it could result in the robot "jittering" badly in an attempt to follow that noise. Let's say you were using RSI to press a drill or a grinder onto a surface with a constant force. The vibrations of the tool are going to generate a lot of high-frequency noise that really isn't relevant to the application -- you want the robot to chase the "running average" value of the force.

    That's basically how the RSI LPS works -- it keeps a running average of the last several samples (taken every 12ms (or 4ms in IPO-Fast mode)) of the input. and outputs the average of those samples. The more samples, the lower the cutoff frequency of the filter. Really, the LPF acts like a damper, smoothing out sudden changes in an input.

    As an aside, the startup of an RSI container can have a similar effect. For the first "cycle" of an RSI program (timestamp 0), all inputs are treated as 0. It's only on the next cycle that the inputs actually start being read. This also includes "fixed" inputs, like gain settings or variables set from the KRL program. What this means is that an RSI PID object might well see the setpoint input as making a sudden instant change from 0 to... whatever you want it to be. I found a LPF very useful here, as it took my "steady state" input and "ramped" it from 0 to that value over the first few hundred milliseconds of run time. This saved me from some serious "jerks" when the RSI was started.

    Likewise, if you use gain scheduling or setpoint shifting, putting a LPF inline with those inputs is a good idea.

Advertising from our partners