I did not set up the Sunrise cabinet to connect to ROS Master via KONI port. I set the Master as per your instructions. I am using the X66 port The SmartServo App on sunrise connects to the master. I can see the Topics but when I try to echo anyone of them to get the data, I get a "Couldn't find an AF_inet address for [[fe80]" error.

My questions are.

1. Is this because I did not setup the cabinet to work with KONI port?
2. Why are we not using the X66

We are having trouble moving the robot, although we receive its position and torque data. We double checked the IP and network settings as mentioned in the wiki, and we looked at the network activity in the Sunrise Cabinet. Sent and Received data increases normally when we subscribe to joint or torque data of the robot, but when we send a jointPosition, the Sent data stops increasing after the first message is received by the robot, it seems.

We tried putting a debug message into the callback function in the Java code, but it is never displayed. The robot interface complains about timeouts in other errors (see pictures), so I wonder if the message arrives but then locks up the thread somehow.

We use this code to publish the jointPosition. We're new to ROS, so this code might well be the problem.

We are still running on KUKA Sunrise 1.7 and the corresponding branch of iiwa_stack, but we will upgrade soon.

Can this send/receive any messages besides JointPosition?

The readme said the app can "iiwa_ros_java: the ROSJava interface to use on SunriseApplications - it allows to send and receive messages defined in iiwa_msgs", however reading the actual ROSSmartServo code perhaps there are some changes implementing that functionality not publically available yet?

I noticed when switching control mode to Cartesian Impedance, load mass validation is performed on line 235 in:
"iiwa_stack/iiwa_ros_java/src/de/tum/in/camp/kuka/ros/ROSSmartServo.java"
This is done on the frame: "LBR_iiwa_7_R800_1", even when an additional tool is defined.
(The selected tool has a definition and attached frame defined in sunrise and the smartpad indicates it is selected when starting roscore)
This then often results in a variance>10 and a subsequent failure to initiate the control mode.

How to tell sunrise it should use the currently selected tool frame for load mass validation?
It seems like robot is initialized correctly at line 214:
robot = getContext().getDeviceFromType(LBR.class);
but apparently not entirely

Hi,

I'm still in the learning-ROS phase, so please correct me if I am going about this in the wrong way.

I was trying to get two iiwa robotarms spawn in gazebo so I can control them separately.
From the way the package is (nicely) structured, I would have the feeling that it should be possible with minimal changes, but I cannot get it to actually work.
From what I find online, the best guess seems to be to adapt the urdf to get multiple arms into a single file, so that's what I tried.
What I did:

• adapt the transmission.xacro so all names are robot_name dependent
• spawn 2 iiwa's in the iiwa14.urdf.xacro, with a different robotname
  => this works, and both arms get spawned
  To try to control them, I
• spawn the iiwa_control twice, with a different robotname, and the robot_name is also part of the controller names.
• adapted the yaml file so it has a variant of each controller for each robot_name
  With that, I can almost control each arm separately, except that 2 joint_states are published, which each contain all joints, so they constantly contradict eachother and the arms jump between positions all the time.

I hope this explanation makes more or less sense :)

Thanks for any help!
Broes

Hi,

There are some transform error in the iiwa7 xacro file cause link 3 of the robot not rotating to the joint 3 center. I saw this small displacement when I rotates joint 3:

Later I found that there are some overlapping in link 1 and link 2:

By changing the origin of link 2 from (0,0,-0.006) to (0,0,0) and link 3 from (0,-0.005,-0.026) to (0,0,-0.026). The problem goes away without changing the transform of the links.

I tested both in OpenRAVE using or_urdf, and in RViz, they showed the same result.

I am trying to setup your packages to work with Kuka LBR IIWA. I am using ubuntu 14.04 LTS and ros Indigo. I found the robot connected with an wireless setting. Therefore, I didn't change the configuration. I uploaded the sunrise project to controller with no error or red sign in IDE. I followed roscore side. Next I ping with cabinet address and got reply.
However, when I run the lunch file using roslaunch iiwa_tool_examples iiwa_tool_read.launch, I found the error, [ERROR] [1458371985.836149274]: Robot is not connected.....

