-
Notifications
You must be signed in to change notification settings - Fork 199
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
Remove many extra conversions from Matrix3x3 to Quaternion #741
base: rolling
Are you sure you want to change the base?
Conversation
tf2/include/tf2/buffer_core.h
Outdated
@@ -382,12 +382,15 @@ class BufferCore : public BufferCoreInterface | |||
std::string allFramesAsStringNoLock() const; | |||
|
|||
bool setTransformImpl( | |||
const tf2::Transform & transform_in, const std::string frame_id, | |||
const std::string child_frame_id, const TimePoint stamp, | |||
const tf2::Vector3 & origin_in, const tf2::Quaternion & rotation_in, const std::string & frame_id, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: I changed the string values into references - this really should be a std::string_view
- it shouldn't break any code, and ROS is c++17 now - but it's somewhat a moot point as SSO will kick in for most char*
conversions.
@kscottz - tagging as requested |
Note: I've broken all tests, I'll fix it - the base idea is sound, however |
Never mind - appears to just be tests using hardcoded quaternion values, rather than actually checking equality - I'm happy to fix this either by manually fixing the test quaternions, or by doing some nicer equality check. This does mean that downstream users will sometimes get out different (but equiv) rotations from the library than they got before. |
Pushed what should hopefully fix the failing tests. |
Co-authored-by: jmachowinski <[email protected]> Signed-off-by: kyle-basis <[email protected]>
Hit a failed test in CI, I don't think this is my fault - ci flake?
Locally:
|
Sorry about the delay, had a power outage this morning. I'll take a look but I am not super familiar with the internals of TF / Geometry. Thanks for sticking with this and trying to get it over the line. We really appreciate the help and could always use a few more contributors. ❤️
I figured you might hit a few flakey tests as anything that relies on float / double ends up being a bit brittle. I can't speak to any of these tests being historically flakey. I think setting the epsilons to five or six sig figs should be sufficient.
Absolutely. We're starting to have conversations about bringing in someone to address API doc deficiencies but that's still far off. I would need more familiarity to do it myself.
This one's on you and what you're up for. I would have to look at the individual tests to make a call. Please do keep in mind that more you change on the lower level code the more likely it is that it may break something up stream. Smaller deltas are always better and get finished faster. You can always circle back
I'll need to look at these a bit more but probably warrants an issue with a |
For what it is worth, we have no reports of flakey tests from our nightly CI in this package that I can remember, and nothing is reported in https://github.com/ros2/geometry2/issues . So while it is always possible that there is a flakey test here, we do not currently know about any. |
EXPECT_NEAR(q_simple.quaternion.z, -1 * M_SQRT1_2, EPS); | ||
EXPECT_NEAR(q_simple.quaternion.w, 0, EPS); | ||
{ | ||
const geometry_msgs::msg::QuaternionStamped q_simple = tf_buffer->transform( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might help the reviewers, and readability, if you articulate what's going on in this function call. I've been looking at this for ten minutes and it still isn't quite clear what's going on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added an intermediate variable - I think the diff moved your comment though, which line specifically is confusing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh, that doesn't really tell me what the test does, it just tells me what the result should be. What would really help readers is something like, // Frame a and frame b differ by [x,y,z] and [p,q,r] at time t, check the resulting quat is <foo>
That's why I dislike this big ball of wax test pattern, when you write one function per test you can name the tests something sane like, "check_basic_frame_transform" and it all makes sense. The original author really should have at least left us a few bread crumb comments. 😢
Anyway, not your fault, thanks for putting up with this stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're good to go once the uncrustify suggestions are merged.
@kyle-basis I was busy last week but I wanted to check in on your progress here. I added a couple of quick suggests to deal with uncrustify. @kyle-basis I want to give you a shout out on the ROS channels. What would be really awesome to include is an estimate of much performance has improved with these changes. Would it be possible to time the test performance before and after these changes to see how things have improved? |
Co-authored-by: Katherine Scott <[email protected]> Signed-off-by: kyle-basis <[email protected]>
Co-authored-by: Katherine Scott <[email protected]> Signed-off-by: kyle-basis <[email protected]>
Co-authored-by: jmachowinski <[email protected]> Signed-off-by: kyle-basis <[email protected]>
Sorry, I've been busy with work on Basis and holiday stuff! Merged the suggestions. I can try and get performance numbers for before and after. It's tricky as I don't actually have a full ROS environment to test some of this stuff in. |
} | ||
} | ||
|
||
namespace tf2 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
namespace tf2 { | |
namespace tf2 | |
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦🏻
@kyle-basis |
Both of these are legacy from the LInearMath library that we have forked from Bullet to use internally: https://github.com/bulletphysics/bullet3/tree/master/src/LinearMath We chose to internalize this library with renaming process to break the dependency and it's main goal is to only be internally used. But we didn't restrict access and so people have used it despite our preference for it not to be used directly. We've tried to keep this to be a direct fork instead of evolving it and improving it. We don't want to get into the business of maintaining yet another Linear Math library. The recommendation is to use Eigen or any other one of your own choice instead, leveraging the templated interface to tf2. |
That's reasonable - still, the hard dependency on geometry_msgs is painful and unnecessary. |
I've used this before, it ends up reformatting a lot of files in |
Pulls: #741 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I merged the another PR and now we have conflicts. Sorry about that, do you mind to fix it ?
Let me see what I can do. |
Manually moving |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you mind to restore tf2/include/tf2/buffer_core.h
with https://github.com/ros2/geometry2/blob/rolling/tf2/include/tf2/buffer_core.h ?
Sorry about that - done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
Fixed. Will work on perf testing today or tomorrow. |
Will fix the ...should I make a PR to fix the spelling of that warning? Edit: these warnings don't appear to be my fault. |
When calling
setTransform()
, rotation data would flow asros_msgs::Quaternion
->tf2::Quaternion
->tf2::Matrix3x3
, then reconvert totf2::Quaternion
12 times to check validity of the rotation, then do one final conversion to actually store it inside the buffer.When calling
lookupTransform()
, we'd go fromtf2::Quaternion
->tf2::Matrix3x3
->tf2::Quaternion
(x4)->ros_msgs::Quaternion
.I've fixed this in two parts -
setTransformImpl
andlookupTransformImpl
to take a vector+quat, eliminating both the roundtrip throughtf2::Transfrom
and the possible footgun ofgetRotation
tf2::Transform
, only callgetRotation()
once, and reusing the result afterwardslookupTransform
norlookupVelocity
, those are far less mechanical changes - would appreciate if someone fixed these up in a followup PRSome notes:
getRotation()
is poorly named - would recommend deprecating and renaming tocalculateRotation
or similar. I shot myself in the foot implementingtf2_basis
and not realizing that origin is by reference and rotation is by value.tf2::Transform
should really be a vector+quat, but it would be an API change