When attempting to run the node from inside the virtual machine I get error code 1015. Although I see that the error is ERROR_CLAIM_INTERFACE, I am unsure what that means and what is causing it.

Please advise.

I use part of the joints_action_client to move the arm to certain configurations, but have some troubles:

• For what I am testing the joint velocity is a bit too high for having time to manually counter potential collisions, is it possible to set a lower velocity?
• After setting a joint configuration the joystick controls the arm in joint-space instead of cartesian space. Is this a known problem? Is there a fix?
• Is there some way to take (known) obstacles into account when moving to pre-defined joint configurations?

Hi, I'm working with a mico arm (firmware: Actuators 1.2.6, Fingers 1.1.3) on the Ubuntu 12.04 ros hydro.

When I roslaunch the mico_arm.launch (or jaco_arm.launch), the terminal display these messages as follows:

[ INFO] [1411619270.995993976]: Initializing Kinova API (header version: 50101, library version: 5.0.6)
[ERROR] [1411619271.106618061]: Could not find the specified arm (serial: PJ00650002132770005) among the 1 attached devices
[ERROR] [1411619271.106820590]: JacoCommException: Could not find the specified arm (return code: 0)

However, the arm.launch can initialize the API successfully.

When using the home_arm service, the JACO2 successfully homes along with just two of its fingers. The third finger does not move, and as a result the third finger does not respond to movement commands (in this case, grip_workout.py was used to test the fingers). The joystick controller must be used to manually move the fingers to the fully open position, at which point the API is able to control all three of the fingers.

It would be nice to have support for Catkin to use the node within the Groovy build system.

From the README.md, it seems like only the last 3 wrist joints are continuous. But in the URDF here it also makes joint 1 continuous:

<xacro:jaco_joint joint_name="${joint_1}" type="continuous" parent="${link_base}" child="${link_1}" joint_axis_xyz="${joint_1_axis_xyz}" joint_origin_xyz="${joint_1_origin_xyz}" joint_origin_rpy="${joint_1_origin_rpy}" joint_lower_limit="${joint_1_lower_limit}" joint_upper_limit="${joint_1_upper_limit}"/>

Is this a bug?

I'm using Jaco 2, is there a difference?

Also, are there reasons to set fake limits? I see the comment in the README.md:

You may want to limit to +/-6.28 rad in software to prevent the joints from rotating excessively.

Kinova should provide a simplified collision model for e.g. collision checking or robot body removal from point clouds. Please, try to provide the model in terms of primitive shapes, not meshes (which are slow in computations). Or at least provide simplified convex hulls of the meshes.

As a starting point, you can cherry-pick my work for Jaco arm: 14c006a (I won't create a PR because we have lots of different stuff changed in our working branch).

I was playing a little bit with the URDF model of the Mico arm in rviz,
and I realized that the fingers do not have the additional underactuated
joint. Are you planning on releasing soon the full gripper URDF model?

On firmware version 4.x I was able to stop the API control by just moving the joystick or pressing a button. On the latest version, nothing happens and even if I stop the API control programmatically it doesn't work. It also seems that the led indicators on the Joystick have changed. When in API mode led one and two was lit on the older firmware, when not in API control only led one was on. Now in the new firmware when not in API control only led one is on and if not in API control no led is on.
I would really be able to stop API control because it's the only save method to stop the Jaco.

When I connect to the arm get everything running I try the command:

 rosservice call /jaco_arm_driver/in/start_force_control

and then get the error:

 Error: Service [/jaco_arm_driver/in/start_force_control] is not available.

And when I check if it exists with:

 rosservice list

it is not on the list.

Furthermore, at the top of the documentation on your main page, it does not list Force Control as a service provided but it does further down the page in the services section.

So my question is, is Force Control possible with the Mico Arm?
And can the main page be updated so as to not have the confusion?

Thank you for any help!

I want to record the movement of Jaco arm and play it back.
How to do it?

On which ROS/Ubuntu distributions has the new library been tested? Could you add this information to the main readme?

During catkin_make an error in kinova_comm.cpp occurs due to the header file:

include <KinovaTypes.h>

I guess Changing it into:

include "KinovaTypes.h" solves the problem for me.

Trying to move the arm by publishing directly to the topic as:

rostopic pub --once /arm_pose/goal jaco_driver/ArmPoseActionGoal "{header: auto, goal_id:{'id':""}, goal:{pose:{pose:{position:[0.20, -0.23, 0.43], orientation:[0, 0, 0, 1]}}}}

results in the following error:

[ INFO] [1377780222.922908564]: Got a cartesian goal for the arm
[ERROR] [1377780222.923070135]: Could not get transfrom from /jaco_api_origin to , aborting cartesian movement
[ WARN] [1377780222.923222014]: Your executeCallback did not set the goal to a terminal status.
This is a bug in your ActionServer implementation. Fix your code!
For now, the ActionServer will set this goal to aborted

The finger positions of the robot model does not update in RViz.

Obviously not important, but it would be more standard ros_control convention.

I'm receiving error code 1014 (ERROR_JACO_CONNECTION) when I try to run the launch file jaco_driver/launch/jaco_arm.launch. I get the following error output:

[FATAL] [1381469449.501827749]: Could not initialize arm
[FATAL] [1381469449.502122084]: Jaco_InitAPI returned: 1014
[jaco/jaco_arm_driver-2] process has died [pid 12775, exit code -11, cmd /home/lukegt/fuerte_workspace/ros-jaco-arm/jaco_driver/bin/jaco_arm_driver __name:=jaco_arm_driver __log:=/home/lukegt/.ros/log/483080d2-3236-11e3-8d47-000c29e2478c/jaco-jaco_arm_driver-2.log].
log file: /home/lukegt/.ros/log/483080d2-3236-11e3-8d47-000c29e2478c/jaco-jaco_arm_driver-2*.log

Thinking that it might've been a permissions issue, I created the following file: /etc/udev/rules.d/50-kinova.rules

# libusb Jaco nodes
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="22cd", MODE="0666"

But this didn't work out. lsusb gives the following output, with the last entry being what I believe to be the Jaco arm:

Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 027: ID 22cd:0000  

I'm running 32-bit Ubuntu 12.04 in a VM Workstation virtual machine. My host OS is Windows, and I can successfully connect to the Jaco using Jacosoft.

Any clues as to what's going on here? Any guidance will be much appreciated.

I know this branch isn't ready, but I need my Jaco 2 working now so I studied your changes. If you don't mind:

There is a misspelling of "RefresDevicesList" in include/kinova/Kinova.API.UsbCommandLayerUbuntu.h

In kinova_driver/src/jaco_arm.cpp there appears to be a regression where it says

joint_state.position[1] = (jaco_angles.joint2 - 270) * (PI / 180);

shouldn't the 270 be the variable j6o like it was previously?

Also, how stable is this and the experimental branch? How many bumps should I expect if I start using it now?

I am missing the FollowJointTrajectory action interface to communicate with MoveIt!.
Has someone created an adapter for that or is there a MoveIt! interface to communicate with this package I am not aware of?

I have a KG-3 gripper with me, which I would like to connect to ta different robot and I would like to use the jaco ros to connect to the gripper.
I have the base power supply module and I am connecting to it using USB and every time I try to launch the jaco_arm.launch I get the following error

[ INFO] [1449704319.866393727]: Initializing Kinova API (header version: 50101, library version: 5.0.6)
[ERROR] [1449704319.868765466]: JacoCommException: Could not initialize Kinova API (return code: 1015)

I assume that the drivers are failing to connect as it is not able to communicate with the firmware in the arm.
It would be really helpful if there was a way to use the gripper without the Jaco ARM.

Are there plans to add the capability to simulate Jaco / Mico kinematics in Gazebo? Would be a nice feature to have to test functionality while awaiting delivery of arm.

I get a nice output when I home the arm:
[ INFO] [1476979654.727292332]: haha Arm is in "home" position

You might want to correct line 1208 of kinova_driver/src/kinova_comm.cpp

Cheers :)

The ROS wiki page is outdated.

We are using the mico arm with 6 joints and two fingers and firmware version 5.2.1.22 using the latest kinova-ros driver. The joint position and velocity control is working fine, however the cartesian position and control is not working. Also, mico_home service is not working. We were using the command line tools as mentioned in the readme.

