Motor current noise filtering


Our team has implemented the admittance controller on the stretch using the force feedback from the motor. However, the force reading is very noisy, so we decided to use a lowpass/bandpass filter to filter out the noise. The lowpass filter did an excellent job, but we found an interesting phenomenon. For example, the lift started at 0.3m and got a reading of “3”. When we commanded the lift to move to 0.5m and then moved back to 0.3m, the reading would stable at “5” instead of “3.”. Thus we would like to try the Kalman filter, but we couldn’t find the parameter such as the supply voltage, inductance, or viscous friction constant from the Do you know where we can find that info, or you have a better filter suggestion?


Interesting issue, thank you for sharing. I’m assuming you’re primarily interested in admittance control for the arm extension and the lift. Both of these can have non-ideal / non-linear friction due to their unique design of their transmissions ( though the lift is likely much closer to ideal).

We haven’t yet tried to model these effects. The ‘force’ reading is actually simply the motor current, so any reading is subject to the non-ideal effects of the transmission. Modulo the particulars of your filter, the issue you describe sounds like physical hysteresis of the transmission friction.

We will explore a bit more in detail tomorrow in order to provide better guidance. We’ll also be happy to post motor parameters, etc in case they are helpful.

Hi Dr.Edsinger, thanks for replying! Ideally, when the arm or lift is stable (no-load attached), its force reading should be “0,” right? Since the function is using “I - feed_forwad_I.”

We would also be happy to see those parameters so we can try out the Kalman filter.


No problem! First, a few items that may / may not self evident:

The uC reports an ‘effort’ which is then scaled in the Stepper class of Stretch Body to current (A).

There is a low pass filter of the reported effort signal that runs on the uC. You can find its values under your stretch_re1_factory_params.yaml. As configured it has a roll-off of 2hz

    effort_LPF: 2.0

You can overwrite the default value by including it in your stretch_re1_user_params.yaml, for example:

    effort_LPF: 10.0

The Lift joint is unique in that it needs to support itself against gravity. Thus it has a non-zero feedforward current (A)

 i_feedforward: 0.54

You could extend the Lift.move_to( ) to also allow setting of the i_feedforward to the uC on each control cycle. You’ll see that passes the term down on each push_command()

The tool can be useful to experiment with the Lift. On my robot, when I jog the lift up and then down, and then allow the reported force to settle, I see roughly 10N of hysteresis. (Note: These reported forces are only only rough approximations of Newtons).

You are correct in noting that for the reported force, the feedforward current is first subtracted off - so with an ideal transmission it would be zero when the arm is not in motion. See


, in

The non-ideal reported forces of the Lift and the arm will vary based on the history of the motion (eg, hysteresis on up vs down). The will also vary somewhat based on the position of the arm. As the arm extends the friction of the telescoping mechanism will increase. As the arm and lift retract, the internal cable winding mechanisms will apply increasing and possibly discontinuous forces that the motor must fight against. You can get a sense of these forces by backdriving the two joints with the Runstop enabled.

Below are the motor parameters of the motors.

Base wheels and Arm:


Good luck, let us know if you need anything else. We’d love to see the admittance control in action once it is working.