Hi, I have tried demos in lbr_demos_fri_ros2_cpp, the JointSineOverlay works smoothly but wrench and torque not. After launch there is no error/warning message from both ROS2 side and FRI side, and I can even see the command topic with values in rqt, but on our iiwa7, nothing happens. Need your help!

Thanks in advance!

I have noticed some strange issues with publishing commands on the real robot. I am running the admittance controller example (I have tested with both the current Kinpy implementation and optas implementation in #53 in order to verify the issue is not with optas - I see the same behaviour with both versions).

When I run the example and check the hz of /lbr_command, i see

ros2 topic hz /lbr_command 
average rate: 499.911
	min: 0.000s max: 0.003s std dev: 0.00083s window: 501
average rate: 500.416
	min: 0.000s max: 0.003s std dev: 0.00083s window: 1002
average rate: 499.860
	min: 0.000s max: 0.003s std dev: 0.00083s window: 1501

However, I have verified in the admittance controller node script: (i) 100. commanding rate is being passed as the parameter, and the timer callback is running at 100hz (just by taking the time stamps between each successive call to the callback method.

The example isn't that clean anyway and I wonder if this has something to do with that.

@mhubii do you have any thoughts?

Hi,

Is humble branch building and working properly in ubuntu 22.04 or is it still under active development and testing?

After updating my system via apt update; apt upgrade, Gazebo fails to load and the robot model is not published (see below).

The terminal output is as follows.

$ ros2 launch lbr_bringup lbr_bringup.launch.py model:=med7 sim:=false
[INFO] [launch]: All log files can be found below /home/chrismo/.ros/log/2022-11-23-11-25-27-384196-sie-063-8934
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [fri_ros2_control_node-1]: process started with pid [8938]
[INFO] [robot_state_publisher-2]: process started with pid [8940]
[INFO] [spawner.py-3]: process started with pid [8942]
[INFO] [spawner.py-4]: process started with pid [8944]
[INFO] [move_group-5]: process started with pid [8946]
[INFO] [rviz2-6]: process started with pid [8948]
[robot_state_publisher-2] Parsing robot urdf xml string.
[robot_state_publisher-2] Link lbr_link_0 had 1 children
[robot_state_publisher-2] Link lbr_link_1 had 1 children
[robot_state_publisher-2] Link lbr_link_2 had 1 children
[robot_state_publisher-2] Link lbr_link_3 had 1 children
[robot_state_publisher-2] Link lbr_link_4 had 1 children
[robot_state_publisher-2] Link lbr_link_5 had 1 children
[robot_state_publisher-2] Link lbr_link_6 had 1 children
[robot_state_publisher-2] Link lbr_link_7 had 1 children
[robot_state_publisher-2] Link lbr_link_ee had 0 children
[robot_state_publisher-2] [INFO] [1669202727.856092293] [robot_state_publisher]: got segment lbr_link_0
[robot_state_publisher-2] [INFO] [1669202727.856181646] [robot_state_publisher]: got segment lbr_link_1
[robot_state_publisher-2] [INFO] [1669202727.856193074] [robot_state_publisher]: got segment lbr_link_2
[robot_state_publisher-2] [INFO] [1669202727.856198636] [robot_state_publisher]: got segment lbr_link_3
[robot_state_publisher-2] [INFO] [1669202727.856203758] [robot_state_publisher]: got segment lbr_link_4
[robot_state_publisher-2] [INFO] [1669202727.856208634] [robot_state_publisher]: got segment lbr_link_5
[robot_state_publisher-2] [INFO] [1669202727.856213467] [robot_state_publisher]: got segment lbr_link_6
[robot_state_publisher-2] [INFO] [1669202727.856218401] [robot_state_publisher]: got segment lbr_link_7
[robot_state_publisher-2] [INFO] [1669202727.856223301] [robot_state_publisher]: got segment lbr_link_ee
[robot_state_publisher-2] [INFO] [1669202727.856228205] [robot_state_publisher]: got segment world
[move_group-5] [WARN] [1669202727.893521881] [move_group.move_group]: MoveGroup launched without ~default_planning_pipeline specifying the namespace for the default planning pipeline configuration
[move_group-5] [WARN] [1669202727.893575986] [move_group.move_group]: Falling back to using the the move_group node namespace (deprecated behavior).
[move_group-5] Parsing robot urdf xml string.
[move_group-5] [INFO] [1669202727.896132640] [moveit_rdf_loader.rdf_loader]: Loaded robot model in 0.000901863 seconds
[move_group-5] [INFO] [1669202727.896163263] [moveit_robot_model.robot_model]: Loading robot model 'med7'...
[move_group-5] [INFO] [1669202727.896174923] [moveit_robot_model.robot_model]: No root/virtual joint specified in SRDF. Assuming fixed joint
[move_group-5] Link lbr_link_0 had 1 children
[move_group-5] Link lbr_link_1 had 1 children
[move_group-5] Link lbr_link_2 had 1 children
[move_group-5] Link lbr_link_3 had 1 children
[move_group-5] Link lbr_link_4 had 1 children
[move_group-5] Link lbr_link_5 had 1 children
[move_group-5] Link lbr_link_6 had 1 children
[move_group-5] Link lbr_link_7 had 1 children
[move_group-5] Link lbr_link_ee had 0 children
[fri_ros2_control_node-1] [INFO] [1669202728.030027653] [controller_manager]: Loading controller 'position_trajectory_controller'
[spawner.py-4] [INFO] [1669202728.047236486] [spawner_position_trajectory_controller]: Loaded position_trajectory_controller
[fri_ros2_control_node-1] [INFO] [1669202728.047996932] [controller_manager]: Configuring controller 'position_trajectory_controller'
[fri_ros2_control_node-1] [INFO] [1669202728.048120234] [position_trajectory_controller]: Command interfaces are [position] and and state interfaces are [position].
[fri_ros2_control_node-1] [INFO] [1669202728.049041002] [position_trajectory_controller]: Controller state will be published at 50.00 Hz.
[fri_ros2_control_node-1] [INFO] [1669202728.049986720] [position_trajectory_controller]: Action status changes will be monitored at 20.00 Hz.
[fri_ros2_control_node-1] [INFO] [1669202728.053447614] [controller_manager]: Loading controller 'joint_state_broadcaster'
[spawner.py-3] [INFO] [1669202728.066228102] [spawner_joint_state_broadcaster]: Loaded joint_state_broadcaster
[move_group-5] [INFO] [1669202728.210257125] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Publishing maintained planning scene on 'monitored_planning_scene'
[move_group-5] [INFO] [1669202728.210422377] [moveit.ros_planning_interface.moveit_cpp]: Listening to 'joint_states' for joint states
[move_group-5] [INFO] [1669202728.210931595] [moveit_ros.current_state_monitor]: Listening to joint states on topic 'joint_states'
[move_group-5] [INFO] [1669202728.211717265] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to '/attached_collision_object' for attached collision objects
[move_group-5] [INFO] [1669202728.211736157] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Starting planning scene monitor
[move_group-5] [INFO] [1669202728.211910639] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to '/planning_scene'
[move_group-5] [INFO] [1669202728.211921962] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Starting world geometry update monitor for collision objects, attached objects, octomap updates.
[move_group-5] [INFO] [1669202728.212149595] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to 'collision_object'
[move_group-5] [INFO] [1669202728.212400382] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to 'planning_scene_world' for planning scene world geometry
[move_group-5] [WARN] [1669202728.212437399] [moveit.ros.occupancy_map_monitor]: Resolution not specified for Octomap. Assuming resolution = 0.1 instead
[move_group-5] [ERROR] [1669202728.212477943] [moveit.ros.occupancy_map_monitor]: No 3D sensor plugin(s) defined for octomap updates
[move_group-5] [INFO] [1669202728.363418048] [moveit.ros_planning_interface.moveit_cpp]: Loading planning pipeline 'move_group'
[move_group-5] [INFO] [1669202728.385832140] [moveit.ros_planning.planning_pipeline]: Using planning interface 'OMPL'
[move_group-5] [INFO] [1669202728.387712651] [moveit_ros.fix_workspace_bounds]: Param 'move_group.default_workspace_bounds' was not set. Using default value: 10.000000
[move_group-5] [INFO] [1669202728.387735627] [moveit_ros.fix_start_state_bounds]: Param 'move_group.start_state_max_bounds_error' was set to 0.050000
[move_group-5] [INFO] [1669202728.387742031] [moveit_ros.fix_start_state_bounds]: Param 'move_group.start_state_max_dt' was not set. Using default value: 0.500000
[move_group-5] [INFO] [1669202728.387752586] [moveit_ros.fix_start_state_collision]: Param 'move_group.start_state_max_dt' was not set. Using default value: 0.500000
[move_group-5] [INFO] [1669202728.387758345] [moveit_ros.fix_start_state_collision]: Param 'move_group.jiggle_fraction' was not set. Using default value: 0.020000
[move_group-5] [INFO] [1669202728.387769300] [moveit_ros.fix_start_state_collision]: Param 'move_group.max_sampling_attempts' was not set. Using default value: 100
[move_group-5] [INFO] [1669202728.387780434] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Add Time Parameterization'
[move_group-5] [INFO] [1669202728.387786056] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Fix Workspace Bounds'
[move_group-5] [INFO] [1669202728.387790027] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Fix Start State Bounds'
[move_group-5] [INFO] [1669202728.387793677] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Fix Start State In Collision'
[move_group-5] [INFO] [1669202728.387797237] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Fix Start State Path Constraints'
[move_group-5] [INFO] [1669202728.430101818] [moveit.plugins.moveit_simple_controller_manager]: Added FollowJointTrajectory controller for position_trajectory_controller
[move_group-5] [INFO] [1669202728.430270786] [moveit.plugins.moveit_simple_controller_manager]: Returned 1 controllers in list
[move_group-5] [INFO] [1669202728.430818615] [moveit_ros.trajectory_execution_manager]: Trajectory execution is managing controllers
[move_group-5] [INFO] [1669202728.430840417] [move_group.move_group]: MoveGroup debug mode is ON
[move_group-5] [INFO] [1669202728.445154244] [move_group.move_group]: 
[move_group-5] 
[move_group-5] ********************************************************
[move_group-5] * MoveGroup using: 
[move_group-5] *     - ApplyPlanningSceneService
[move_group-5] *     - ClearOctomapService
[move_group-5] *     - CartesianPathService
[move_group-5] *     - ExecuteTrajectoryAction
[move_group-5] *     - GetPlanningSceneService
[move_group-5] *     - KinematicsService
[move_group-5] *     - MoveAction
[move_group-5] *     - MotionPlanService
[move_group-5] *     - QueryPlannersService
[move_group-5] *     - StateValidationService
[move_group-5] ********************************************************
[move_group-5] 
[move_group-5] [INFO] [1669202728.445194629] [moveit_move_group_capabilities_base.move_group_context]: MoveGroup context using planning plugin ompl_interface/OMPLPlanner
[move_group-5] [INFO] [1669202728.445210215] [moveit_move_group_capabilities_base.move_group_context]: MoveGroup context initialization complete
[move_group-5] Loading 'move_group/ApplyPlanningSceneService'...
[move_group-5] Loading 'move_group/ClearOctomapService'...
[move_group-5] Loading 'move_group/MoveGroupCartesianPathService'...
[move_group-5] Loading 'move_group/MoveGroupExecuteTrajectoryAction'...
[move_group-5] Loading 'move_group/MoveGroupGetPlanningSceneService'...
[move_group-5] Loading 'move_group/MoveGroupKinematicsService'...
[move_group-5] Loading 'move_group/MoveGroupMoveAction'...
[move_group-5] Loading 'move_group/MoveGroupPlanService'...
[move_group-5] Loading 'move_group/MoveGroupQueryPlannersService'...
[move_group-5] Loading 'move_group/MoveGroupStateValidationService'...
[move_group-5] 
[move_group-5] You can start planning now!
[move_group-5] 
[rviz2-6] [INFO] [1669202728.600498425] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-6] [INFO] [1669202728.600616733] [rviz2]: OpenGl version: 4.6 (GLSL 4.6)
[rviz2-6] [INFO] [1669202728.640191407] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-6] Parsing robot urdf xml string.
[rviz2-6] Warning: Invalid frame ID "lbr_link_1" passed to canTransform argument source_frame - frame does not exist
[rviz2-6]          at line 133 in /tmp/binarydeb/ros-foxy-tf2-0.13.13/src/buffer_core.cpp
[rviz2-6] Warning: Invalid frame ID "lbr_link_2" passed to canTransform argument source_frame - frame does not exist
[rviz2-6]          at line 133 in /tmp/binarydeb/ros-foxy-tf2-0.13.13/src/buffer_core.cpp
[rviz2-6] Warning: Invalid frame ID "lbr_link_3" passed to canTransform argument source_frame - frame does not exist
[rviz2-6]          at line 133 in /tmp/binarydeb/ros-foxy-tf2-0.13.13/src/buffer_core.cpp
[rviz2-6] Warning: Invalid frame ID "lbr_link_4" passed to canTransform argument source_frame - frame does not exist
[rviz2-6]          at line 133 in /tmp/binarydeb/ros-foxy-tf2-0.13.13/src/buffer_core.cpp

