Skip to content
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

Migrate RobotModelDisplay #210

Merged
merged 36 commits into from
Mar 8, 2018

Conversation

Martin-Idel-SI
Copy link
Contributor

@Martin-Idel-SI Martin-Idel-SI commented Feb 20, 2018

Closes #101

Note that we moved the robot to rviz_default_plugins. This means that it is no longer part of any public interface. Is this the way to go?

In that case, there is quite some functionality in robot which is part of its public interface but not used in the display. Shall we delete it?

@wjwwood
Copy link
Member

wjwwood commented Feb 22, 2018

Note that we moved the robot to rviz_default_plugins. This means that it is no longer part of any public interface. Is this the way to go?

It's possible that some of those files belong in the public part of rviz_common. We can move them again later if that's the case.

In that case, there is quite some functionality in robot which is part of its public interface but not used in the display. Shall we delete it?

If you can try to figure out what was using these functions (interactive markers? something else?) then we could decided if they should be moved to rviz_common or if they should be deleted. At the very least, I'd say it would be helpful to enumerate these functions here briefly.

@wjwwood
Copy link
Member

wjwwood commented Feb 22, 2018

LGTM, the only thing I found I was missing was a file browser button in the text box (usually as an ellipsis at the end of the dialog) which would let me browse to a file rather than type it in.

For a file, does it need to be a URL? Like file:// or can it just be a path. Either way it might be nice to have a resource_retriever/URL option (which could use file:// or package://<package_name>/<relative_path> instead of a file path or topic).

Copy link
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code review lgtm too, with one comment for a change or a TODO

@@ -35,6 +35,7 @@
<test_depend>ament_cmake_gmock</test_depend>
<test_depend>ament_cmake_lint_cmake</test_depend>
<test_depend>ament_cmake_uncrustify</test_depend>
<test_depend>dummy_robot_bringup</test_depend>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm hesitant about this, since I don't expect dummy_robot_bringup to exist forever. I'd rather have it self contained in the rviz repository, though I understand that makes it a lot harder.

I'll take it as-is, but please add a TODO to use something less volatile in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree - that's why we added our own urdf file for testing. This is a leftover and we'll remove it. Thanks for catching it!

@wjwwood
Copy link
Member

wjwwood commented Feb 22, 2018

I'd like to have an answer on the removing dead code question and the dependency on dummy_robot_bringup as well as CI before merging. But so far it looks great, thanks!

@Martin-Idel-SI
Copy link
Contributor Author

Martin-Idel-SI commented Feb 22, 2018

Regarding the robot, maybe we really want to explicitly have it in rviz_common? Now that I once again read through the code, it seems to be designed for subclassing. The reason I think so is the following comment in Robot::setLinkFactory(...):
https://github.com/ros-visualization/rviz/blob/fe0512e6ce3c7d4ae54d57ec11c8cdd87acca4d5/src/rviz/robot/robot.h#L179

The functionality is never used in RViz (I'll show below). If subclassing is not used outside RViz (probably that can't be answered), the following functions can be removed (links are always to the ROS master and not to our ROS 2 fork):

Suggestion: We'll leave it in rviz_default_plugins. In a second PR, we'll remove all dead code. That way, it can easily be reverted if somebody complains that he/she needs it.

@Martin-Idel-SI
Copy link
Contributor Author

Martin-Idel-SI commented Feb 22, 2018

I added a file picker to the file property. Right now, it'll only work with the normal filepath, no package:// or anything. I also took the liberty to delete the old code from the old rviz package.

I agree that it might be nice to be able to react to package:// or file:// type paths (both send via topic and by just typing), but maybe we'll just add a ticket for now? I'm not exactly sure how one could add resource_retriever + file picker or how the user can be helped there.

@Martin-Idel-SI
Copy link
Contributor Author

CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@Martin-Idel-SI
Copy link
Contributor Author

Next try...

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@Martin-Idel-SI
Copy link
Contributor Author

Martin-Idel-SI commented Feb 23, 2018

And now with all tests disabled as they can't run: Failures are unrelated

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@greimela-si greimela-si force-pushed the feature/migrate_robot_model_display branch 2 times, most recently from 218b9e5 to c8bc311 Compare March 6, 2018 12:42
@greimela-si
Copy link
Contributor

greimela-si commented Mar 6, 2018

Rebased after changes on ros2 branch.

New CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status (failures unrelated)
  • Windows Build Status (failures unrelated)

@wjwwood
Copy link
Member

wjwwood commented Mar 8, 2018

Suggestion: We'll leave it in rviz_default_plugins. In a second PR, we'll remove all dead code. That way, it can easily be reverted if somebody complains that he/she needs it.

Sounds good to me.

I agree that it might be nice to be able to react to package:// or file:// type paths (both send via topic and by just typing), but maybe we'll just add a ticket for now?

That's fine.

I'm not exactly sure how one could add resource_retriever + file picker or how the user can be helped there.

I wasn't thinking that the file picker would be used but result in a package:// or file:// like url, but if the user wanted to type that in manually, it should work. That should be as simple as passing it to resource_retriever and falling back to opening it as a file if it fails.

Copy link
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@wjwwood wjwwood merged commit 8718ef5 into ros2:ros2 Mar 8, 2018
@Martin-Idel-SI Martin-Idel-SI deleted the feature/migrate_robot_model_display branch March 9, 2018 09:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants