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

Make kdl_parser_py build successfully under ros2 #48

Closed
wants to merge 9 commits into from

Conversation

fjulian
Copy link

@fjulian fjulian commented Jan 8, 2021

Changed the build files (mainly setup.py) s.t. this can be built using colcon in a ROS 2 workspace. Tested building and using this with ROS 2 Foxy on Ubuntu 20.04.

The only thing that is missing is also building and running the tests under ROS 2, since I don't know the standard way of running python tests in ROS 2. If you think this is necessary before merging, I can look into it.

Copy link
Collaborator

@clalancette clalancette left a comment

Choose a reason for hiding this comment

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

First, thanks for the initial work to port this to ROS 2.

There's one nit inline, and one major problem that we have to solve before this gets in.

While we are doing this, we should also enable the tests. https://github.com/ros-teleop/teleop_tools/tree/foxy-devel/joy_teleop has some good examples on how to rewrite the tests to be ROS 2 compliant. Make sure to also remember to enable the flake8, copyright, pep257, and xmllint tests; that will ensure that the package meets our coding guidelines.

kdl_parser_py/setup.py Outdated Show resolved Hide resolved
kdl_parser_py/package.xml Outdated Show resolved Hide resolved
<exec_depend version_gte="1.3.0">orocos_kdl</exec_depend>
<exec_depend>urdf</exec_depend>
<exec_depend>urdfdom_py</exec_depend>
<exec_depend>python_orocos_kdl</exec_depend>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Unfortunately, this is going to be a problem. We don't have python_orocos_kdl ported to ROS 2 at this time. See ros2/geometry2#360 (comment) for some of my thoughts on how we can get this ported and enabled for ROS 2.

Copy link
Author

Choose a reason for hiding this comment

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

Sounds like you have these two options already mapped out well. Is there already a preference regarding which one to go for? Has someone already picked this up or is there a timeline? Can I help something with this? Although I probably couldn't help with the second option since I have no Windows machine available and no experience with ros on Windows...

Copy link
Collaborator

Choose a reason for hiding this comment

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

Nobody has picked it up as far as I know. So help there would be welcome (it would unblock both this and that geometry2 PR).

As far as which way to go, I would probably choose option 1. It's the most straightforward to do. Keep in mind that we will have to get it working for Windows (and macOS) there as well, but that should be easier than making a choco package.

Copy link
Author

Choose a reason for hiding this comment

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

Okay, I think I can find some time to look into option 1.

@fjulian
Copy link
Author

fjulian commented Jan 11, 2021

Regarding the tests, I updated the existing one s.t. it can be run with colcon, and added flake8, copyright, pep257 and xmllint tests. Not all tests pass yet and I have two questions about this:

  • Copyright notes are missing in the package files. Which ones would you like to have added? You're probably more familiar with the package history and who holds the copyright.
  • The flake8 test is failing. However, on my machine, the flake8 tests from the joy_teleop package you mentioned as an example are also failing. Maybe they're using a custom flake8 configuration, ignoring certain rules? If they do, it's not included in the repo. Do you know where this could be?

Thanks for reviewing this by the way!

@clalancette
Copy link
Collaborator

* Copyright notes are missing in the package files. Which ones would you like to have added? You're probably more familiar with the package history and who holds the copyright.

Good question. This should be the BSD license, for 3 reasons:

  1. This is a port of a ROS 1 package, and hence should retain whatever license it had.
  2. The package.xml in the ROS 1 branch says "BSD".
  3. The files in https://github.com/ros/kdl_parser/tree/noetic-devel/kdl_parser are marked as BSD.
* The flake8 test is failing. However, on my machine, the flake8 tests from the `joy_teleop` package you mentioned as an example are also failing. Maybe they're using a custom flake8 configuration, ignoring certain rules? If they do, it's not included in the repo. Do you know where this could be?

We don't typically use a custom flake8 configuration as far as I know. However, flake8 is somewhat annoying in that it will just automatically use whatever plugins you have installed. If you happen to have ones installed that we don't have, that could cause the warnings. Can you give me a better idea of what warnings you are getting?

@fjulian
Copy link
Author

fjulian commented Jan 12, 2021

Thanks for the hints. Copyright notes are added now and flake8 tests are passing after I removed a couple of plugins.

Also, I made a draft of re-enabling PyKDL, see ros2/orocos_kinematics_dynamics#19. Would be great to hear your opinion on this.

:param param: Parameter name, ``str``
"""

return treeFromUrdfModel(urdf.URDF.from_parameter_server())
Copy link
Contributor

Choose a reason for hiding this comment

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

As the from_parameter_server method was removed in urdf_parser_py 1.* (the version used in ROS2) probably we may need to remove this method as well.

@clalancette
Copy link
Collaborator

Thanks for the pull request. We've done some further work here in #55, so I'm actually going to close this one out in favor of that. We'll continue the discussion over there.

@clalancette clalancette closed this Apr 7, 2022
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.

3 participants