0
$\begingroup$

Rosanswers logo

Hi, I am currently on Ubuntu 16.04 LTS and ROS Kinetic, working on the integration of a Husky and a Robotis Manipulator-H in the Gazebo simulator. Right now I have the manipulator working with MoveIt! while standing fixed on top of a Husky robot. First of all I was having a problem which was the fact that when I moved the Husky robot (for example, with the teleop keyboard), his dynamics were not correct, i. .e, the front wheels would lift up when I moved him forward and the back wheels would also lift up If I moved him backwards. I researched about the possible reasons why this was happening and via this link:

http://answers.gazebosim.org/question/15045/why-my-model-seems-to-defy-the-gravity-and-seems-to-be-grabbed-from-the-top-when-moving/#18851

I found out that the fact that I was using a position_controllers/JointTrajectoryController to control the manipulator (via MoveIt!) was afecting my robot's dynamics. The solution was changing this controller to a effort_controllers/JointTrajectoryController, which made it possible to move my Husky robot around normally. The only problem is that now, the initial position of the manipulator is a bit odd. The following images show the normal position of the manipulator (when using a position_controllers/JointTrajectoryController) and the position of the manipulator when using a effort_controllers/JointTrajectoryController:

Normal position: image description

Altered position: image description

Besides this initial position problem, path planning has equally good (or even perfect) results when using both controller types. Has this weird initial position any side effect in my system/manipulator/simulation?

I posted this question in Github: https://github.com/znbrito/Brito-thesis-Robotis-Manipulator-H-path-planning/issues/3 And in Gazebo answers: http://answers.gazebosim.org/question/18873/manipulator-initial-position-altered-after-changing-from-a-position_controllersjointtrajectorycontroller-to-a/

Because I am not sure where exactly I should post my problem but from the feedback that I got till know, I think this has something to do with the PID controllers that I am using right now. What I did was simply using the PID parameters that came from the original package from Robotis's Github from other controller types:

robotis_manipulator_h:
  # Publish all joint states -----------------------------------
  joint_state_controller:
    type: joint_state_controller/JointStateController
    publish_rate: 125  
         
  # Position Controllers ---------------------------------------
  joint1_position:
    type: effort_controllers/JointPositionController
    joint: joint1
    pid: {p: 9000.0, i: 0.1, d: 500.0}

  joint2_position:
    type: effort_controllers/JointPositionController
    joint: joint2
    pid: {p: 9000.0, i: 0.1, d: 500.0}

  joint3_position:
    type: effort_controllers/JointPositionController
    joint: joint3
    pid: {p: 6000.0, i: 0.1, d: 400.0}

  joint4_position:
    type: effort_controllers/JointPositionController
    joint: joint4
    pid: {p: 6000.0, i: 0.1, d: 400.0}

  joint5_position:
    type: effort_controllers/JointPositionController
    joint: joint5
    pid: {p: 6000.0, i: 0.1, d: 400.0}

  joint6_position:
    type: effort_controllers/JointPositionController
    joint: joint6
    pid: {p: 6000.0, i: 0.1, d: 400.0}

And I added the controller for MoveIt! myself with these PID parameters:

robotis_manipulator_h:
  # Publish all joint states -----------------------------------
  joint_state_controller:
    type: joint_state_controller/JointStateController
    publish_rate: 125  

  # Controllers for MoveIt! ------------------------------------
  main_group_controller:
    type: effort_controllers/JointTrajectoryController
    joints:
      - joint1
      - joint2
      - joint3
      - joint4
      - joint5
      - joint6
    gains: 
      joint1: {p: 9000.0, i: 0.1, d: 500.0}
      joint2: {p: 9000.0, i: 0.1, d: 500.0}
      joint3: {p: 6000.0, i: 0.1, d: 400.0}
      joint4: {p: 6000.0, i: 0.1, d: 400.0}
      joint5: {p: 6000.0, i: 0.1, d: 400.0}
      joint6: {p: 6000.0, i: 0.1, d: 400.0}
   
      
  # Position Controllers ---------------------------------------
  joint1_position:
    type: effort_controllers/JointPositionController
    joint: joint1
    pid: {p: 9000.0, i: 0.1, d: 500.0}

  joint2_position:
    type: effort_controllers/JointPositionController
    joint: joint2
    pid: {p: 9000.0, i: 0.1, d: 500.0}

  joint3_position:
    type: effort_controllers/JointPositionController
    joint: joint3
    pid: {p: 6000.0, i: 0.1, d: 400.0}

  joint4_position:
    type: effort_controllers/JointPositionController
    joint: joint4
    pid: {p: 6000.0, i: 0.1, d: 400.0}

  joint5_position:
    type: effort_controllers/JointPositionController
    joint: joint5
    pid: {p: 6000.0, i: 0.1, d: 400.0}

  joint6_position:
    type: effort_controllers/JointPositionController
    joint: joint6
    pid: {p: 6000.0, i: 0.1, d: 400.0}

So:

  1. Is this weird position a problem?
  2. Can I use the same PID parameters to more than one different controller, even though I now that MoveIt! is now performing path planning with no errors?

Thanks in advance!


Originally posted by znbrito on ROS Answers with karma: 95 on 2018-04-06

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Changing from position_controller to effort_controller is no longer sending joint position commands, but effort commands. This implies that each actuator uses up to the max_effort set in the URDF, as well as the PID gains in order to minimize the error between the current joint position and the commanded joint position. Because of this, the joints are not always able to perfectly control the joint position bent commanded. This is what is shown in the second image you provided, and is more realistic.


Originally posted by JoshMarino with karma: 592 on 2018-04-06

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by znbrito on 2018-04-07:
THanks for the reply! Hmm so how do you justify that MoveIt! can move the manipulator with no error to any position I want with this PID gains? Cause I am simply using the gains that came from the original package also...

Comment by znbrito on 2018-04-07:
And this gains where for effort_controllers/JointTrajectoryController and this time they are for effort_controllers/JointPositionController so the effort_controllers type is the same... can this mean that the gains that came from the original package weren't well tuned?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.