Ask Your Question
2

weird behaviour when loading controller in controller manager in gazebo

asked 2012-04-18 23:44:15 -0500

Kai Bublitz gravatar image

updated 2012-04-19 22:07:47 -0500

Hi, I have a strange problem again and I can't figure out what is going wrong.

I use the gazebo_ros_controller_manager plugin for controlling an arm and a pan/tilt unit in gazebo simulation. I use similar configuration parameters for both of them. I posted the yaml files at the end. Both configuration files are loaded to the parameter server, then I use the pr2_controller_manager spawner node to load the controllers. It works perfectly when I load the arm_controller, I can move the arm and everything. But when I try to load the pantilt_controller, the simulation gets freaky. All the robot parts that are attached with non-fixed joints are displayed somewhere in the centre of the gazebo area, the published joint states look like this:

header: 
  seq: 131001
  stamp: 
    secs: 1311
    nsecs: 61000000
  frame_id: ''
name: ['base_link_to_wheel_l_rim_joint', 'base_link_to_wheel_r_rim_joint', 'lenkrolle_base_to_lenkrolle_dreh_joint', 'lenkrolle_dreh_to_lenkrolle_rim_joint', 'kopf_base_to_kopf_pan_joint', 'kopf_pan_to_kopf_tilt_joint', 'arm_1_joint', 'arm_2_joint', 'arm_3_joint', 'arm_4_joint', 'arm_5_joint', 'arm_6_joint', 'arm_7_joint', 'gripper_base_to_finger_l', 'gripper_base_to_finger_r']
position: [31.415926535897945, 37.699111843077524, 9.42486522723199, 3.1416799200523933, -9.424716252608002, -9.424872208549377, -3.1415926535897913, -10.995570796905772, -1.5707998174534001, 7.853985124632986, 4.712385489726186, 1.5707998174534001, -1.5707998174533984, nan, nan]
velocity: [nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan]
effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, nan, nan]

All the position values should be close to 0, velocity too. The other joints are controlled by different controllers, they don't even use the pr2 controller_manager, except for publishing the joint states. I tried using the JointSplineTrajectoryController instead but with the same result. Same result if I don't start the arm controller.

I'm really lost. I have no idea what I am doing wrong. It used to work some time ago, but I haven't used the simulation for some time. I can't remember I changed anything since it worked. There are no error messages, the spawner just gives two info messages "Loaded controllers: pantilt_controller" and "Started controllers: pantilt_controller". Maybe it is just a simple but stupid mistake again, but I can't find it. Please help me solve this problem. Thanks.

The configuration files I use:

arm_configuration.yaml:

arm_controller:
  type: robot_mechanism_controllers/JointTrajectoryActionController
  joints:
    - arm_1_joint
    - arm_2_joint
    - arm_3_joint
    - arm_4_joint
    - arm_5_joint
    - arm_6_joint
    - arm_7_joint
  gains:
    arm_1_joint:
      p: 2000.0
      d: 0.0
      i: 100.0
    arm_2_joint:
      p: 2000.0
      d: 0.0
      i: 100.0      
    arm_3_joint: 
      p: 2000.0
      d: 0.0
      i: 100.0
    arm_4_joint:
      p: 2020.0
      d: 0.0
      i: 100.0
    arm_5_joint:
      p: 2030.0
      d: 0.0
      i: 100.0
    arm_6_joint:
      p: 5050.0
      d: 0.0
      i: 100.0
    arm_7_joint:
      p: 2080.0
      d: 0.0
      i: 100.0

  arm_joint_trajectory_action_node:
    joints:
      - arm_1_joint
      - arm_2_joint
      - arm_3_joint
      - arm_4_joint
      - arm_5_joint
      - arm_6_joint
      - arm_7_joint
    constraints:
      goal_time: 0.6
      arm_1_joint:
        goal: 0.05
      arm_2_joint:
        goal: 0.05
      arm_3_joint:
        goal: 0.05
      arm_4_joint:
        goal: 0.05
      arm_5_joint:
        goal: 0.05
      arm_6_joint:
        goal: 0.05
      arm_7_joint:
        goal: 0.05

Update 1: I found out that the problem is ... (more)

edit retag flag offensive close merge delete

Comments

1

Why do you use the d-term for the pan-tilt head and not for the arm? Could you try your simulation with setting the d-term for the "kopf" :-) to zero?

bit-pirate gravatar imagebit-pirate ( 2012-04-19 13:26:36 -0500 )edit

I have tried different settings for p,i,d. Setting d to zero alone does not change anything, but when I also set p and i to very small values (like 0.1) it works better. The robot does not "fly away" and kill the controllers but still acts strange. (I update the question)

Kai Bublitz gravatar imageKai Bublitz ( 2012-04-19 21:32:33 -0500 )edit

I am having an identical issue, have you come to a solution? Thanks

phil0stine gravatar imagephil0stine ( 2012-08-22 07:35:03 -0500 )edit

Unfortunately I was not able to find a solution. I think there is a problem with the urdf to gazebo converter, but I have no time to do further investigations. I will open another question on another issue I have with my model, perhaps this is somehow related.

Kai Bublitz gravatar imageKai Bublitz ( 2012-08-23 00:09:28 -0500 )edit

does it stabilize if all p,i,d are zeros?

hsu gravatar imagehsu ( 2012-08-23 07:26:28 -0500 )edit

Wow yes that does the trick, at least for me. I had even lowered the values, but obviously I have poor intuition as to what values are reasonable. Anything less than 1 is working well. Thanks!!! Of course, I am receptive to reasons I should have known better :)

phil0stine gravatar imagephil0stine ( 2012-08-23 11:33:53 -0500 )edit

with all p,i,d zero the movable parts keep their initial orientation no matter how I move the robot. Of course the controller doesn't do anything.

Kai Bublitz gravatar imageKai Bublitz ( 2012-08-27 00:02:47 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2012-08-28 13:35:59 -0500

hsu gravatar image

Hi Kai,

With regards to the bouncing problem when you hit the joint limit, you can try tweaking the fudgeFactor values for your joint:

<gazebo reference="r_upper_arm_roll_joint">
  <fudgeFactor value="0.5"/>
</gazebo>

You can take a look at the ode manual and search for terms dParamFudgeFactor to see exactly what it does. Quoting below:

  • The current joint stop/motor implementation has a small problem: when the joint is at one stop and the motor is set to move it away from the stop, too much force may be applied for one time step, causing a ``jumping'' motion. This fudge factor is used to scale this excess force. It should have a value between zero and one (the default value). If the jumping motion is too visible in a joint, the value can be reduced. Making this value too small can prevent the motor from being able to move the joint away from a stop.
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2012-04-18 23:44:15 -0500

Seen: 1,182 times

Last updated: Aug 28 '12