This was not an issue prior to updating/upgrading and I have seen the same problem on @Royo666's system - perhaps a bug in one of the dependencies?

When we download the LBRServer.java in noetic branch and add it into src file inside our new project, we meet the error The project 'SunriseProject' contains Java compilation errors. Please fix the errors to allow project synchronization.

I am not sure if there is the problem because of the different edition of sunrise OS. We use Sunrise OS, workbench and FRI 1.10. Do them have different editions of JAVA? Could you help us with this problem?

When launching the bringup, the default controller is position_trajectory_controller, i.e.

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/c1aadf3854830c8e54966238c17ca0047ef23501/lbr_bringup/launch/lbr_bringup.launch.py#L62-L66

I suggest the default controller should be none, and it should be left as a user option.

Also, the documentation should specify somewhere that these controllers refer to those from ROS control. This would make it clearer how to interface with the robot (i.e. what messages to send or actions to use).

I found new version of SDK has introduced fri_vendor to auto download fri package when build. However, this leads to the PC must link to internet when build. But it's hard when PC link to the kuka.

So is there a method to check fri_vendor already download fri so cancel network connection.

Hi we have followed all the steps to conenct the robot controller to the windows PC to setup the LBR Server application in the controller. Now we are trying to establish a connection between the robot and the linux computer running ROS2 application. However, when we start the LBR server from the Kuka Smart Pad we are getting the following error which points to that the error is coming due to configuration issues. We have gone over the network configuration multiple times and they all seem correct. Are we meant to run a certain version of the sunrise software? We are currently running Sunrise Workbench - Med 1.15.

