-
Notifications
You must be signed in to change notification settings - Fork 212
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
Make transformation framework pluggable #346
Make transformation framework pluggable #346
Conversation
6f6b2c2
to
a312050
Compare
Sorry looks like I caused a merge conflict by merging other stuff. I got part of the way through the review, and I'll try to continue it soon. |
No worries, we'll rebase. |
a312050
to
f7447e2
Compare
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.
Ok, I finally got through the review, sorry it took so long, but this was a large change, I had to break it into three sessions.
So the code review looks pretty good to me, I have some style things I want to address, but I'll do that in a pull request probably tomorrow.
Unfortunately, my testing of the new UI elements revealed some strange behavior. I made a video of me clicking around on it (the most interesting issue is towards the end):
https://media.giphy.com/media/1hMhlfukXkMhsX2Thq/giphy.mp4
The issues I see in the video:
- the save and reset buttons do not disable after saving sometimes
- what does the reset button do?
- after using the reset button I can sometimes check both boxes...
I also got a segmentation fault once but I wasn't running in gdb and I could not reproduce it, but I was doing stuff similar to what I was doing in the video, just clicking around.
I also got this log message when clicking around:
[ERROR] []: Failed to remove time jump callback
Which seems to be from the destruction of an rclcpp::Clock
class and it's time jump callback, here:
Which was added in this pull request:
/cc @sloretz in case you have any idea how our use of clock in this pr might cause that behavior.
I know you guys have been waiting to get this merged for a long time (sorry, my fault) but I think the UI issues need to be investigated before we merge this.
To make them available at runtime, use the cmake macro `register_rviz_ogre_media_exports` defined in `rviz_rendering` | ||
For instance, if you want to register a folder `test_folder/scripts` which resides in your project's source folder, write | ||
``` | ||
register_rviz_ogre_media_exports(DIRECTORIES "test_folder/scripts") | ||
``` | ||
*Note:* If you want to export folder hierarchies, each folder needs to be exported separately. Folders within exported folders are not automatically available. | ||
|
||
#### Writing a display which can only work with one transformation plugin | ||
|
||
Some of the default displays (e.g. TF display or LaserScan display) can only work with tf2 as transformation framework. |
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.
Why can the LaserScan display only work with 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.
The laser_geometry
package used internally needs a tf2_buffer
. Since it is not very easy to get around this (one would need to heavily rewrite some parts in laser_geometry
), we decided that it's probably better to leave it out for now.
docs/plugin_development.md
Outdated
The class `rviz_default_plugins::transformation::TransformerGuard` helps you to handle these possibilities. | ||
|
||
As explained in the relative section, every transformation plugin implements the base class `rviz_common::transformation::FrameTransformer`. | ||
The `TransformerGuard` class is templated on the type of this implementation and will make sure that the display by which is owned will be disabled if the transformer currently in use is of a different type. |
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.
"... by which it is owned ..."?
docs/plugin_development.md
Outdated
The `TransformerGuard` class is templated on the type of this implementation and will make sure that the display by which is owned will be disabled if the transformer currently in use is of a different type. | ||
|
||
When writing a display that is supposed to be working only with a specific transformation plugin, you can add a templated instance of `TransformerGuard` as a display member. | ||
The constructor of this class takes two argument: a raw pointer to the display that owns it, and the name of the transformer it is supposed to work with (needed to correctly set the error status). |
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.
Can it work with more than one kind? Or can you only have one TransformerGuard
per display?
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.
No. Onle one TransformerGuard
per display is supported.
Reason: The only reason for a display to require a special FrameTransformer
would be if the FrameTransformer
interface is not sufficient. I think there is likely only a single frame transformer plugin that fulfills this special requirement (at least that the display knows of).
If support for more allowed transformer plugins is really necessary it should be possible the extend TransformerGuard
to support multiple template parameters for the supported plugins but still have only a single guard member in a display.
virtual ~TransformationLibraryConnector() = default; | ||
}; | ||
|
||
using TransformationLibraryConnectorPtr = std::weak_ptr<TransformationLibraryConnector>; |
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.
Usually the analogy for Ptr
is a raw pointer or unique_ptr
(because it has almost no overhead compared to raw pointer), however weak_ptr
does have overhead. I'd recommend using WeakPtr
as the suffix here.
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.
Or just use std::weak_ptr<TransformationLibraryConnector>
everywhere.
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.
We will use the ::WeakPtr
convention.
{ | ||
|
||
/** @brief Base class for TransformerGuard, needed because Qt's moc and c++ | ||
* templates don't work nicely together. Not intended to be used directly. |
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.
Can you please elaborate on this point?
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.
Same reason as with rviz_common::RosTopicdisplay
and rviz_common::_RosTopicDisplay
: a QObject may not be a template class due to limitations imposed by the Qt moc.
} catch (const tf2::ExtrapolationException & exception) { | ||
throw rviz_common::transformation::FrameTransformerException(exception.what()); | ||
} catch (const tf2::InvalidArgumentException & exception) { | ||
throw rviz_common::transformation::FrameTransformerException(exception.what()); |
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.
So much information is lost here... Maybe you should prefix the error message with the original name of the error.
Thank you for the feedback! I investigated the UI issues:
There are two simple workarounds that I see, which would you prefer @wjwwood :
The latter would be a achieved by making |
You are right, these issues have been introduced after ros2/rclcpp#543. We managed to track the issue inside the rcl and opened an issue there: ros2/rcl#293. |
Looking into this. |
Thanks for the fast feedback.
The second seems reasonable to me. It looks like the Linux tests are taking a long time due to failing tests. My first instinct is to rebase this change, but I don't think much changed within rviz that might affect this pr. I'll probably do that to keep the ball rolling. |
…sformer in visual testing config
-Necessary after PR ros2#340
- use "::WeakPtr" convention - add missing visibility macro to TransformationManager - retain information about tf exceptions when re-throwing - fix documentation typo
- superfluous for small amount of checkboxes - Code-Style: reorder functions in transformer panel
I pushed the rebase to the branch |
3216dd5
to
356f60b
Compare
Ok that run looked good so I force pushed the rebase. I'm just checking on a few things and then I'll do CI on your branch (what this pr is actually testing). |
Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: William Woodall <william@osrfoundation.org>
I think the only thing blocking this right now is the resolution of what to do w.r.t. the save button's behavior. I'll be around tonight to follow up and make more CI jobs to hopefully merge it. |
- Clicking on the transformers view, sometimes the clicked event is only sent to the underlying property, not the tree view - This results in weird behaviour of the gui - With this fix, it can only (rarely) happen that the click does nothing
I pushed a style fixup, but it doesn't affect code, so the CI is valid. Consider it merged if the CI is green. I'll merge it in the morning. |
This change allows developers to provide their own transformation library to be used instead of tf2.
Two transformer plugins are bundled with RViz:
The tf2 plugin is used as default, which means users normally do not have to interact with the transformation plugins.
We also added a new transformation panel to change the transformation plugin at runtime.
This panel displays all transformation plugins available at startup, third party plugins are loaded using the pluginlib.
The documentation was extended accordingly to support developers creating their own transformation plugin.