znbrito's profile - activity

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...

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:

Altered position:

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-thes... And in Gazebo answers: http://answers.gazebosim.org/question...

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 ...

Hi,

I am on Ubuntu 16.04 LTS and ROS Kinetic. I am now working with the manipulator Robotis Manipulator-H standing on top of a Husky robot and I intend to do path planning with the manipulator using MoveIt! so that I can take in account the restrictions from my environment. I am just simulating my system in Gazebo. Right now I am using the laser Hokuyo UST-10LX integrated with the "occupancy_map_monitor/PointCloudOctoMapUpdater" MoveIt! plugin to map my environment and make MoveIt! aware of it in order to correctly perform path planning to my desired goals poses. In the following image you can see the octomap of the tree that I am mapping right now, after I move Husky in order to map her (the laser is the grey thing, right now I don't really care how it looks):

My goal points are already known and some of them are inside the obstacles that I identify (map) with the laser. In order to plan to those poses I am currently updating my AllowedCollisionMatrix with a small cube centered (with millimiter dimentions) in my goal position, making all collisions with that cube possible, which automatically updates my octomap and opens a small gap in it, making it possible for MoveIt! to plan to the goal position because the manipulator has now an open path to the goal pose. In this 2 following images you can see the example that I tried. I set my goal point to be inside the tree's limits (reachable for the manipulator), so naturally the manipulator can't reach it:

And after I update my AllowedCollisionMatrix, the octomap is automatically updated and it looks like this (the small cube can't be seen because it is really small, smaller than the axes):

Which means that, in fact, the octomap is being correctly updated and after that I can perform the path planned to that point without any problems, everything is fine till here. The problem is that a few seconds after the "hole" open in the octomap, I get the following error messages:

[ERROR] [1522945517.882926418, 54.358000000]: Internal error. Shape filter handle 22 not found [ERROR] [1522945518.668399924, 54.874000000]: Internal error. Shape filter handle 22 not found

I searched about them and I didn't find anything except the fact that they have something to do with the octomap generated by MoveIt!. Is this a bug that's ocorring because the octomap was "updated" because of the AllowedCollisionMatrix? If you think this is relevant, I can send you the code where I update the collision matrix. If there is a better way to do what I did, I would like you to tell me please.

I think it should also be interesting (and profitable, in my case), if I could regulate the size of the box (hole) that eliminates points from the octomap), because if the box is hole in the octomap is to big, it can eliminate objects that will actually interfere ... (more)