afroza@afroza-XPS-8700:~/ros_ws$ roslaunch iiwa_tool_examples iiwa_tool_read.launch
... logging to /home/afroza/.ros/log/8b1ff4da-eda1-11e5-8d62-989096a52895/roslaunch-afroza-XPS-8700-6122.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://afroza-XPS-8700:41750/

SUMMARY

PARAMETERS

• /iiwa/ReadRobotState/joint_position_topic: /iiwa/state/Joint...
• /iiwa/ReadRobotState/ros_rate: 1000
• /iiwa/publishJointStates: True
• /iiwa/robot_description: <?xml version="1....
• /iiwa/robot_description_kinematics/manipulator/kinematics_solver: kdl_kinematics_pl...
• /iiwa/robot_description_kinematics/manipulator/kinematics_solver_attempts: 3
• /iiwa/robot_description_kinematics/manipulator/kinematics_solver_search_resolution: 0.005
• /iiwa/robot_description_kinematics/manipulator/kinematics_solver_timeout: 0.005
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_1/has_acceleration_limits: False
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_1/has_velocity_limits: True
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_1/max_acceleration: 0
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_1/max_velocity: 10
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_2/has_acceleration_limits: False
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_2/has_velocity_limits: True
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_2/max_acceleration: 0
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_2/max_velocity: 10
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_3/has_acceleration_limits: False
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_3/has_velocity_limits: True
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_3/max_acceleration: 0
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_3/max_velocity: 10
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_4/has_acceleration_limits: False
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_4/has_velocity_limits: True
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_4/max_acceleration: 0
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_4/max_velocity: 10
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_5/has_acceleration_limits: False
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_5/has_velocity_limits: True
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_5/max_acceleration: 0
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_5/max_velocity: 10
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_6/has_acceleration_limits: False
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_6/has_velocity_limits: True
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_6/max_acceleration: 0
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_6/max_velocity: 10
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_7/has_acceleration_limits: False
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_7/has_velocity_limits: True
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_7/max_acceleration: 0
• /iiwa/robot_description_planning/joint_limits/iiwa_joint_7/max_velocity: 10
• /iiwa/robot_description_semantic: <?xml version="1....
• /iiwa/toolName: tool
• /rosdistro: indigo

• /rosversion: 1.11.16
  NODES
  /iiwa/
  ReadRobotState (iiwa_tool_examples/read_robot_state)
  robot_state_publisher (robot_state_publisher/robot_state_publisher)
  rviz_afroza_XPS_8700_6122_4091623036572324931 (rviz/rviz)
  ROS_MASTER_URI=http://172.31.1.2:11311
  core service [/rosout] found
  process[iiwa/robot_state_publisher-1]: started with pid [6143]
  process[iiwa/ReadRobotState-2]: started with pid [6144]
  process[iiwa/rviz_afroza_XPS_8700_6122_4091623036572324931-3]: started with pid [6145]
  [ERROR] [1458371905.833199520]: Robot is not connected...
  [ INFO] [1458371905.886202985]: rviz version 1.11.10
  [ INFO] [1458371905.886257469]: compiled against OGRE version 1.8.1 (Byatis)
  [ INFO] [1458371906.552963147]: Stereo is NOT SUPPORTED
  [ INFO] [1458371906.553024826]: OpenGl version: 4.5 (GLSL 4.5).
  [ INFO] [1458371907.212131210]: Loading robot model 'iiwa7_tool'...
  [ INFO] [1458371907.212188297]: No root joint specified. Assuming fixed joint
  [ERROR] [1458371910.833342426]: Robot is not connected...

  Please help me in this regard.
  Thank you

Hi,

I just took a look at the implementation of JOINT_VELOCITY in ROSSmartServo.java but haven't actually tested it yet.
In contrast to JOINT_POSITION_VELOCITY in setDestination() only the position is set, but not the velocity.
Did that work better in practice? I think otherwise you could just do

