carlos's profile - activity

If I leave the simulation running for while, it does start falling, but very slow, as if the joint had damping (if the robot is vertical it never moves). I'm actually playing with the gazeboroscontrol plugin, I'm using my modified rrbot example. Here I'm trying different things for the non-driven joint.

I have a model with 2 revolute joints spawn from an urdf, and a gazebo-ros plugin to interact with it.

I want to command the position of one joint, and the other should swing freely, but wish to know its position.

So I have a std::vector<gazebo::physics::JointPtr> sim_joints_; properly initialized with the sdf joints, and in the plugin Update() I read the two states like

for(unsigned int j=0; j < 2; j++)
{
    joint_position_[j] += angles::shortest_angular_distance(joint_position_[j],
                          sim_joints_[j]->GetAngle(0).Radian());
}

then publish all joint_position_'s, update the joint_position_command for joint j=1, and finally write

sim_joints_[0]->Update();
sim_joints_[1]->SetPosition(0, joint_position_command);

Joint j=1 moves according to the command, but joint j=0 does not swing. If I don't write anything, i.e. delete the SetPosition(), or if I use sim_joints_[j=0,1]->Update(), both joints swing freely.

Seems like writing the position to any joint makes the rest joints to freeze.

Am I missing something? How can achieve the desired behavior?

I tried succesfully the robotNamespace tag in the transmissioninterface package. (Simple) changes are in the "multi-robot-test" branch of https://github.com/CentroEPiaggio/roscontrol and https://github.com/CentroEPiaggio/gazeborospkgs that allows me to spawn a single robot description param composed of robots (having different HW and Trans interfaces). The same param used by MoveIt!. Here a screenshot of the whole robot https://www.dropbox.com/s/wmfahzm8jln1059/vito.png?dl=0.

Hi, I know this is old, however, I'd like to mention that the point cloud data is fine. With Asus/Primesense/Kinect1 the point cloud is published in the "camerargbopticalframe" which is rotated with the transformation you mention with respect to the "cameralink".

In my case, I set <framename>${name}/camerargboptical_frame</framename> and then I have a launch file with the default axis transformations (you can get them using a real RGBD sensor and tf echoing the frames) like this.

<launch>

<!-- LAUNCH INTERFACE -->
<arg name="camera_name" default="head"/>

<!-- LAUNCH IMPLEMENTATION -->
<node pkg="tf" type="static_transform_publisher" name="hand_camera_calib" args="0.000 -0.020 0.000 0.000 0.000 0.000 1.000 $(arg camera_name)_link $(arg camera_name)/camera_link  100"/>

<node pkg="tf" type="static_transform_publisher" name="camera_depth_frame" args="0.000 -0.020 0.000 0.000 0.000 0.000 1.000  $(arg camera_name)/camera_link $(arg camera_name)/camera_depth_frame 100"/>

<node pkg="tf" type="static_transform_publisher" name="camera_depth_optical_frame" args="0.000 -0.020 0.000 -0.500 0.500 -0.500 0.500 $(arg camera_name)/camera_link $(arg camera_name)/camera_depth_optical_frame 100"/>

<node pkg="tf" type="static_transform_publisher" name="camera_rgb_frame" args="0.000 -0.045 0.000 0.000 0.000 0.000 1.000 $(arg camera_name)/camera_link $(arg camera_name)/camera_rgb_frame 100"/>

<node pkg="tf" type="static_transform_publisher" name="camera_rgb_optical_frame" args="0.000 -0.045 0.000 -0.500 0.500 -0.500 0.500  $(arg camera_name)/camera_link $(arg camera_name)/camera_rgb_optical_frame 100"/>

</launch>

And it works fine for me.

I have a robot formed by several robots, say two arms, two hands mounted at each arm as end-effectors, and a head, as usual, and have the following requirements:

1. Plan for the two arms simultaneously, or plan for one arm being aware that there is another arm, etc(using MoveIt! and ros_control).

2. A launch file in which I can select whether a part uses the real or the simulated hardware (using Gazebo).

3. Each part is a self-contained robot, that is, the URDF has a gazebo_ros_control plugin and transmissions, so it can be used separately as well.

4. (optional, but desirable) Minimize duplication in specifications, as always.

My short experience with MoveIt!, and as well, as explained in this post, tells me that a single URDF for point 1 is the best, if not the only, solution for now.

The issue with a single URDF loading self-contained URDFs is that the gazebo_ros_control plugin parses/loads/(eventually uses) all transmissions from the robot_description parameter. Each plugin of each part starts in a different namespace, ok, but every time a plugin starts, it loads all transmissions again, and create the interfaces for the same joints in different namespaces, and so on. I wouldn't use a single plugin for the whole robot, specially having a custom robotHWsim interface that uses a custom transmission on the hands (it worths noting that). So, what I'd like to happen is that each plugin uses those transmissions affecting the joints the plugin is meant to expose. And recall that I can't use the <robotParam> tag in the plugin, since I'm using a single URDF... that would be ideal.

One possible solution I can think of is to allow a namespace specification in transmissions, in a similar way as the gazebo_ros_control plugin <robotNamespace> tag, with the aim to use that information to filter transmissions out by namespace when starting the plugin. Thus, one could spawn a single URDF, and in my case, point 2 would be just a mere source_list/remap of joint states from real and/or simulated hardware.

/

My workaround so far is to have both a single URDF of the full robot which is not spawned in gazebo and used through the robot_description parameter in MoveIt!, Rviz, etc., and separated URDFs which are spawned in gazebo in case I want to simulate that part, where transmissions are loaded from a /PART_NAMESPACE/robot_description parameter. Note that placement points for each URDF part are useless in this case, and as a consequence, the full robot in simulation is only useful to control a dynamic/kinematic chain. Something like the proposed here would help on this. However, I would still prefer spawning a single URDF file.

Has anyone faced a similar problem? (or perhaps I'm missing a more trivial solution) Suggestions, tips and comments are more than welcome. Thanks.