We tested the kinova SDK (in Windows) and we were able to control the cartesian velocity using the keyboard. However this only works once the robot is sent to home position using -H on the keyboard.

Do you have any ideas on how we can debug this issue?

Throughout the README.md it says the parameter is node_name such as:

rosrun jaco_demo joint_angle_workout.py node_name random num        - randomly generate num joint angle sets

This is misleading because when running rosnode list I see my node is called "jaco_arm_driver" but what these python scripts actually want is just "jaco". I think the scripts should be changed to use the whole node name so it is more intuitive to ROS users.

Hi,

I am trying to launch the package, so, I typed $roslaunch kinova_bringup kinova_robot.launch
then got an error and it stuck there,

[ INFO] [1474363787.379153676]: Initializing Kinova API (header version: 50200, library version: 5.2.0)
[ERROR] [1474363787.381342213]: KinovaCommException: Could not initialize Kinova API (return code: 1015)

I found something about 1015 at the bottom of Readme but It does not give me any help.

How can I solve this? :(

Env is
Ubuntu 16.04 (not VM) with ROS Kinetic 1.12.2

• It happened on Ubuntu 14.04 with ROS Indigo, Ubuntu 12.04 with ROS Fuerte / Hydro as well.
• I just found another thing,
  If I try to launch with robot type m2, (e.g. m2n6s300, m2n4a200, whatever.) then an error occurs.
  full terminal log below.

$ roslaunch kinova_bringup kinova_robot.launch kinova_robotType:=m2n4a300
... logging to /home/drivebot/.ros/log/73ca7f8c-7f1c-11e6-9d79-fcaa14a2287a/roslaunch-drivebot-M4HM85P-00-20749.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.

xacro: Traditional processing is deprecated. Switch to --inorder processing!
To check for compatibility of your document, use option --check-order.
For more infos, see http://wiki.ros.org/xacro#Processing_Order
No such file or directory: /home/drivebot/catkin_ws/src/kinova-ros/kinova_description/urdf/m2n4a300_standalone.xacro
XacroException('No such file or directory: /home/drivebot/catkin_ws/src/kinova-ros/kinova_description/urdf/m2n4a300_standalone.xacro',)
Invalid tag: Cannot load command parameter [robot_description]: command [/opt/ros/kinetic/share/xacro/xacro.py '/home/drivebot/catkin_ws/src/kinova-ros/kinova_description/urdf/m2n4a300_standalone.xacro'] returned with code [2].

Param xml is <\param command="$(find xacro)/xacro.py '$(find kinova_description)/urdf/$(arg kinova_robotType)_standalone.xacro'" name="robot_description"/>
The traceback for the exception was written to the log file

Regards, Sun

Right now if you send an angular command to move the arm, the tool_position topic is no longer updated. Similarly the joint angles are not updated when cartesian motions are executed. This also occurs when using the home_arm service.

I tried to launch robot with following command :
roslaunch kinova_bringup kinova_robot.launch kinova_robotType:=j2s7s300 use_urdf:=false
but it returns error :
[ INFO] [1469825146.149697563]: kinova_robotType is j2s7s300.
Please specify the kinematic of robots other than jaco and mico!
[j2s7s300_driver-1] process has died [pid 2725, exit code -6, cmd /home/administrator/vinobot_ws/devel/lib/kinova_driver/kinova_arm_driver j2s7s300 __name:=j2s7s300_driver __log:=/home/administrator/.ros/log/694e5d8c-55cb-11e6-bc33-003018c2a7c0/j2s7s300_driver-1.log].
log file: /home/administrator/.ros/log/694e5d8c-55cb-11e6-bc33-003018c2a7c0/j2s7s300_driver-1*.log

Whenever I run "roslaunch jaco_driver jaco_arm_launch" I get the following error -

[ INFO] [1438286522.917873264]: Initializing Kinova API (header version: 50101, library version: 5.0.6)
[ERROR] [1438286523.031603216]: JacoCommException: Could not get general information about the device (return code: 2005)

The arm was working properly before this, so I am unsure what exactly went wrong.

Hi,

I would like to remotely control the mico arm with a master device (like a joystick). What is the maximum refresh rate of the Mico arm?

And how can I change it?

Thanks.

Are you going to release the new library as an official ROS package?

I need to write code that works with both JACO and JACO2, however when I tried to launch with kinova_robotType:=j1n6a300 I get an error message that the file 'j1n6a300_standalone.xacro' does not exist. I looked in the folder, and there are no URDF files for JACO version 1?

How can the new API be used with both versions of the arm - with URDF model?

I've embedded "kinova_bringup/launch/kinova_robot.launch" in a namespace (e.g. "kinova_ns"), which leads to that almost all topics has the correct prefix. The exception is the topic "/j2n6a300_driver/out/joint_state" (subscribed to by "j2n6a300_state_publisher").

I don't think this causes troubles, but it does not look as nice.

When I use the joint_angle_workout.py demo to execute an ArmJointAnglesAction (send a series of trajectory points to the robot arm), the arm can follow the joint trajectory well, but it stops at each waypoint before driving to the next waypoint. Is it posiible to drive through the desired path faster without stopping at each waypoint? Thanks a lot!

Trying to control Jaco arm with ROS-hydro and jaco-ros

the arm appears to be connected using 'lsusb'
Bus 001 Device 002: ID 13d3:5702 IMC Networks UVC VGA Webcam
Bus 002 Device 015: ID 22cd:0000
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

This is what i get when I do roslaunch jaco_driver jaco_arm.launch

[ INFO] [1415117300.461576789]: Initializing Kinova API (header version: 50101, library version: 5.0.6)
[ERROR] [1415117300.684649220]: Could not find the specified arm (serial: PJ000000010301) among the 1 attached devices
[ERROR] [1415117300.684941575]: JacoCommException: Could not find the specified arm (return code: 0)

The serial number is the one that I get on connecting with Jacosoft.

The 32 bit CommandLayer API for Jaco expects to find the comm library in the directory which the Jaco node is launched from. This is unlike the 64 bit version of the API which will look in system library paths. As a result, on 32-bit architectures, the node will fail to launch as-is since roslaunch launches everything from ROS_HOME.

As a workaround, the comm library may be copied to the ROS_HOME, e.g.:

$ roscd jaco_driver/lib/i386-linux-gnu
$ cp Kinova.API.CommLayerUbuntu.so ~/.ros/

This should fix launching the node with roslaunch or rosrun.

I'm just started to work with a JACO arm, using the 'catkin'. In my first tries of using the driver an error was reported ([jaco/jaco_arm_driver-1] process has died [pid 6739, exit code -11...), searching on the file 'jaco_comm.cpp' I realized that was because the arm wasn't turned on, but the error message doesn't say that.
The code that shows the real error (lines 81 - 93) is not even executed, my suggestion is to change the position of this part of code to before the 'StartControlAPI' call.
Here this change works very well.

Hello,
I am using Jaco arm for pick and place task using 3 finger gripper.
My code is in ROS. I set the noint angles first using jaco_angle_action server, then try to control finger positions using jaco_fingers_action server.
These two action servers are sent the goals in same python node. Finger positions are changed by the client periodically in a while loop.
I observe that, both of the tasks, that are, moving the fingers and holding up the arm position fail to happan simultaneously.
The arm is seen to be moving under the influence of gravity when fingers are being controlled.
The arm keeps going down in jerks, finally ends up on the floor.

Any pointers on how to work it around are most appreciated.
Also a quick response would be highly useful as publishing a paper with approaching deadline is blocked by this issue.

Thanking in advance,
Kunal

We have a MICO research edition arm and are trying to get it to work. When we use the jaco_arm_driver from here we can built it (although we had to add ${CMAKE_DL_LIBS} to the target_link_libraries of the jaco_arm_driver). When we try to run it we get:

./jaco_arm_driver: symbol lookup error: /home/x/catkin_ws/devel/lib/libjaco_pose.so: undefined symbol: _ZN2tf11Transformer18DEFAULT_CACHE_TIMEE

and:

./jaco_tf_updater: symbol lookup error: home/x/catkin_ws/devel/lib/libjacokinematics.so: undefined symbol: _ZN2tf20TransformBroadcasterC1Ev

It seems that certain libraries cannot be found (as symbol lookup error suggests). How can we fix this problem? We are using Ubuntu 12.04.

Hello,

We are using the mico arm with the kinova api. When we send Cartesian velocity using the SendAdvancedTrajectory call the robot acts in the drinking mode (a velocity in +Y direction makes the arm wrist to rotate and it will go near the drinking position). The ActualSystemStatus for the DrinkingMode is 0 (enabled by default). We do not have a Kinova joystick.
How can we disable the DrinkingMode and achieve a normal Cartesian behavior for the velocity control using the api?

Thanks!

Siddarth

The robot model in rviz cannot display the finger movements. How to solve the problem?

I can control the finger via the python script.

No expected changes in behaviour, but should be verified anyway.

Hello,

I need the transformation matrices of MICO to control it.
Now I'm using the matrices referring to the comments on jaco_arm_kinematics.cpp.
However, tfs from jaco_tf_updater.cpp (which uses jaco_arm_kinematics.cpp, you may know) is different from tfs from MICO's urdf.

Which is the same as the real MICO configulations?
How can I know the transformation matrices of MICO?

thanks.

I noticed here

broadcaster_.sendTransform(tf::StampedTransform(transform, ros::Time::now(),
                                            "root",
                                            concatTfName(tf_prefix_, "link_base")));

That the base tf is hard coded to "root". It would be useful to be able to define that as a parameter. In my case, the reason is that the arm is mounted onto other stuff therefore the base link of the arm isn't "root".

In some end effector poses, the setFingerPositions command does not cause the fingers to move.
This is reproducible by putting the mico arm in the position:

Actuators:
Actuator1: 241.93
Actuator2: 281.801
Actuator3: 161.085
Actuator4: 240.205
Actuator5: 68.1818
Actuator6: 104.386

and then calling the setFingersPosition with the values 4000,4000, 4000.

The exact resulting TajectoryPoint sent can be found here:
https://gist.github.com/jon-weisz/e6baf40ea9cd7711e613

Sending the same command in Angular Position mode results in the fingers closing, but the hand dropping slightly, as described in the known issues occuring with the Jaco arm.

The drop appears to be on the order of .005 m, which is problematic for fingertip grasping.

I can subscribe to cartesian topics like tool_position but the cartesian workout just doesn't work. On the terminal it says Using the specified pose and Done but nothing happens to the real arm.

Everything else has worked perfectly so far except for this cartesian_workout.

Any hints on this one?

I started to work with jaco_driver, I encounter a problem which is as follows:

I launch the "jaco_driver" and run "pose_action_client.py". The arm moves to the defined position. but if I want to try to send a new goal by rerunning the script and change the position, the arm does not move.

More interestingly, If I kill the launch and the script and repeat everything from scratch (even turn off the arm and then turn it on), the arm does "NOT" move. It will work again only if I restart the computer!

Do you have any suggestion what would be the problem?

The jaco_arm.xacro (https://github.com/Kinovarobotics/jaco-ros/blob/master/jaco_model/urdf/jaco_arm.xacro#L139-L142) file does not specify the joint limits for joint 2 and 3.

I am trying to write nodes that consume the state of the mico arm. I know that some (all?) of the joints on the MICO are continuous. This wouldn't be a problem if they all wrapped between -PI and +PI, but I have noticed that joint 6 (index 5) appears to be wrapping between -1/2 PI and + 3/2 PI. Is this the desired behavior? If so, I have to write special cases anywhere J5 is used in my code.

It basically comes down to these lines in the arm driver:

    double j6o = jaco_comm_.robotType() == 2 ? 270.0 : 260.0;
    joint_state.position[0] = (180- jaco_angles.joint1) * (PI / 180);
    joint_state.position[1] = (jaco_angles.joint2 - j6o) * (PI / 180);
    joint_state.position[2] = (90-jaco_angles.joint3) * (PI / 180);
    joint_state.position[3] = (180-jaco_angles.joint4) * (PI / 180);
    joint_state.position[4] = (180-jaco_angles.joint5) * (PI / 180);
    joint_state.position[5] = (270-jaco_angles.joint6) * (PI / 180);

Where position[5] for some reason is offset by 270 degrees (1.5 PI), wheras the value wraps between -pi and +pi.