kinovarobotics / kinova-movo Goto Github PK

The fingers must be closed before issuing the arms homing commands (with button #8 on the USB joystick), otherwise they could hit something on the homing path.

When running on a remote machine, the Kinect 2 framerate is something like 1hz. This is not even the point cloud, but the framerate I get when running rostopic hz on one of the image topics. When I run the same command on the movo2 machine, I get 30hz, which is more like I expect.

We see an improvement when running on the wired network (something like 15 hz), but I expect the wireless framerate to be somewhat similar. Has anyone else experienced this problem? Are there suggested fixes?

The arms must not be laying on the ground or in contact with a rigid surface when the MOVO is powered up. As part of the start-up process, the fingers open and could be damaged if they are in contact with a rigid surface.

Under f7c370f,
there are 2 movo_network_config.bash files in here and here.

Should not we remove one of those ?

When using a MoveBaseActionClient at the start of a simulation, the top of the Movo robot model disappears, and its transformations take on nan values.

This is happening when I run movo_demos sim_demo.launch, when it gets to the point of moving the movo base. A few weeks ago it was working fine, and I do not know what has changed (I have re-pulled from github and re-built the workspace to ensure there are no local changes).

I can also cause this to happen by spawning the movo in an empty world, and running a script that creates a MoveBaseActionClient, and sends a command to move to (1, 0, 0). This is done with a similar launch process as the sim_demo, but modified to use the empty_world (navigation is currently set to use a map).

I was looking at #29, and found that if I send a quick /movo/cmd_vel command at the start of the simulation, followed by a zero-velocity command, I can then run the script mentioned above with no problems.

I have tested spawning the movo slightly in the air, with the same results.

I'm running 14.04/Indigo, and running off of kinova-movo/master (and have tried the devel branch). My Gazebo physics settings are the same as in #29

The following is some of the errors messages that appear when roslaunching sim_demo:

[INFO] [WallTime: 1531965891.398466] [44.029000] Moving to table...
target_pose: 
  header: 
    seq: 0
    stamp: 
      secs: 44
      nsecs:  29000000
    frame_id: odom
  pose: 
    position: 
      x: 0.882549476624
      y: 0.00389907136559
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
[INFO] [WallTime: 1531965891.435477] [44.057000] Received a new goal
[INFO] [WallTime: 1531965891.436118] [44.058000] Going to (X,Y): (0.883,0.004)
[ERROR] [1531965891.795702953, 44.287000000]: Ignoring transform for child_frame_id "linear_actuator_link" from authority "unknown_publisher" because of a nan value in the transform (-nan -nan -nan) (0.000000 0.000000 0.000000 1.000000)
[ERROR] [1531965891.795721746, 44.287000000]: Ignoring transform for child_frame_id "linear_actuator_link" from authority "unknown_publisher" because of a nan value in the transform (-nan -nan -nan) (0.000000 0.000000 0.000000 1.000000)
[ERROR] [1531965891.795784383, 44.287000000]: Ignoring transform for child_frame_id "mid_body_link" from authority "unknown_publisher" because of a nan value in the transform (-nan -nan -nan) (0.000000 0.000000 0.000000 1.000000)
[ERROR] [1531965891.796210994, 44.287000000]: Ignoring transform for child_frame_id "mid_body_link" from authority "unknown_publisher" because of a nan value in the transform (-nan -nan -nan) (0.000000 0.000000 0.000000 1.000000)
[ERROR] [1531965891.796011359, 44.287000000]: Ignoring transform for child_frame_id "linear_actuator_link" from authority "unknown_publisher" because of a nan value in the transform (-nan -nan -nan) (0.000000 0.000000 0.000000 1.000000)
[ERROR] [1531965891.796339136, 44.287000000]: Ignoring transform for child_frame_id "mid_body_link" from authority "unknown_publisher" because of a nan value in the transform (-nan -nan -nan) (0.000000 0.000000 0.000000 1.000000)

Hi,

Is there a plan to add support for Google Cartographer? I have heard it's better than gmapper but have no direct experience either way.

https://github.com/googlecartographer/cartographer

Hello,

I am trying to upgrade our movo to kinetic. We first upgraded our system to 16.04, and then upgraded to kinetic. At first our movo_ws had issues building, but we were eventually able to resolve all the issues and get a fully-built movo_ws. However, even though we now have a built movo_ws, when we restart the movo, there is no ros master being launched, and it does not move at all on start up.

We also apt-get upgraded everything, but that still has not resolved the issue. Is there something we're missing in the upgrade process? How do we get the movo to launch the master ros node at launch so that we can actually use the movo?

Thanks!

In movo_jtas.py, the actionlib.SimpleActionServer (e.g. for the arm control) may sometimes abort goals. Currently, it does not populate the 'error_string' field. It would be helpful if this field was popultated to explain why the goal was aborted (e.g. see line 488 in movo_jtas.py)

Hi Kinova,

Following on from the discussion at https://github.com/orgs/Kinovarobotics/teams/movo-beta-program/discussions/15 I'm trying to implement a joint space velocity controller for our MOVO robot. In doing this I have been referencing the following files as a guide;

• kinova_api_wrapper.py
• jaco_joint_controller.py
• movo_jtas.py
• movo_arm_ctl
• movo_manipulation.launch

I have created a python ROS node that tries to instantiate a KinovaAPI object. Unfortunately, I get an error every time I try and construct this object.

movo@MOVO1:~$ rosrun popcorn_planning velocity_listener.py
[INFO] [WallTime: 1519619767.200056] Init API with arm=right, interface=eth0, robotIpAddress=10.66.171.15, localCmdport=25000, localBcastPort=25000, robotPort=55000
[ERROR] [WallTime: 1519619767.201531] Init API result:   1010
[ERROR] [WallTime: 1519619767.201661] GetDevices result: 2101
[ERROR] [WallTime: 1519619767.201748] Number of arms:    0
[ERROR] [WallTime: 1519619767.201828] Initialization failed, could not find Kinova devices                           (see Kinova.API.CommLayerUbuntu.h for details)
Segmentation fault (core dumped)

The error message refers to see Kinova.API.CommLayerUbuntu.h but this file is a header for a precompiled lib, so doesn't help me at all. It seems that the internal API construction (specifically line 211) is indicating that there are no arms attached.

• Is the Kinova API object designed to be singleton? I.e. if there is already one of these objects, should I be able to create another one?
• Our lab's development repo for the MOVO is private, but I have uploaded the source code for the relevant node to a Gist that you should be able to see. Could you have a look and see if I am constructing the KinovaAPI object correctly? As you can see above, I'm using the paremters "arm=right, interface=eth0, robotIpAddress=10.66.171.15, localCmdport=25000, localBcastPort=25000, robotPort=55000".

Thank you for your assistance.

Hi,

What is the preferred way to connect movo to the internet? Since movo2 acts as a dhcp server, it's nontrivial. I worked around it by plugging a USB/ethernet adaptor directly into movo2 (since our cover is off), and doing it that way. This only worked for movo2 of course, and not movo1. I was planning to configure movo2 to act as a gateway to movo1, so movo1 has internet as well.

The purpose of internet access is two-fold: 1) we'd like to be able to run ntpdate or the like on both movo1 and movo2 at each boot to ensure all our machines are using the same clocks. 2) we'd like to be able to install updates on movo1 and movo2.

So a related question is, is it okay to apt-get update apt-get upgrade movo1 and movo2? Have you tested this? I'd like to make sure we are current on security updates etc.

Thank you!

Stefanie

Hello, we are curious about the intention between the devel, master, and other branches of this repository. Could the maintainers of this repo clarify in the README or in this issue?

Using the /movo/cmd_vel topic to send linear velocities to the gazebo sim causes the simulated movo to rotate around its its axis rather than translating to a linear movement. sending an angular velocity along its z axis works properly but the linear x and y cause the movo to rotate and "fly" rather than move linearly.

Hello, I hope you are well. I was wondering if we could get any assistance with the error that we keep getting when we try to follow the manual setup instructions for movo. We have confirmed that PCL has been installed properly and we are currently stuck at this stage when we run catkin_make. Thank you!

Jonathan

[100%] Built target simple_grasping
Linking CXX executable /home/sagadre/movo_ws/devel/lib/simple_grasping/grasp_planner_node
Linking CXX executable /home/sagadre/movo_ws/devel/lib/simple_grasping/basic_grasping_perception
/home/sagadre/movo_ws/devel/lib/libsimple_grasping.so: undefined reference to pcl::search::KdTree<pcl::PointXYZRGB>::KdTree(bool)' collect2: error: ld returned 1 exit status make[2]: *** [/home/sagadre/movo_ws/devel/lib/simple_grasping/grasp_planner_node] Error 1 make[1]: *** [kinova-movo/movo_common/movo_third_party/simple_grasping/CMakeFiles/grasp_planner_node.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... /home/sagadre/movo_ws/devel/lib/libsimple_grasping.so: undefined reference to pcl::search::KdTreepcl::PointXYZRGB::KdTree(bool)'
collect2: error: ld returned 1 exit status
make[2]: *** [/home/sagadre/movo_ws/devel/lib/simple_grasping/basic_grasping_perception] Error 1
make[1]: *** [kinova-movo/movo_common/movo_third_party/simple_grasping/CMakeFiles/basic_grasping_perception.dir/all] Error 2
make: *** [all] Error 2
Invoking "make -j8 -l8" failed

Hi,

So we're currently trying to read the Jaco arms' end-effectors velocities (both linear x,y and z and angular as x, y, z as well). We noticed that in the kinova-ros package, there is a custom message type called PoseVelocity which has exactly the fields we need. The documentation for kinova-ros mentions a way to send PoseVelocity message commands to Movo, but we're wondering if there is some way to read the PoseVelocity of the end effectors? Is there a topic, service, launch file, or anything we can use to constantly read and publish the PoseVelocity of the Jaco arms onto some topic?

Thanks!

Hi All:

In this line,
should not it be movo_move_base, instead of move_base?

self.move_base_client = actionlib.SimpleActionClient("/movo_move_base", MoveBaseAction)

Using movo_base there and launching demo_extra.launch, we got:

[ERROR] [WallTime: 1516248125.612894] [326.658000] Could not connect to action server
Traceback (most recent call last):
  File "/home/tor/catkin-ws/src/kinova-movo/movo_simulation/movo_gazebo_demo/scripts/demo.py", line 360, in <module>
    move_base = MoveBaseActionClient(sim=True)
  File "/home/tor/catkin-ws/src/kinova-movo/movo_common/movo_ros/src/movo_action_clients/move_base_action_client.py", line 76, in __init__
    self._shutdown()
AttributeError: 'MoveBaseActionClient' object has no attribute '_shutdown'

What do you think?

Thank you,
tor

PS: this is using:
kinova-movo-master: Latest commit 8936d75
Indigo, trusty

Im using ubuntu 16.04 to work on a project using kinova arms. and after cloning all the files, when i catkin_make it, it show error like this. And i already adding add_compile_options(-std=c++11) in every cmakelist.txt in kinova folder. And here is my error screenshot.

Could anyone help me with this issue please! Really appreciate your help!

Hello,

I am currently trying to control the right arm on the MOVO (6dof jaco arms) through moveit and I am running into a MoveIt error where there is no end effector to set the pose. I looked into the moveit API to find that this error is thrown when there is no end effector link for moveit to command. I was wondering if you knew of a solution to move the arm to a goal end effector pose. Thank you!

Jonathan

Hello,

Last week, we found that the charger of our Movo was broken, so we have replaced the power block with a new one since then. We are, however, not sure if this will solve our problem. We were wondering if you could direct us through some troubleshooting steps. Currently the robot is completely discharged and it is hard for us to gauge whether our solution is properly working.

Jonathan

Steps to Reproduce:

1. roslaunch movo_demos sim_demo_show_basic.launch
2. rosrun movo_demos demo_show_basic.py

Result:

Traceback (most recent call last):
  File "/home/iumay/movo_ws/src/kinova-movo/movo_demos/scripts/demo_show_basic.py", line 67, in <module>
    movo_base = MoveBaseActionClient(sim=True, frame="map")
  File "/home/iumay/movo_ws/src/kinova-movo/movo_common/movo_ros/src/movo_action_clients/move_base_action_client.py", line 58, in __init__
    self.last_pose = self._helpers.GetCurrentRobotPose(frame)
  File "/home/iumay/movo_ws/src/kinova-movo/movo_common/movo_ros/src/movo_action_clients/helpers.py", line 101, in GetCurrentRobotPose
    self.tfl.waitForTransform(frame, "base_link", rospy.Time().now, rospy.Duration(1.0))
  File "/opt/ros/indigo/lib/python2.7/dist-packages/tf/listener.py", line 74, in waitForTransform
    can_transform, error_msg = self._buffer.can_transform(strip_leading_slash(target_frame), strip_leading_slash(source_frame), time, timeout, return_debug_tuple=True)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/tf2_ros/buffer.py", line 122, in can_transform
    not self.can_transform_core(target_frame, source_frame, time)[0] and
TypeError: time must have a to_sec method, e.g. rospy.Time or rospy.Duration
Exception AttributeError: "'MoveBaseActionClient' object has no attribute 'move_base_client'" in <bound method MoveBaseActionClient.__del__ of <movo_action_clients.move_base_action_client.MoveBaseActionClient object at 0x7f7816966450>> ignored

Should movo_jtas.py be renamed to movo_arm_jtas.py?
If so, this will provide naming consistency with other files under movo_jtas dir.

If the arm bases are unpingable during startup, ROS fails to launch. Ideally, setting MOVO_HAS_KINOVA_ARMS and related environment variables to false in movo_config.bash would skip the startup ping.

Hello Kinova,

At UQ we find ourselves in need of a way to command angular velocities on the MOVO robot arms. We are able to do this in some tests (e.g. see discussion at this post), however this requires killing the Kinova arm control nodes, which contain lots of useful safety-relevant code. Below I will outline a proposal to update this repository to natively support angular velocity control of the arms via a ROS interface.

I am happy to do the bulk of the work outlined below. I am seeking input from Kinova to steer the development work in an appropriate direction to get it merged as a pull request down the track, if appropriate.

Hi All:

I launched demo.launch and got:

[INFO] [WallTime: 1516239457.135306] [2.303000] Could not get transform from /map->base_link
[ERROR] [WallTime: 1516239457.135624] [2.303000] Could not get initial pose!!!! exiting....

My workaround is to set directly the global_frame from map to odom in map_nav.launch.
Is it the right solution? or ?

Thank you,
tor

PS: this is using:
kinova-movo-master: Latest commit 8936d75
Indigo, trusty

Due to lines like
<property name="shoulder_pan_joint_rpy" value="0 ${M_PI} 0" />

Full message:

deprecated: xacro tags should be prepended with 'xacro' xml namespace.
Use the following script to fix incorrect usage:
        find . -iname "*.xacro" | xargs sed -i 's#<\([/]\?\)\(if\|unless\|include\|arg\|property\|macro\|insert_block\)#<\1xacro:\2#g'
when processing file: /data/movo_description/urdf/manipulation/jaco/jaco_7dof.urdf.xacro
included from: movo_description/urdf/movo.urdf.xacro

We have a Movo with two 7-DOF arms and KG3 grippers. We've removed one of the arms to be used separately, and now the Movo won't launch all of its ROS components. We changed the movo_config file to make sure it knows it only has one (right) arm and one (right) KG3 gripper and ran make clean/make on both computers, but that doesn't seem to have helped.

Any input and/or solutions would be welcomed. Any else have this issue and solve it already?

Hi Kinova,

After updating to the v1.1.0 release, I'm no longer able to use the active arm teleoperation mode via the joystick. I checked and can confirm the cartesian velocities are being sent using e.g. movo@MOVO2:~$ rostopic echo /movo/right_arm/cartesian_vel_cmd, it seems that the KinovaAPI object isn't responding to calls to the send_cartesian_vel_cmd() method.

Are you able to try replicating this at your end?

Hi there,

recently, i am testing motion planning for both arms on movo and encountered the following problem.

the movo is supposed to move its left arm and right arm to a predefined joint configuration. the right arm moves along its planned path perfectly but the left arm suffered from executing the intended path, i recorded a video for your reference
https://www.youtube.com/watch?v=E0THA4qcHKA

in the video, movo first tried to move its left arm to a joint configuration which is a mirror configuration to the right arm. However, in the process of executing the planned path, the left arm got stuck. The warning signal from Moveit reports the error code "PATH_TOLERANCE_VIOLATED", which means the motion of the arm was deviated from the intended path by certain amount.

From my observation, I think the problem lies on the shoulder_lift joint of the left arm. as you can see, when the left arm is almost in full extension configuration, the should_lift joint is shaking, indicating it could not exert enough torque to execute the motion. meanwhile other joints were moving as planned and the should lift joint was left behind, which resulted in the error code "PATH_TOLERANCE_VIOLATED".

I also noticed the shoulder lift joint is warmer than the other joints, which may confirm my guess that the shoulder lift joint is not function properly.

may I seek for your help to resolve this issue?

Dear everybody:

I would like to use force control/adimittance control with 7-dof jaco arm equipped on MOVO. However when I look at the topics offered by movo1 or movo2, there are no such interfaces for me. It seems that the two arms could only be contolled by using Moveit! using position or velocity control on both joints and end-effector. Are there any methods that I could use force control or get the force feedbacks from the two arms?

I have tried to connect my computer directly to the jaco arm using USB and pull out the ethernet plug. The demo admittance control program works fine. I also tried to run the program directly on either movo1 or movo2. However the arm initialization failed. It seems that the arms are occupied by other program which offeres arm control for ROS.

So I was wondering that are there any methods that I could implement the arm force control on MOVO?

Best wishes!

Qing

Hi,

I am able to open and close the grippers via the SimpleActionClient. However this only gives access to a single number to control the finger position. While it's nice to have that API, I was wondering if there was in addition an API to control each fingers individually? I see the finger joint state topic, but was wondering if there was a topic to set each finger joint position and/or velocity individually? For example, I want to be able to make a "V" for victory sign, or a one-finger pointing gesture, or strum a ukulele.

Sorry if I missed it in the docs... I ran rostopic list | grep gripper and looked at all the topics and didn't see any way to set individual finger positions. I was able to do this with the jaco api before...

Thanks.

Hi,

Is there a way to access zero G mode for the Jaco arms on Movo? I recall seeing something about this in the Jaco API docs, but I don't see anything in the Movo Repo. I'd like to put the arms in a mode where they compensate for their own weight, but allow a person to physically drive them into different configurations.

Thanks!

Stefanie

Launching sim_demo.launch as suggested for running simulation in #6, we got:

tor@movodev:~$ roslaunch movo_demos sim_demo.launch
...
[/home/tor/catkin-ws/src/kinova-movo/movo_demos/launch/demo/demo.launch] requires the 'is_sim' arg to be set
The traceback for the exception was written to the log file
[demo_bringup-6] process has died [pid 3176, exit code 1, cmd /home/tor/catkin-ws/src/kinova-movo/movo_common/si_utils/scripts/timed_roslaunch 35 movo_demos demo.launch sim:=true local:=true __name:=demo_bringup __log:=/home/tor/.ros/log/f8a3c91a-ffeb-11e7-9ad9-b8ca3ab91193/demo_bringup-6.log].
log file: /home/tor/.ros/log/f8a3c91a-ffeb-11e7-9ad9-b8ca3ab91193/demo_bringup-6*.log
...
[ERROR] [1516677519.458088619, 5.303000000]: "front_laser_link" passed to lookupTransform argument source_frame does not exist. 
[ERROR] [1516677520.585542905, 6.304000000]: "rear_laser_link" passed to lookupTransform argument source_frame does not exist.
...
[ERROR] [WallTime: 1516677620.982949] [100.993000] Timed out waiting for Gripper Command Action Server to connect. Start the action server before running example.
[WARN] [WallTime: 1516677621.140778] [101.138000] Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received. Please check sender for additional details.
[init_sim_inplace-1] process has died [pid 4055, exit code 1, cmd /home/tor/catkin-ws/src/kinova-movo/movo_simulation/movo_gazebo/scripts/init_sim_inplace __name:=init_sim_inplace __log:=/home/tor/.ros/log/f8a3c91a-ffeb-11e7-9ad9-b8ca3ab91193/init_sim_inplace-1.log].
log file: /home/tor/.ros/log/f8a3c91a-ffeb-11e7-9ad9-b8ca3ab91193/init_sim_inplace-1*.log
...

And

tor@movodev:~$ roswtf
...
WARNING The following nodes are unexpectedly connected:
 * /robot_state_publisher->/init_sim_inplace (/tf)
 * /movo_marker_ctrl->/init_sim_inplace (/tf)
 * /movo_marker_ctrl->/rviz (/movo_marker_ctrl/update_full)
 * /move_group->/init_sim_inplace (/move_group/result)
 * /move_group->/init_sim_inplace (/move_group/feedback)

WARNING These nodes have died:
 * demo_bringup-6
 * init_sim_bringup-5
 * spawn_gazebo_model-4
 * default_controller_spawner-5
...

And it seems we are missing many TFs:

tor@movodev:~$ rosrun tf tf_monitor
RESULTS: for all Frames
Frames:
Frame: base_link published by unknown_publisher Average Delay: 0.0215 Max Delay: 0.037
All Broadcasters:
Node: unknown_publisher 150 Hz, Average Delay: 0.0215 Max Delay: 0.03

Possible fixes include:

• fix is_sim in this line
• add sim arg in demo.launch

<!-- Navigation configuration -->
<include file="$(find movo_demos)/launch/nav/sensor_nav.launch">
    <arg name="local" value="$(arg local)"/>
    <arg name="sim" value="$(arg sim)"/>
</include>

Note: using f7c370f on Indigo, trusty

When updating the kinova-movo code on our MOVO robot, the file movo_config.bash gets overridden. This lead to the environment variables MOVO_HAS_KINOVA_ARM_7DOF and MOVO_HAS_KINOVA_ARM_6DOF being reset, and caused us some confusion (arm controllers wouldn't work) until we figured out the issue and amended it.

I'm not sure what the solution here is - maybe this file should be .gitignored?

We blew another fuse. We confirmed that it happened when the arm was impeded from moving to its target destination. So probably some kind of over current or something. Can you suggest a fix? it's annoying to change the fuse every time.

Thanks!

To install new packages on the MOVO PC's the current suggested solution (e.g. see wiki page here or discussion here is to connect movo1 and movo2 to an organisational network with internet access so that sudo apt-get install <pkg> can work.

For movo2 this is fairly straightforward as the HMI panel ethernet port can be used, however for movo1 this requires removing the skin. This is not desirable, especially as e.g. on our robot, the thread of the screws holding the skin are stripped, making it very hard to get the skin on/off.

For the 1.1.0 release, I found a way to do this without connecting the movo PC's to the internet (see here). However this is a slow manual process and prone to error.

I'd like to propose that a better solution would be if instructions could be provided so that the aptitude repository for Ubuntu 14 could be hosted either on a movo development PC, or on a flash drive that could be connected to the HMI port (e.g. see instructions here on hosting aptitude repos on a flash drive).

Potential drawbacks of this approach;

• It doesn't provide a way to run rosdep update commands. Does this matter?

I'd love to hear any other thoughts about a better way to update movo1, movo2 packages without removing the skin.

Hi All:

In my case, the node spawner of pkg="controller_manager" launched in movo.launch always fails to spawn the controllers.

Any clue for why the spawner fails?
What if using a node controller_manager as below? Any drawback?

My workaround is:

    <node name="controller_spawner" pkg="controller_manager" type="controller_manager"
        args="  spawn
                movo/right_arm_controller
                movo/right_gripper_controller
                movo/left_arm_controller
                movo/left_gripper_controller
                movo/torso_controller
                movo/head_controller
                joint_state_controller"/>

Thank you,
tor

PS: this is using:
kinova-movo-master: Latest commit 8936d75
Indigo, trusty

I'm trying to follow the instructions here: https://github.com/Kinovarobotics/kinova-movo/wiki/How-Tos#creating-a-map-with-real-robot

And in particular this instruction: "Launch navigation: o roslaunch movo_navigation_apps gmapping.launch."

However I can't find gmapping.launch in kinova-movo. I also searched for this file on the movo1, movo2, and Google, and can't find it.

Hi Kinova,

I was having a look inside the top of our MOVO today (front 'head' skin panel removed) and noticed that the Kinect power cable has some serious mechanical wear. See below.

You can't see it in the above photo, but the Kinect cable is actually worn through to the point where the internal metal sheath is visible.

I believe this rubbing is happening when the MOVO torso linear actuator is used, but we've hardly used this actuator, so I'm not sure if it was exercised lots before shipping to us?

Hi,

I hope you are well. I am currently trying to implement the Zero G mode described in issue #34, and I have a few questions.

The first step that was mentioned was to set the gravity vector in the correct orientation using SetGravityVector. I have located this function; however, what should the arguments to this function be for the correct orientation? Moreover for the wrapper, currently I am planning on adding to the movo_joint_interface/kinova_api_wrapper.py by creating a self.setGravityVector =self.kinova.Ethernet_SetGravityVector but what would have to go into the setGravityVector.argtypes?

The second step that was mentioned was to activate the Reactive force control mode by calling SetForceControl; however, I did not find this function. The closest functions I found were StartForceContorl and StopForceControl. How would I go about completing this step of the process?

Finally, where in the pipeline of the system would a script that calls these functions belong? More specifically, after updating the wrapper to include the necessary functions, could I just run a script that calls these functions to activate zero g mode?

Thank you very much for your help!

Best,
Jonathan

We have only recently started to use a Movo and have been having any problems with the Kinect2. Kinova does a calibration before shipping but we're getting substantial errors. Before undertaking random acts of calibration, we wanted to see if someone can report that they get good behavior. That way we could rule out other sources for the problems.

If you look at the attached images you see one of the arms (with a Robotiq gripper) holding a ruler up to a block. You can see in the photograph that the left edge of the "actual" finger is aligned with the left edge of the ruler and the right edge of the block. In the Rviz picture you can see that the “simulated” finger is almost at the right edge of the ruler. It's also off in the approach distance but that's harder to judge from the picture.

The Rviz picture is showing the topic /kinect2/sd/points and the robot model. It’s being displayed relative to the robot base frame. So, this should simply be showing the Kinect point cloud and the robot model placed at whatever angles are being read as the current position.

As far as I understand it (but I may be missing something), this relatively large offset can only come from the following sources:

• The encoders are reporting (very) incorrect joint angles
• The actual geometry of this robot does not match the geometry in the URDF
• The kinect is (very) uncalibrated

Is your Kinect data reasonably aligned with the world? Note that I don't mind noise - 2 cm systematic offsets are another thing. Any suggestions?

Thanks,
Tomas Lozano-Perez

Is it okay to run apt-get update/apt-get upgrade on the movo? If I run that on movo1/movo2 to get the security updates (and generally, keep running it), will it break anything?

Hi, we are trying to remove one of the Jaco arms from the Movo platform. I followed the instructions on this page: https://kinovarobotics.github.io/kinova-movo/Tasks/t_kinova_arms_uninstall.html ; however, when I get to step 3, the robot arm does not budge. I was feeling around to see how the arm was still attached, and felt a screw on the underside of the base. Is it possible for the arm to be screwed in from UNDER the base, and not just on the top like step 2 indicates? If this is the case, it would seem like we'd have to disassemble most of the robot to get access to this screw. I thought it was worth checking here before doing anything close to that drastic. Any help would be much appreciated, thanks!

The kinova-movo repo contains some files in directories that differ only in capitalisation. This causes issues when using the git repo from an NTFS filesystem, which doesn't care about filename capitalisation.

In particular, the files in the folder https://github.com/Kinovarobotics/kinova-movo/tree/master/movo_common/movo_description/meshes/sensors/collision are a problem for me.

Would you be able to rename one of these files to a different name?

Thank you,

I am trying to send moveit commands from C++. I was working from the Python initialization code (to move to home and move to tuck) and basically did a C++ version of that with the MoveGroup class, but the arm would not move.

To try to debug it, I looked for the moveit log files on movo2, but they weren't in any obvious places. Where are they?

After failing to find the log file, I decided to try starting moveit myself so I could see what happened when I was sending the C++ service calls and if there were any errors in the log. I ran the following command:
roslaunch movo_7dof_moveit_config movo_moveit_planning_execution.launch debug:=true

Which I believe kills the moveit process that is started during bootup, then restarts it. Everything starts fine, it says "All is well! Everyone is happy! You can start planning now!", and my C++ code starts magically working. Something is clearly different between when moveit starts from boot, and when I launch it.

Here is my extracted code, which works just fine when I launch moveit myself from movo2, but does not work after a clean boot. And note that the boot itself successfully moves the arms to home, then tuck, using the Python init script.

upperBody = new MoveGroup("upper_body");
upperBody->setPlannerId("RRTConnectkConfigDefault");

for (int i = 0; i < MC->homedJoints.size(); i++) {
bool result = MC->upperBody->setJointValueTarget(MC->upperBodyJoints[i], MC->homedJoints[i]);
if (!result) {
CONSOLE_ERROR(ms, "Invalid joint target: " << MC->upperBodyJoints[i] << " value: " << MC->homedJoints[i]);
return;
}
}
MoveItErrorCode r = MC->upperBody->asyncMove();
if (r.val != moveit_msgs::MoveItErrorCodes::SUCCESS) {
CONSOLE_ERROR(ms, "Couldn't execute. Code: " << r.val);
}

hi there,

i have a question about cartesian control of the arm via joystick.
As stated in the manual, i activate cartesian control mode of left arm by pressing #12 on the joystick (lean direction to control motion in x-y and joystick rotation to control vertical motion in z)

i suppose while the arm is moved in cartesian mode, the orientation of the end-effortor should not change, however i observed that its orientation is keeping changing.

I took a video for your reference.
https://www.youtube.com/watch?v=8-3YkLoaXhM

in this video, when i move the arm in x direction, the orientation of the end effector is kept constant. but when i move the arm in z direction, the orientation cannot be kept. also when i move the arm in y direction, the orientation changes a bit.

wondering if there is some problem with the cartesian velocity controller? or it is supposed to behave like such?

note: the x,y,z direction mentioned above is with respect to the base_link frame

===============================================================

I also wrote a cartesian position controller myself based on two rostopics below
/movo/left_arm/cartesian_vel_cmd
/movo/right_arm/cartesian_vel_cmd

the package is available below
https://github.com/ljklonepiece/movo_cartesian_server

my cartesian controller encountered the same issue as in the case of joystick control

Any ideas to improve the controller are much appreciated!

Hey everyone,

I'm currently having some issues with getting gmapper to work correctly with the movo. I've been able to create a map of our lab space and launch a visualization of the map and the movo in it for RViz. The issue is that when I try to send the Movo to a new spot by setting a navigation pose, the local cost map gets populated with all of these fake "obstacles", and it makes the movo move in a random direction that isn't towards the goal pose. I've done some debugging, and it seems like the /move_base/EBandPlannerROS/global_plan contains invalid floating point values. When I echo out this topic, I can see that the path plan does indeed contain nan values. Does anyone have any thoughts as to why this might be happening?

I'm not sure if this is directly related, but we also noticed that when we try to ping out front_laser, we get no responses. However, in RViz we can see the lase scans visually, and they seem right, so somehow Rviz is receiving those values.

Description

the urdf description for the movo contains a reference to a link that does not exist

Version

kinetic-devel (but looks the same on master branch)

Steps to reproduce

1. launch the gazebo simulator, something like movo_gazebo movo_test_zone.launch
2. try and find the camera topics

Code example

line 88 in kinect_one_sensor.urdf.xacro

<gazebo reference="${prefix}_ir_link">

Expected behavior

load the sensor and camera plugin

Any other information

there are no other references to ${prefix}_ir_link in the robot description so gazebo will not load the sensor and camera plugin

replaced with:
<gazebo reference="${prefix}_ir_frame">
which is a valid reference and the camera plugin loads correctly.

If the e-stop button is pushed in when the Movo is powered up, the WiFi connection isn't launched. It would be useful to have access to the computers while e-stopped.

Description

Hi All, the Kinova team created a migration procedure for Movo. Here it is attached to this issue. If you have any questions, please publish an issue or directly contact [email protected]
Official migration of Indigo to Kinetic (1).pdf

Expected behaviour: When the move_base_action_client.py class exits due to an error (e.g. could not reach Action Server during initialisation, it should do so cleanly.

Observed behaviour: The move_base_action_client.py references a method self._shutdown() in several locations, but that method isn't defined. This causes an exception under some circumstances when using this class.

Steps to replicate: Try instatiating move_base_action_client.py somewhere that can't see the Action server (e.g. on MOVO1).