Fix ball filter linear regression relative error bug

[nycrat]

Description

Fixes bug where ball velocity is inaccurately being calculated/estimated. The bug is caused by the following logic:

• estimateBallStateFromBuffer calls calculateLineOfBestFit to get the trajectory of the ball
• estimateBallVelocity is optionally passed this trajectory, setting the current + previous positions (used to calculate velocity) based on the trajectory
• However, the calculateLineOfBest function does two linear regressions, one with x vs y and one with y vs x (to account for vertical lines) and selects the one with least error
• In the calculateLinearRegression function, the error is calculated as relative error, which causes an issue when the x or y coordinate is close to zero, since it divides by it

The simple fix is just to use absolute error, since relative error for linear regression in this context of coordinates makes no sense, since we expect similar error for the estimated trajectory of the ball no matter where it is on the field.

Testing Done

Ran tests for ball_filter and passes. Also ran the original test that caused this bug and it is fixed (proper velocity being reported)

Resolved Issues

fixes #3527

Review Checklist

It is the reviewers responsibility to also make sure every item here has been covered

• Function & Class comments: All function definitions (usually in the .h file) should have a javadoc style comment at the start of them. For examples, see the functions defined in thunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.
• Remove all commented out code
• Remove extra print statements: for example, those just used for testing
• Resolve all TODO's: All TODO (or similar) statements should either be completed or associated with a github issue

[GrayHoang]

Nice catch!

[Andrewyx]

This makes sense to me, but can you update ball_filter.h to include the fact it returns the value of the error itself now? Additionally, if possible, it would be helpful to note if that value is in terms of the MSE just so that future reference to this function is clearer as to how the regression error is being generated. Otherwise, nice work!

[StarrryNight]

Nice!

[nycrat]

Note: I think that this change actually causes the pass_defender_tactic test to fail for some reason. I'll look into it and fix it

[nycrat]

The issue with the failing pass defender tactic test was that the ball for this specific test goes out of bounds and bounces off the wall. With the original ball filter code, the velocity of the ball is not calculated properly right after a bounce (probably since the original code divided error by x position of ball which is 0), so it doesn't trigger the ballKicked function used in pass defender's passStarted guard. However, after the changes in this PR, the ball filter code notices the change in direction almost immediately, so it does register as a kick, meaning the robot tries to intercept the ball and fail the test.

I just added an if statement to check if the ball is in the playing area

2026-01-19_215844.mp4

[StarrryNight]

good work