helper.rosJointQuantityToKuka(commandVelocity.getVelocity(), jv);
for(int i = 0; i < robot.getJointCount(); ++i) jp.set(i, jp.get(i) + loopPeriod*jv.get(i)); //add the displacement to the joint destination.
...
motion.getRuntime().setDestination(jp, jv);

similar to JOINT_POSITION_VELOCITY

Thanks,
Jens

First of all, iiwa_stack is remarkable, and so is your commitment to continually developing it!

I'm seeing that ROSSmartServo's tendency to leave the Sunrise task running in the background is a known issue. Has anyone figured out what exactly causes the task to hang in the background? I had a thought that maybe the SmartServo motion isn't explicitly stopped, so I added motion.getRuntime().stopMotion() in the cleanup() method, but it doesn't seem to help.

Beyond the obvious nuisance of waiting 15 seconds for the error message, the memory used to run the application is never relinquished. So if you're doing debugging, starting the application several times leads to an out-of-memory error on the sunrise controller, which requires a reboot to resolve.

Could you please describe me step by step process connect LBR IIWA Kuka(7R800) with ROS (Indigo) by using IIWA-Stack.. And it will be more fruitful if there will be some video tutorial regarding this...

Hi,

First of all, I am running ROS Indigo and Gazebo 5.3.0 on Ubuntu 14.04.

I tried to run the iiwa_gazebo.launch file (from master branch, with default argument values) and the controllers failed to initialise due to missing <robotNamespace> elements within the <transmission> elements in iiwa.transmission.xacro.

I added the missing <robotNamespace> elements to all 7 <transmission> elements as below and the controllers loaded successfully:

<transmission name="iiwa_tran_1">
      <robotNamespace>/${robot_name}</robotNamespace>
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="iiwa_joint_1">

Is that something exclusive to my setup/Gazebo version? Have you experienced this issue before?

I'd be happy to open a pull request if you like!

Thanks a lot!

Hi All,

I have a quick question. Does the interface support torque? The interface has a massage type dedicated to torque. Does it work? and another minor question, can we get the robot's mass matrix?

Thx a lot
Best
Sina

Hello,

Running the following command

roslaunch iiwa_moveit moveit_planning_execution.launch model:=iiwa14

results in the following warning:

[ INFO] [1487789324.400531125, 3.279000000]: Loading robot model 'iiwa14'...
[ WARN] [1487789324.400599896, 3.279000000]: Skipping virtual joint 'fixed_base' because its child frame 'iiwa_link_0' does not match the URDF frame 'world'
[ WARN] [1487789324.400649151, 3.279000000]: Skipping virtual joint 'fixed_ee_kuka' because its child frame 'iiwa_link_ee_kuka' does not match the URDF frame 'world'
[ WARN] [1487789324.400699731, 3.279000000]: Skipping virtual joint 'fixed_ee' because its child frame 'iiwa_link_ee' does not match the URDF frame 'world'
[ INFO] [1487789324.400766146, 3.279000000]: No root/virtual joint specified in SRDF. Assuming fixed joint
[ INFO] [1487789324.521896939, 3.400000000]: Loading robot model 'iiwa14'...
[ WARN] [1487789324.521933564, 3.400000000]: Skipping virtual joint 'fixed_base' because its child frame 'iiwa_link_0' does not match the URDF frame 'world'
[ WARN] [1487789324.521951315, 3.400000000]: Skipping virtual joint 'fixed_ee_kuka' because its child frame 'iiwa_link_ee_kuka' does not match the URDF frame 'world'
[ WARN] [1487789324.521971997, 3.400000000]: Skipping virtual joint 'fixed_ee' because its child frame 'iiwa_link_ee' does not match the URDF frame 'world'

These virtual joints are defined in iiwa_moveit/config/iiwa14.srdfand https://github.com/cpaxton/costar_stack uses these joints in its iiwa driver.

Any idea what the problem might be? There appears to be a mismatch between the world frame and how the links are defined.

Hey,

I'm also working on an iiwa stack though I'm taking a slightly different approach. I was wondering if you might be interested in some degree of collaboration and/or enabling some integration between our setups?

My project is grl:
https://github.com/ahundt/grl

The bulk of the kuka code can be found at:
https://github.com/ahundt/grl/tree/master/include/grl/kuka

We are working towards a driver supporting FRI and Java at the user's option. My group and I also have the first implementation of a ROS driver for this purpose.

I took a slightly different approach from yours so that users don't need ROS to use the driver. My system uses ZeroMQ and google flatbuffers to send messages to the JAVA API. When in FRI mode it directly sends packets to the FRI system but is planned to also be able to simultaneously communicate with the JAVA side for ongoing configuration changes.

Since using the KONI interface for the JAVA side is exclusive to using the FRI I currently don't take that step. What is the advantage there?

I'm also interested in your integration with other toolsets like moveit and gazebo.

Thanks for taking the time to consider my thoughts! It may also be worth noting that I'm at JHU and there are a few TUM people here from the CAMP lab.

Hello,

I tried to use the new function introduced in the new update to set the joint velocity by publishing JointVelocity to the topic /iiwa/command/JointVelocity. I am not sure if it is a bug or I have a misunderstanding on what the server will do. This is what I did and saw:

(1) The robot is in T1 mode. I moved the robot to joint position [0,0.7,0,0,0,0,0] by publishing to /iiwa/command/JointPosition. This works fine.

(2) Then I tried to move the 2nd joint with a velocity -0.2, and other joints are 0 velocity. I expect the second joint to reach -0.2 velocity after a short acceleration and keeps that velocity until new command is received or triggered some safety limits. However, the first time I send this command, it does not move. Everytime I try this, I need to send exactly 3 times to make it move

(3) After it moves, it seems it will stop at some random joint position. I tried several times, and cannot find out where and why it will stop.

(4) After it stops, I tried to rotate the joint back by sending 0.2 velocity in 2nd joint. Usually I will see this error message on the SmartPad and the program stops:

https://1drv.ms/i/s!AvtCHo07178NgfwTaBy0gyovl5Fxxw

I believe I have misunderstandings on what this function does. Could you please tell me more details about its implementation? Thank you.

Yu-Chi

Hello all,
I am trying to control an simulated kuka lbr iiwa robot with a cpp script using move group commands.
The original script is not from me but a tutorial using an ur5 robot.
Anyway, after executing the script everything works fine but the robot doesn't move (with ur5 the similar script worked).
Is it possible that I need to change some names or publish to a different node than with the UR5?
If someone already created a program to control this robot using move group commands it would be really helpful if I could use that script as example to make mine work.
Thank you for your help.

iiwa_script.docx
iiwa_launch.docx

There seems to be a lot of dependencies for this that aren't documented. Could I get a complete list?

So far I've needed to add:

• from ros-controls
  • ros_control
  • ros_controllers
  • realtime_tools
  • control_toolbox

It seems that I need to use your ROSSmartServo application as a base, and add my own publishers, subscribers, messages, and control loop elements. Are there any examples of implementations of iiwa_stack in this manner? My goal is to be able to make my modifications modular, so I can get new versions of iiwa_stack easily, but I'm curious to know if there are several possible ways of doing this.

there have been some changes in 1.9 so the iiwa_stack will need updates to match

As per subject really.

I was wondering why ROSBaseApplication.run() invokes NtpTimeProvider.updateTime() instead of configuring the NtpTimeProvider instance to manage its own periodic updates using NtpTimeProvider.startPeriodicUpdates(..).

Are the periodic updates too slow / inaccurate for the driver? It would seem to make it possible to do away with the decimation counters and make the while-loop tighter.

As I need some features of Sunrise.OS 1.11, I was wondering if you are planning to support this version in the future?
In the FAQ is written, that normally only tiny changes are needed to support newer versions, so I'll probably also try for myself if I can get it to work.

Hello,

I am using KUKA LBR 14 R800, with Sunrise 1.8. I open this issue because while following the sunrise_project_setup tutorial, I accidentally installed the sunrise project using an IP that interferes with the cabinet's internal structure. The IP I used is one within the prohibited range, as stated in the KUKA Sunrise user manual (unfortunately, I saw that after uploading).

As a result, the cabinet Application Server fails to connect, and tries to reconnect continuously. I would like to ask whether someone faced this problem and was able to recover from that. I am considering reinstalling the Cabinet OS (any tutorials for that are welcome).

Thank you very much!

Hi,
I am using my robot with sunrise 1.11 and the standard ethernet interface v(Not KONI).
I am able to ping also see the list of topics. But no messages seem to be published to the topics.

I have roscore running and rosservo running on the controller. The last message shown on the dialogue box is "entering node loop" after "connected to master".

Also, ntp host is set to false

Hello!

I have troubles following the procedure detailed in cabinet_setup. I'm trying to setup your solution on KUKA Sunrise.OS 1.7.1.12.

During Step 2:

2. Shutdown KRC
   It is the green icon in the system tray.

The green icon you describe seems to be the StartKRC Icon. Right-clicking on it displays "KRCDiag" or "Stop KRC". However, "Stop KRC" just shuts down the robot computer and disables the remote connexion as well, which prevents from doing any further action.
Hence, my solution was to go in the task manager and end StartKRC.exe.

3. Open a terminal and type
   C:\KUKA\Hardware\Manager\KUKAHardwareManager.exe -assign OptionNIC -os WIN
   This will assign the KONI interface to Windows.

Running this command led to the following output in the KUKA Hardware Manager :

2017-03-01 16:23:29 INFO Trying to assign OptionNIC to WIN ...
2017-03-01 16:23:30 INFO Success running 'DevInstXP /Q /+ /ZI'
2017-03-01 16:23:30 INFO BoardID from Registry: D3236-K1
2017-03-01 16:23:30 INFO BusType OptionNIC found (HardwareID PCI\VEN_8086&DEV_1533&SUBSYS_11FC1734&REV_03, Address 0)
2017-03-01 16:23:30 WARN Assignment not possible while KS is running

any attempts at killing more processes (KUKAHardwareService.exe, KukaPMService.exe KUKAHardwareManager) before step 3 didn't improve the last WARN message...

After hoping against hope that I was supposed to get this output, I tried the forth step. However, no reference to a KONI port seems to have added to the list of my Device Manager..

I believe I couldn't shutdown KRC properly (step 2) which prevented me from going any further. Would you have any solution to my problem please?

KUKA control modes also include a really useful mode that allow to apply a constant force at the tool tip, we should integrate that too.

Hi,thank you for your sharing. I have noted that the last version of kuka lbr supports the gravity compensation via FRI. In your work, position command is transferred via a variable defined in iiwa_msg, and KUKA FRI is not actually integrated. I don't know if the new IIWA series interface includes that function. And if it does, how would you include the FRI interface functions in the future work? Any differences between the two versions of FRI?

The current implementation of iiwaConfiguration has most of its member variables declared as static (the staticConfigurationSuccessful variable fi).

I was wondering if one of the authors (@marcoesposito1988, @SalvoVirga) could provide some rationale as to why this class was set up this way?

We currently use the KONI Ethernet port of the cabinet for our communication.
That is an heritage from Khanris's work, we should rather use the Ethernet port used to sync with Sunrise Workbench.
This would allow to integrate FRI commands using that port, and make the whole setup of the stack way easier (without the need to modify settings on the cabinet).

I always start the ROS Application on the Master with roslaunch. The first start works fine and it connects to the ROSSmartServo application on the Workstation.
But if I restart the ROS application on the Master, the connection doesn't get established again until I also restart ROSSmartServo.

I need to connect IIwa kuka robot with kinect 3d camera by using ros.

Just seeing whether there would be any interest to migrate to the messages and services defined in the ROS-Industrial Majorana project.

