Skip to content

[BUG] LowPassFilter::operator() returns nan #446

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
manuelbaum opened this issue Jan 13, 2025 · 2 comments
Open

[BUG] LowPassFilter::operator() returns nan #446

manuelbaum opened this issue Jan 13, 2025 · 2 comments
Assignees

Comments

@manuelbaum
Copy link

manuelbaum commented Jan 13, 2025

Describe the bug
LowPassFilter::operator() returns nan when called with zero dt and zero Tf.

I have a multi-threaded setup running where I asynchronously call FOCMotor::shaftAngle() from different threads. Occasionally my setup breaks down because the LPF returns nan. That happens because the LPF is initialized with zero Tf in the FOCMotor class and occasionally dt is also zero which then breaks the formula in LowPassFilter::operator():

float alpha = Tf/(Tf + dt);

I'm actually surprised that nobody else had this problem yet, so I'm wondering if I am doing sth wrong.

hardware setup

  • Motor: GB4106
  • Driver: DRV8313
  • MCU: ESP32
  • Sensor: AS5048
  • No current sensing

IDE

  • Platformio

Suggested Solution
Catch the zero case by turning

if (dt < 0.0f ) dt = 1e-3f;

into

if (dt <= 0.0f ) dt = 1e-3f;

But I think that 1e-3f is actually a little too large and would suggest to go with 1e-4f or 1e-5f

@runger1101001
Copy link
Member

Thank you for reporting it, and sorry to take a long time to get back to you.

I guess the value assigned to dt doesn't matter in this case, because alpha will be 0 when Tf is set to 0, regardless of the value of dt.

I have to think about this solution a bit, and ask some of the other developers, but I'll try to have a fix for this in the next release.

As an aside, I don't think you should be calling FOCMotor.shaftAngle() from multiple threads.
One of your threads should be calling motor.move() in a fairly tight loop. motor.move() calls the shaftAngle() function for you once per call to motor.move() and set the value obtained to the field motor.shaft_angle. (See BLDCMotor.cpp line 409)

So your other threads should obtain the value from the field motor.shaft_angle, rather than calling the function. In this way I think you'll avoid the 0 dt case and won't have this error.

@runger1101001 runger1101001 self-assigned this Feb 18, 2025
@manuelbaum
Copy link
Author

thank you @runger1101001 for your answer!

As an aside, I don't think you should be calling FOCMotor.shaftAngle() from multiple threads.
One of your threads should be calling motor.move() in a fairly tight loop. motor.move() calls the shaftAngle() function for you once per call to motor.move() and set the value obtained to the field motor.shaft_angle. (See [BLDCMotor.cpp line 409]>
(https://github.com/runger1101001/Arduino-FOC/blob/1f0be50f81f1b6151d5d629a2386a9a5a02ebd5f/src/BLDCMotor.cpp#L409))

So your other threads should obtain the value from the field motor.shaft_angle, rather than calling the function. In this way I think you'll avoid the 0 dt case and won't have this error.

Makes sense and I now understand this after I looked into the code. I'm certainly going to do it this way, thanks for the hint! However I also think this is not really the behavior one would expect from a user perspective. In a sense I would expect that function to work as a getter that I can arbitrarily call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants