Problems using MoveBaseActionClient in Gazebo

[Wesley-Fisher]

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)

[martine1406]

Hi @Wesley-Fisher

When you say that your Gazebo physics settings are the same as in #29, what do you mean? Can you copy those settings?
¸What version of Gazebo are you running?
What is you fixed frame set to?

You said that it was working fine a few weeks ago. The kinova-movo/master has not changed in months (besides the documentation). So I doubt that this is something from the movo package.

Maybe you can try searching the specific error you get on the internet. e.g. of resources I could find:
https://answers.ros.org/question/10080/how-to-solve-tf_nan_input/
http://wiki.ros.org/tf/Errors%20explained

Thank you
Martine

[Wesley-Fisher]

I'm running Gazebo 2.2.6. My physics settings match the picture from #29, which is linked here. I'm not sure what the exact framerate is at the moment, but it can run at nearly real-time.

Thank you for the links you provided. I'll look into those and see if there are any solutions.

[martine1406]

I'm running the same Gazebo version and I do not have the same problem... strange. Let me know if you find a solution.

[martine1406]

Hi @Wesley-Fisher

I re-tested the same demo as you mentioned (movo_demos sim_demo.launch) on my remote pc, and both 6 dof and 7 dof arm configurations with kg3 gripper (in https://github.com/Kinovarobotics/kinova-movo/blob/devel/movo_common/movo_config/movo_config.bash) resulted in appropriate base planning. On my side, the real-time factor was really bad however... about 0.20...
I tested on a fresh devel branch pulled this morning.

I do not know why it fails on your side. What specific configuration are you trying to run (how is the movo_config.bash file configured)? Is this something that happens systematically on your side? This is an error that originally comes from tf publishing a wrong transform. The move_group node is not able to recover from this inappropriate transform...

Honestly, the ros knowledge we have internally are not enough to be able to really explain this issue and help you further.... I am very sorry about this situation.

Maybe you can try searching for the specific error you get on Gazebo forums. e.g. ignoring because of a nan value in the transform? I could not find a clear answer, but maybe you will.

The fix you have found is rather curious:

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 am unfortunately not able to explain why this would work.

Last but not least, I am launching a local ros master (roscore), then launch the demo in another terminal on my machine. Have you launched a local ros master when testing on yours? just to be sure....

sorry I am not able to help more

[Wesley-Fisher]

Hi @martine1406

Thanks for the reply, and sorry for my delay in responding.

The movo_config.bash file should have all the default values from the master branch.

Lately, the simulation has actually been working well for the most part. I can't track down any specific factor in why that has been happening. It sounds like it is not something in the movo models; I will try to look into other causes on my local machine.

In any case, thank you for trying to look into this further.

[martine1406]

awesome. yeah those issues can be confusing. At least, a lot of information is generally available online. Good luck with your digging of the root cause for this problem!