Humble port

[mcbed]

Ported the packages as-is to work in Humble. Based on PR #7.

[mcbed]

@marcbone, could you allow me to run the CI on this PR ?

[marcbone]

looking at the most recent changes. I guess the errors come from introducing the captures in the lambdas. Also the "not"s were also replaced in the strings. This should be reverted

[peterdavidfagan]

@marcbone @mcbed I think from Humble onwards ros2-control uses the https://github.com/PickNikRobotics/generate_parameter_library to generate parameters. Maybe this is part of the issue I am facing with this current set of code as the joint_effort_trajectory_controller follows a different design pattern. I am still reading through ROS2 control docs and the code but would it make sense to switch to the official joint_trajectory_controller from ROS distros starting at Humble onwards?

https://github.com/ros-controls/ros2_controllers/tree/humble/joint_trajectory_controller/src

[mcbed]

now all should build as CI failed because of format tests. @marcbone, can you run CI again ?

[marcbone]

@peterdavidfagan about the joint_trajectory_controller, the reason I copied it was that this PR was still open at that time. Also there was the issue that the controller would not keep its initial pose before you send him a goal. It would instead only send zero torques. I modified this to use the starting pose as goal pose when the controller is started. I am not sure whether this is now also in the upstream controller. You should check this before you start using it.

[destogl]

Also there was the issue that the controller would not keep its initial pose before you send him a goal. It would instead only send zero torques. I modified this to use the starting pose as goal pose when the controller is started.

This could still be an issue. Nevertheless, we are glad to fix this if we get a PR :)

[peterdavidfagan]

This could still be an issue. Nevertheless, we are glad to fix this if we get a PR :)

Happy to work on this, still reading the code and upramping but I would be happy to work towards submitting a PR with these changes.

[marcbone]

@peterdavidfagan If you want to work on this, this is the commit where I fixed it.

[peterdavidfagan]

@marcbone changes submitted in pr to the ros2_controllers repository. I've also add another pr for the current Humble port. Before running the controller on a real-robot do you have any guidance on avoiding damage to the motors etc.?

@destogl is there a recommended way to test the changes I make to controller software in ros2_controllers? I presume I should run tests defined here.

Note: I am also happy to open a separate pr that adds support for MoveItConfigsBuilder, I'll be developing this code anyway for our setup so happy to add this.

[marcbone]

@peterdavidfagan What I really like about the FCI is that you cannot damage the robot by sending out wrong commands (as long as you are not moving it into something like a chainsaw, or fullspeed into the ground). It will may make motions that look scary to you but the robot will reject any commands that would harm the motors. Just be quick with the user stop button if the robot tries to move itself into an object. What you also can do is to call "robot->setCollisionBehavior(...)" after this line and use very low values. This will make the robot stop faster if it collides with something (by detecting a collision earlier).

[peterdavidfagan]

Awesome thanks @marcbone this is really reassuring and what I was hoping to here.

(as long as you are not moving it into something like a chainsaw, or fullspeed into the ground)

I can confirm that there are no chainsaws in the vicinity of our robot, we do have a ground plane though :).

What you also can do is to call "robot->setCollisionBehavior(...)" after this line and use very low values. This will make the robot stop faster if it collides with something (by detecting a collision earlier).

Thanks for this tip and the support in helping answer these queries.

[peterdavidfagan]

Works with Humble now, thanks @marcbone @destogl @mcbed for the help with this.

IMG_1086.MOV

[craig-sony]

+1 Eagerly awaiting this merge. Thanks.

[BarisYazici]

+1 Eagerly awaiting this merge. Thanks.

We are working on it @craig-sony

[tingelst]

I have a working setup with a Panda on Humble. With the ported joint_effort_trajectory_controller the motion is smooth and everything works. With the upstream joint_trajectory_controller from ros2_controllers, however, I am getting a very jerky motion with the same PID gains. I have tested the humble branch, as well as the different PRs related to the jtc.

Have you seen this behavior on your setups?

[drewskoots]

Yes! I have also started to notice this problem while using Moveit! and thought my motion planning was the issue. AFAIK the default move it controller also uses the JTC to actually perform the motion.

[BarisYazici]

We have released the source code of the humble port! We kept the original commits from @mcbed and extended with unit testing. Thanks a lot for your contribution! 💯
Humble is now the default branch at franka_ros2 repo. Please take a look and test it with your own setup. If there is no issue, we could close this PR.

[christian-rauch]

Humble is now the default branch at franka_ros2 repo. Please take a look and test it with your own setup. If there is no issue, we could close this PR.

@BarisYazici Since this is incompatible with foxy, could you rename the develop branch to foxy to indicate that this is the old version for the previous LTS version?

[BarisYazici]

@BarisYazici Since this is incompatible with foxy, could you rename the develop branch to foxy to indicate that this is the old version for the previous LTS version?

We will push a new branch named foxy to avoid having upstream deleted for the users on develop branch.