We do not have access to your school's sharepoint to look at any of the additional resources. We are able to successfully ping the robot controller from the linux computer.

Please look at this image of the error we get from the smart pad. It is pointing at this line

Any help here would be greatly appreciated.

The mass in the med7 xacro file on the melodic branch seems to me to be incorrect - 46kg for the first link is nearly double the weight of the robot itself! The other links have equally unbelievable masses.

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/81dfea30dc89903d27df454f431269a52c6610ea/lbr_description/urdf/med7.xacro#L36

On the main branch, things are much more sensible:

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/0d2cc6e2f6bcfbff860fa87ecb87a64520f55181/lbr_description/urdf/med7/med7_description.urdf.xacro#L29

Hi,

Thanks for the work! We are doing joint torque control via FRI with this repo and it works well most of time. However we find the FRI session gets disposed when we have some physical interaction with the robot (like doing some small handguiding motions). From the log it seems like the connection quality drops to "poor" and hence get disconnected (please see the screenshot below).

Any idea on what could be the cause?

Btw I think here should be "FRI command mode" instead of control
https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/0d2cc6e2f6bcfbff860fa87ecb87a64520f55181/server/fri_ros2/LBRServer.java#L94

Thanks for your help!

A warning problem occured after run

``ros2 launch lbr_bringup lbr_bringup.launch.py model:=med7 sim:=true # model:=[iiwa7/iiwa14/med7/med14]''

