Repository navigation
Robot Kalman Filters - #3906
Robot Kalman Filters#3906sunghyuneun wants to merge 64 commits into
Conversation
…into sunghyuneun/robot_filter
…into sunghyuneun/robot_filter
…into sunghyuneun/robot_filter
…into sunghyuneun/robot_filter
man fuck you
| # Robot always not excessively dribbling | ||
| always_validations = [ | ||
| [BallAlwaysStaysInRegion([tbots_cpp.Circle(ball_location, 0.05)])] | ||
| [BallAlwaysStaysInRegion([tbots_cpp.Circle(ball_location, 0.5)])] |
There was a problem hiding this comment.
this is pretty significant relaxation, is it necessary?
| // does not account for: deflections, uneven turf, and the tail of a kick. A kick | ||
| // itself is far larger than this, but it is also abrupt enough that the outlier gates | ||
| // catch it and reset the filter, so this does not need to cover one. | ||
| constexpr double ACCELERATION_NOISE_M_PER_S_SQUARED = 5.0; |
There was a problem hiding this comment.
how were these values derived? Will they differ depending on camera? In that case, is anonymizing it here in this namespace the best location to put this?
There was a problem hiding this comment.
Could these values be adjusted frequently? ie surface, camera, SSL vision quality? In that case, should we consider a dynamically adjustable set of datavalues
| * where it ended up. A ball moving at 5 m/s covers over 8 cm between frames at 60 Hz, | ||
| * so a test that only asked whether the ball was currently within its own radius of a | ||
| * surface would step straight over anything thin, and a goalpost is thin. | ||
| * |
There was a problem hiding this comment.
given this desc, maybe a more apt naming scheme is appropriate
| # Disable for kalman filter | ||
| #cc_test( | ||
| # name = "ball_filter_test", | ||
| # srcs = ["ball_filter_test.cpp"], | ||
| # deps = [ | ||
| # ":ball_filter", | ||
| # "//shared/test_util:tbots_gtest_main", | ||
| # "//software/world:field", | ||
| # ], | ||
| #) |
There was a problem hiding this comment.
should this test be updated + enabled?
There was a problem hiding this comment.
I started this PR by pulling the Ball Kalman Filter PR so there may be remnants remaining that I haven't removed yet.
|
|
||
| void BallFilter::addNewDetectionsToBuffer(std::vector<BallDetection> new_ball_detections, | ||
| const Rectangle& filter_area) | ||
| std::optional<Ball> BallFilter::estimateBallState( |
There was a problem hiding this comment.
how often is this called? is it a concern that we recalc a pseudo inverse on the fly every time?
…into sunghyuneun/robot_filter
sunghyuneun
left a comment
There was a problem hiding this comment.
andrew's comments moved to robot filter stuff where it's relevant.
| // catch it and reset the filter, so this does not need to cover one. | ||
| // TODO: this does NOT apply to a robot but like whatever man lol | ||
| constexpr double ACCELERATION_NOISE_M_PER_S_SQUARED = 4.0; | ||
| constexpr double ANG_ACCELERATION_NOISE_RAD_PER_S_SQUARED = 1.0; |
There was a problem hiding this comment.
Andrewyx comment -
how were these values derived? Will they differ depending on camera? In that case, is anonymizing it here in this namespace the best location to put this?
Could these values be adjusted frequently? ie surface, camera, SSL vision quality? In that case, should we consider a dynamically adjustable set of datavalues
|
|
||
| std::optional<Robot> RobotFilter::getFilteredData( | ||
| const std::vector<RobotDetection>& new_robot_data, const Timestamp& capture_timestamp, | ||
| std::optional<Robot> RobotFilter::estimateRobotState( |
There was a problem hiding this comment.
how often is this called? is it a concern that we recalc a pseudo inverse on the fly every time?
…neun/tb-software into sunghyuneun/robot_filter
|
if you have time can u merge master and resolve the conflicts |
Andrewyx
left a comment
There was a problem hiding this comment.
Some comments. Ran out of time, so handing off to @StarrryNight / @nycrat if possible?
| .vscode/ | ||
| .vscode/.* | ||
| !.vscode/extensions.json | ||
| *.code-workspace |
| #include "software/networking/unix/threaded_proto_unix_sender.hpp" | ||
| #include "software/simulation/er_force_simulator.h" | ||
|
|
||
| // CSV file that the filtered robot state is logged to, alongside the ground truth |
There was a problem hiding this comment.
nit: "Ground truth state" is not informative. Unnecessary jargon and verbosity from AI here I assume. Really confusing what this supposed to actually be, assuming filtered vs real values from sim?
| // Wraps an angle to [-pi, pi] so detected and actual orientations are directly | ||
| // comparable (e.g. -3.1 rad and 3.1 rad aren't reported as a ~6.2 rad error) | ||
| static double wrapAngle(double radians) | ||
| { | ||
| return std::atan2(std::sin(radians), std::cos(radians)); | ||
| } |
There was a problem hiding this comment.
is this not some standard utility we have elsewhere? Seems like a common use case, or why are we "wrapping" in the first place?
| Timestamp default_timestamp; | ||
| }; | ||
|
|
||
| // Robot expires when it hasn't received its own data for at least 200 milliseconds. |
There was a problem hiding this comment.
arbitrary. we should change depending on real robot data.
…into sunghyuneun/robot_filter
Description
note: i am lazy and i want auto-formatting fixes so i marked it as open but it's not in a final state but it's 95% there i think (excluding physical tests)
Makes changes to robot filter. Notable changes:
Notably a lot of the files changed are part of PR #3900, because I built upon a lot of the work there. Files that should actually be reviewed include:
robot_filter.cpp,robot_filter.h,robot_filter_test.cpp,robot_team_filter.cpp,robot_team_filter_test.cppTesting with real robots is incomplete, and some constants should be changed.
Testing Done
Unit tests modified
Resolved Issues
Resolves #3701, fixes #1717.
Length Justification and Key Files to Review
Ball Kalman Filter is +529 -503, therefore this PR is +413, -101.
Review Checklist
It is the reviewers responsibility to also make sure every item here has been covered
.hfile) should have a javadoc style comment at the start of them. For examples, see the functions defined inthunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.TODO(or similar) statements should either be completed or associated with a github issue