The message set is intended to try and bring some uniformity to the interfaces to impedance / force-control supporting (robot) controllers with a ROS interface out there. There has been some initial work to get ahundt/grl working with it, and it would seem this driver could benefit from it as well.

Is there already a way of polling whether a destination has been reached?
The KUKA servoing manual states:

The IServoRuntime class contains the isDestinationReached() method.

Notification upon achievement of target:
For SmartServo and SmartServoLIN motions, the listener SampleGoal-
ReachedEventListener is available. It signals that the destination setting has
been reached using the event onGoalReachedEvent(...).
The listener must be derived from the class IServoOnGoalReachedEvent and
be registered on the interface IServoRuntime by calling the method setGoal-
ReachedEventHandler(...).

Could be a handy feature for on the ROS side.

Hi to all,

I installed iiwa_stack on my real robot kuka iiwa and it works perfectly. I am trying to have a control mapping with the gazebo simulator. I am able to start the simulation and use it with moveit packages released in this repository. Sadly I am not able to have the same topic to control single Joints (like the real robot). Is possible to control robot joints directly?

What I do is only to launch the iiwa_gazebo.launch. Should I run other pakages insted?

Regards.

Hello.
I was trying to see the full example of command the robot using move it, but when I try to open the link https://github.com/SalvoVirga/iiwa_stack_examples/blob/master/iiwa_tool_examples/src/command_robot_moveit.cpp
It give me and 404 error.

Currently, Sending command/JointTorque command/JointVelocity to the robot is disabled/commented in iiwaRos.cpp. Is this an untested feature? We have the iiwa 800 and I would like to use this feature. Any gotchas/concerns about enabling these? This is related to issue #28

When trying to the build the package after cloning, i get an error that iiwaRos.h cannot be found when compiling iiwa_hw.h. Replacing it with the full path gets it to compile.
Probably there is some include missing in the cmake file?

Thx!
Broes

I'm having some trouble with the elbow dropping down and into a limit when in cart imp mode.

To my mere human judgement, a stiffness and damping (in nullspace) of 5 and 0.1 feel practically the same as a stiffness of 200 and a damping ratio of 0.7.

I know the end-effector mass specs to be slightly off since it is so light, but it was workable before. The nullspace properties are set correctly in ROSSmartservo.Java as far as I can tell.

Anyone else noticed nothing changing in nullspace dynamics when defining them upon a service request? Or a way of preventing elbow drop? endpoint dynamics do not seem to affect it.

I am using a real robot LBR iiwa 7 R800. I also want to simulate this in Gazebo. However, it is stated that "Simulation with Gazebo is currently fully functioning ONLY for the KUKA LWR IIWA R820 (the 14 kg model).
The reason is that inertia values for the IIWA R800 model are not defined in its URDF yet."

I would like to know is there any way to simulate LBR iiwa 7 R800 model using your package? Or when gazebo support for this model will be available? Also can I control my robot using MoveIt? Does your package iiwa_moveit support LBR iiwa 7 R800 model?

I have set up iiwa_stack on three robots now and have feedback. Maybe you can amend the wiki page accordingly.

• One of our newer arms would not display the login screen if both a DVI cable and the smartPAD were connected to the robot. The smartPAD has to be disconnected to follow the instructions.
• It helps to open the device manager and the network adapter settings and to note which adapters exist before doing step 3 (it should be only the Realtime OS Virtual Network Adapter (IRQ)).
• I never had to install drivers as described in step 4. I wouldn't know how to install the files either, so this confused me on my first try.
• On the latest robot, the Network adapter appeared without rebooting.
• It may be good to put in an explicit warning such as "Do not change the settings of the Realtime OS Virtual Network Adapter. The network adapter you want is a different one." It didn't happen to us, but almost. It's an easy mistake to make.

Apart from that, we also added our robot (160.69.69.100) as the default DNS server. Otherwise, you have to set up the hostname on the ROSCORE PC to be its IP address, which is not very pretty. This was often the cause for the robot sending its state, but not reacting to commands.

I have a hunch that this is a robot setup issue, but maybe you know where to look to fix it. When ROSSmartServo is running, it exits with an IllegalStateException when the external torque is reported high (see image)

From what I can tell we have set up no safety monitoring on the torque, and the code seems like it should not break out. Do you have any experience with this? Should we upgrade the robot's firmware?

We are running Sunrise 1.7 with the code from master-Sunrise1.7

Thanks in advance

useful links for determining inertial parameters of kuka iiwa R800:

https://www.google.co.in/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=Dynamic+Identification+of+Manipulator%3A+Comparison+between+CAD+and+Actual+Parameters

http://www.inacomm2015.ammindia.org/img/94.pdf

These could be incorporated into the urdf.

@Ahyan1 you may be interested in this based on #11.

Hello all,
we want to control a real kuka iiwa robot using the iiwa_hw part of this package.
As you can see in the attached picture first we got the error : [Robot is not connected.]
and after that [Couldn't find an AF_INET adress for [[fe80] ].
We already tried the solution you find with google like changing the EXPORT statement in .bashrc from localhost to the actual IP but that did not solve anything.
We think it could be related to the IPv6 since the kuka handheld outputs something like fe80:0:0:0:0%efe:c0a8:1 as the robot IP.
We are using the kuka sunrise version 1.9.1.7.

Thanks for your help.

I am running Sunrise 1.9 Java 1.6 on the KUKA controller and ROS Indigo on the control PC.

The robot seems to be publishing info just fine. However i am not able to subscribe to subjects, say "/iiwa/command/JointPosition".

I have also tried to setup a simple /Float64 subscriber with the same results. It seems that the message listener (onNewMessage) callback is never executed.

I can see the ROSJava node is registred in the ros graph and that the topic that i am subscribing to gets registered. But again for some reason the subscribers ROSJava callback never gets executed

I saw in the documentation that you are using Java 1.7. In that case how did you get 1.7 installed on the controller.

Hi,

I am trying to communicate with iiwa 7 r800 using the iiwa_stack. The current Sunrise version is 1.9 and I am connecting to the java side to using a USB NIC (as discussed in #7). The configuration seems to work fine (the java application can connect to the master and rostopic list shows me all the topics) but no messages seem to be published. rostopic echo is not able to read any messages on any of the topics. However sometimes, -very sporadically- it does work. Have you ever run into these kind of problems?

I was using the iiwa7 urdf as a starting point for a model in a different format and I noticed that joint 3 has limits of +/-170 but soft limits of +/-118. Is this a copy/paste error? Or is that really the recommended soft limit?

Hi All,

If I understood correctly, the roscore is running on the cabinet (the control box). If it is true, is it possible to control two IIWA robots at the same time by using this interface? What are going to be the IPs, i.e. ROS_MASTER_URI, ROS_IP and the cabinet's IPs?

Thanks a lot for you help.

Best,
Sina

I noticed you have inertia parameters:
https://github.com/SalvoVirga/iiwa_stack/blob/master/iiwa_description/urdf/iiwa14.urdf#L51

Are they ballpark estimates, or very accurate ones? Thanks!

Setting a relative (joint) velocity does not seem to make any difference when sending Cartesian pose commands in Cartesian Impedance mode.
Any value in <0,1] gives the same resulting motion for me.
Although seems to be properly defined on java side.

Hello,

The ROS interface accepts two kinds of input: joint position and end-effector Cartesian. I wonder if it is possible to send joint trajectory to the robot using this package? or do you have any suggestions on how to implement one? Thank you.

I was having difficulties visualizing the robot in rviz.
Some digging showed that the robot_state_publisher is giving timing errors on the tf's.
Turned out the smartpad clock is an hour ahead of the (correct) system time on the ROS side.
Probably some daylight saving issue. Any idea how to sync these timers? sunrise Doc turns out empty.
Bug could be easily catched by checking if offset is around 3600 seconds.