the result shows:
[rviz2-8] Warning: Invalid frame ID "lbr_link_6" passed to canTransform argument source_frame - frame does not exist
[rviz2-8] at line 133 in /tmp/binarydeb/ros-foxy-tf2-0.13.13/src/buffer_core.cpp

Besides, robotic model and links seems not been shown in Gazebo and Rviz

Currently, tests are only executed on push / merge. In the .github/workflow, tests should be executed on schedule (see https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule) to assure this repository is up to date with changes in ros. Additionally, build-status should be re-added to the readme.

Hi,

Thank you for your impressive work first.

When I try to run example to test simulation, error occurred. Some details is shown below.

I run source devel/setup.bash and roslaunch lbr_moveit moveit_planning_execution.launch model:=iiwa14 sim:=true in command and gazebo and rviz work. However, when I open a new terminal and run cd src/lbr_fri_ros_stack/examples/moveit_python_examples/src and rosrun moveit_python_examples src/moveit_motion_examples.py, the error occurs:

[ERROR] [1659491678.046215306]: Robot semantic description not found. Did you forget to define or remap '/robot_description_semantic'? [ INFO] [1659491678.047591526]: Loading robot model 'iiwa14'... [ INFO] [1659491678.047669979]: No root/virtual joint specified in SRDF. Assuming fixed joint [FATAL] [1659491678.156816603, 3945.746000000]: Group 'arm' was not found. Traceback (most recent call last): File "/home/killentest/lbr_fri_ros_ws/src/lbr_fri_ros_stack/examples/moveit_python_examples/src/moveit_motion_examples.py", line 18, in <module> group = moveit_commander.MoveGroupCommander(group_name) File "/opt/ros/noetic/lib/python3/dist-packages/moveit_commander/move_group.py", line 66, in __init__ self._g = _moveit_move_group_interface.MoveGroupInterface( RuntimeError: Group 'arm' was not found.

I try to run rosparam list | grep robot_description_semantic. It shows `lbr/robot_description_semantic'. And I check the iiwa14.srdf, the group name is "arm".

Could you help me deal with it? Thank you for your time!

Launch file still includes the lbr_state_broadcaster which was depracted https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/1ae86ac0d6a658b9379b0d4bcca739693b5c1172/lbr_bringup/launch/lbr_control.launch.py#L73

Add this package to the ROS index. Alternative would be robostack conda forge.

Documentation

• Documentation: https://docs.ros.org/en/humble/How-To-Guides/Releasing/Releasing-a-Package.html
  • Add source entry https://github.com/ros/rosdistro, fork: https://github.com/ros-ai/rosdistro
  • Start new release team https://docs.ros.org/en/humble/How-To-Guides/Releasing/Release-Team-Repository.html#start-a-new-release-team

Tasks

• Add significant amounts of testing
• Add fri_vendor, too: https://github.com/lbr-stack/fri_vendor, OR, assume users compile and install fri via https://github.com/lbr-stack/fri
• Might become viable via
  • #160 in dev-humble-fri-msgs branch
  • Would require matrix release a la lbr-fri-x-ros2-stack with x = 1.15 etc

I find problems when i install lbr_fri_ros2_stack:

The first problem I meet is that when i follow the steps . The command ''vcs'' is not defined but i cannot find an avaliable vcs-installing command for Ubuntu 20.04.

Most of installing methods shows

    ``Collecting vcs
      Using cached vcs-0.4.0.tar.gz (482 kB)
        ERROR: Command errored out with exit status 1:
         command: /usr/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-2_kpq018/vcs/setup.py'"'"'; __file__='"'"'/tmp/pip-install-2_kpq018/vcs/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-install-2_kpq018/vcs/pip-egg-info
             cwd: /tmp/pip-install-2_kpq018/vcs/
        Complete output (6 lines):
        Traceback (most recent call last):
          File "<string>", line 1, in <module>
          File "/tmp/pip-install-2_kpq018/vcs/setup.py", line 11
            except IOError, err:
                          ^
        SyntaxError: invalid syntax
        ----------------------------------------
    ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.``

      2.When i skip the vcs installation and repos installation, I git clone the fri lib according to the repos.yml. After colcon, the bash showed '' No such file or directory
13 | #include "hardware_interface/base_interface.hpp"''

I use this package(foxy) with moveit2, and I want to give robot dynamic desired pose. So I choose moveit_servo to achieve this goal.

However, when I set FRI mode as 5ms, position mode, position control and then use moveit_servo to publish command at the frequency of 1hz, the motion stuck every second then go. The higher frequency sounds more dangerous. But I think FRI should support realtime servo because the normal moveit plan and execute runs successfully, where the frequency of sending robot command is higher than 1hz.

Do you have any good suggestions?

Refer https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_ros2_control/package.xml

Add cross platform support

In lbr_ctrl.launch you can see:

    <!-- Spawn controllers - it uses an Effort Controller for each joint -->
    <group ns="$(arg robot_name)" unless="$(arg trajectory)">
        
        <include file="$(find lbr_control)/launch/lbr_control.launch">
            <arg name="hardware_interface" value="$(arg hardware_interface)" />
            <arg name="controllers" value="joint_state_controller
                 $(arg hardware_interface)_A1_controller
                 $(arg hardware_interface)_A2_controller
                 $(arg hardware_interface)_A3_controller
                 $(arg hardware_interface)_A4_controller
                 $(arg hardware_interface)_A5_controller
                 $(arg hardware_interface)_A6_controller
                 $(arg hardware_interface)_A7_controller"/>
            <arg name="robot_name" value="$(arg robot_name)" />
            <arg name="model" value="$(arg model)" />
        </include>
    </group>

I do not understand why this should be an Effort Controller as written in the comment.
If you look at the config file (lbr_ctrl.yaml) you can see defined position and velocity controllers.

Effort controller does simply mean that there is a PID control in position or velocity that then send torques commands to the low-level controllers? Why also PID are not defined in position control?

Cheers!

The fri, is currently cloned via vcs, see First Steps. The dependency is loosely defined in the repos.yml. This decision was made, since the fri also runs stand-alone.

However, to simplify use, it might be beneficial moving the fri into this repository.

To facilitate changing FRI versions, remove the java application from this repository and move it to https://github.com/KCL-BMEIS/fri/tree/ros2-fri-1.15 instead

Hi,

Is there any alternative for accessing the files? The sharepoint requires KCL credentials to log in.

Note for later when we come to re-vamping the launch sequence. Moveit (below) should be made optional.

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/d1e70a7a1160ea2d3f29203b6ab83e2919292c29/lbr_bringup/launch/lbr_bringup.launch.py#L79-L99

Hi, may I know if I can use this package in ubuntu 18.04? I have melodic installed but I am really new at ros2. Thanks!

It's useful to have access to URDF file generated from the xacro description (e.g. PyBullet doesn't support loading from xacro, only URDF), in ROS1 this is possible. I assume it should be possible in ROS2 - this would be a worthwhile feature to add to the lbr_description package.

the origin is still unused

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/a8ae3e7168445d1d82ab765c4485c868ae7eda9a/lbr_description/urdf/med7/med7.urdf.xacro#L13

associated origin in launch files

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/d0b6bfaa6a8d17539ff0d61eedbd85f426741b84/lbr_description/launch/view_robot.launch.py#L41

Hi, thank you for your valuable contribution to the community!
I'm wondering if this package supports controlling the robot's end-effector directly in the Cartesian space without using moveit?
Thank you very much!

Controller_spawner is failing because some dependencies are not satisfied when running

"rosdep install --rosdistro melodic --ignore-src --from-paths src"

Fixed by installing ros-melodic-moveit and ros-melodic-joint-trajectory-controller

It might be worth investigating which are the missing packages in the package dependencies rather then installing these two packages which include many others that might not be useful.

Hello, I am having troubles connecting to my kuka controller, my HMI shows the following dialouge:

In addition, I get the warning that I have to use Real Time Kernel - is this the reason? I tried it with RT Kernel but than the FIFO scheduling didn't work out.

Do I have to set the IP of the kuka controller anywhere in the code? Or how does the connection work?

the rt priority execution set here

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/0d2cc6e2f6bcfbff860fa87ecb87a64520f55181/lbr_bringup/launch/lbr_control.launch.py#L69

is an issue if users do not have appropriate rt priorities set. This parameter should thus be adjustable. Also, this execution prefix might not work under windows.

The current fix would be to adjust the user's rt priority in /etc/security/limits.conf by adding the line user - rtprio 99, where user has to be set to the user. After adjusting, logging out and in is required

Link is broken

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/59f714ecde55dcfa5d5a71707f6ce1c5825cf301/lbr_fri_ros2/doc/lbr_fri_ros2.rst?plain=1#L74

Also refer to readthedocs hosted pages

https://lbr-fri-ros2-stack-doc.readthedocs.io/en/latest/lbr_fri_ros2_stack/lbr_fri_ros2/doc/lbr_fri_ros2.html#implementation-details

materials shouldn't be included in .urdf.xacro but in the description

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/93bf8dc9422450e54c8dc450ba8370836c719c64/lbr_description/urdf/med7/med7.urdf.xacro#L7

• Fix on contact bug
• Improved description files (improve coloring)
• Investigate novel Gazebo releases

Investigate support for multiple robots.

• IP and Port: The robot's IP address and port, that this interface tries to connect to are specified in fri_hardware_interface.hpp. These are set as parameters in the lbr.ros2_control.xacro. The hardware interface is loaded as plugin and has thus access to these parameters. Check access of these parameters through launch files.

• Namespaces: Check the namespaces

Thanks for sharing the amazing project.

I am wonder can we set the KONI FRI address similar to x66. The default value for those two are 192.170.10.2 and 172.31.1.147. The jave file, this line builds connection on 172.31.1.148. Do we need some changes to the KONI setting?

Replace FRI submodule by vcs tool

rviz config might have to be replaced by argument '-d'

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/a8ae3e7168445d1d82ab765c4485c868ae7eda9a/lbr_description/launch/view_robot.launch.py#L81

The velocity limit defined in the URDF seems too high.

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/d73115b9f088395b62cfc0073cf1d0ca6aa21c1e/lbr_description/urdf/med7/med7_description.urdf.xacro#L10

Perhaps this is in degrees/sec? The unit for the velocity limit should be in rad/sec. For ease in setting joint limit constraints in optas, we should tune the velocity limit.

Description

When I start the lbr_bringup simulation with the command ros2 launch lbr_bringup lbr_bringup.launch.py model:=iiwa7 sim:=true, the links and joints of the robot are missing after Link 0.
Steps to Reproduce

Launch the lbr_bringup simulation using the command ros2 launch lbr_bringup lbr_bringup.launch.py model:=iiwa7 sim:=true.
Observe the robot in the simulation environment.

Expected Result

I expect to see the complete robot model with all its links and joints in the simulation environment.
Actual Result

The links and joints of the robot are missing after 0 in the simulation environment.
System Configuration

Operating System: [Insert Operating System and version]
lbr_bringup version: [Insert version]

Additional Information
The Problem occurs with iiwa14 aswell

Hi,

We are running Foxy branch in Ubuntu 20.04 real-time kernel. The robot is KUKA lbr Med14, with KUKA sunrise software version 1.15 installed on the controller.

After building, we launched the bringup file:
ros2 launch lbr_bringup lbr_bringup.launch.py model:=med14 sim:=false
Then we got some message from node "[lbr_spinner-1]" and "[ros2_control_node-2]", saying that joint position is nan for joint 0.
To further examine, we added some lines to print joint positions in each iteration. As you can see below, every second iteration the joint position bacame a nan for joint 0.

This problem happened when we tried to include a moveit2 package (from moveit2 tutorial). However, after we removed the moveit2 package from workspace (i.e. only the lbr_fri_ros2_stack and its dependencies in workspace/src) and did a clean build, the problem still presents.

Any help will be highly appreciated! Thanks.

the med gazebo xacro tag is wrongly named

https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/a8ae3e7168445d1d82ab765c4485c868ae7eda9a/lbr_description/gazebo/med.gazebo.xacro#L3

Hi,

I'm tying to set up the server on the real robot but I'm unable to create a connection. Has anyone encountered this error before?

Might need to add cmake flag for release build or set a default build unless specified, ie colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release

Hello,

First of all, thank you for sharing this project.
Base on your code, I am running this repository in Ros2 Galactic after modifying lbr_hardware pkg.

I am just writing to report a trivial typo I found in a gazebo simulation with moveit.

In Line 96 in lbr_move_group.launch.py, there is a typo, "sime_time".

use_sim_time = {"use_sime_time": LaunchConfiguration("sim")}

Without this fix, the trajectory obtained from moveit will not be executed through gazebo. (due to time synchronization)

Hi,

Sorry to bother you guys multiple times, but we do have another problem regarding to running the LBRServer.java.

When we run the LBRServer application on KUKA SmartPad, the FRI session state will change to "MONITORING_READY" after some time (around 60s). And soon after this the FRI connection disposes as you can see below in the screenshot.

We are checking the FRI manual from KUKA but have not figured out why it is happening. Please let us know if you have any idea on how to increase the timeout or prevent the FRI session from getting disconnected.

Thanks for your help!

There seems to be an issue with the Med14 model in Gazebo:

Rviz seems to be fine though.

          Thanks for the help @mhubii and the new changes seem to work for me. 1 small step I needed to also make was updating my cmake version without uninstalling the old one, so I followed the steps here:

https://gist.github.com/bmegli/4049b7394f9cfa016c24ed67e5041930

Thanks also for the heads up on the foxy moveit issue with the launch files, and I'll see if I can give humble install a try again for better performance.

Originally posted by @srisainachuri in #51 (comment)

In the past, the launch file bringup.launch.py will publish /lbr/command and /lbr/state topics. But now I found it doesn't. Is this normal?

And now the cpp demo doesn't need to launch bringup.launch.py cause the app_node is used(Inconsistent with README).

Add simple building checks, then a proper testing pipeline

Hello,
First of all thank you for this repo, it looks really interesting and exciting!

We have gone through the setup, using the noetic branch, but unfortunately encountered a few issues. We have a LBR iiwa 14, to which we have added the FRI package and the LBRserver java file in the src folder. The install and sync went well.
We then connected our client PC which runs on ubuntu 20.04 and with ros Noetic to the controller through the two possibilities:

• the X66 port and using 172.31.1.148 as IP, rate of 10ms
• the KONI port and using 192.170.10.1 as IP, rate of 10ms

In both cases, we are able to ping the controller but unable to create a connection.
We first start the LBRserver application on the SmartPad (rate 10ms, Position Control) and then we run on the client PC the moveit_planning_execution.launch, but the LBRserver stops pretty quickly after not getting any response from the client PC with a "timout before FRI connection was good or excellent" error.
We used wireshark to have a look at the UDP communication, and we can clearly see that the controller is sending packages but our client PC is not responding.

The outcome is the same for both ports/IPs.

Are we missing something? We are not a part of your university, so we do not have access to your sharepoint.