Home | Tutorials | Wiki | Issues
Ask Your Question

IsaacS's profile - activity

2017-08-17 10:02:17 -0500 received badge  Famous Question (source)
2016-11-29 04:32:33 -0500 received badge  Famous Question (source)
2016-04-11 08:07:30 -0500 received badge  Famous Question (source)
2016-02-02 20:47:51 -0500 received badge  Famous Question (source)
2016-02-02 20:47:51 -0500 received badge  Notable Question (source)
2015-11-20 18:36:25 -0500 received badge  Famous Question (source)
2015-11-09 07:44:26 -0500 received badge  Notable Question (source)
2015-11-09 07:44:26 -0500 received badge  Famous Question (source)
2015-11-02 01:36:31 -0500 received badge  Nice Question (source)
2015-11-02 01:34:15 -0500 received badge  Notable Question (source)
2015-11-02 01:34:15 -0500 received badge  Famous Question (source)
2015-10-31 12:31:06 -0500 marked best answer Why even Gazebo + ROS questions should be asked on gazebosim.org?

@nkoenig announced in this thread.

To me, however, since Gazebo can work standalone without ROS, it makes more sense to delegate ROS related question to answers.ros.org. Indeed there have been recently many questions that are related to gazebo on answers.ros.org that might have not captured enough attention from people in gazebosim community.

2015-10-31 12:30:57 -0500 marked best answer Should URDF in Gazebo tutorials be replaced with SDF?

Migrated from ROS' community's website.

In the QA thread "SDF vs URDF what should one use?" (on answers.gazebosim.org), URDF is not recommended on gazebo in favor of SDF. But from the answer in this thread, sounds like URDF will still be supported on gazebo. Can we keep the tutorial using URDF?


A couple of comments there:

It would be better to have one standard (and also use the new version 
of Gazebo in ROS), would prevent a lot of problems. But URDF is also 
used in RVIZ which doesn't care about the extra proporties like 
friction. @Davinci 

2nd:

I'm in favour. I'm new and the learning curve is steep when I need to 
pull bits of advice off of gazebosim (usually SDF) and ros answers 
(URDF) and figure out what's valid where and in which version of Gazebo.
@Benjamin Blumer
2015-10-31 12:30:39 -0500 marked best answer "save as" feature not saving light info into world file

I added a custom Point Light on Gazebo GUI and save it via save as but the resulted sdf file only contain sun with default setting. I can't either seem to save the default sun with modification. Is saving light info not possible yet?

Gazebo 2.2.3 on Ubuntu Trusty 64b

Thanks.

2015-10-31 12:11:52 -0500 marked best answer No skyx texture on Gzweb

While on Gazebo SkyX works as expected, it doesn't seem so on Gzweb for me. We set it after sunset to show the starry sky on moon, but the sky is all blacked out, no stars, Sun and the earth (as we customized).

no starry sky

I found that the files in skyx folders in Gazebo and Gzweb are slightly different, but replacing Gzweb's dir (gzweb/http/client/assets/media/skyx) with the one from Gazebo didn't solve the issue.

Using Gazebo (2.2.5), Ubuntu 14.04, Gzweb 1.2.0 with the following commit.

changeset:   840:a166e0734e7d
tag:         tip
date:        Fri Jan 30 09:44:59 2015 -0800
2015-10-31 12:05:52 -0500 marked best answer Remove the flaring edge of Moon/Earth in SkyX

Using this pull request to gazebo_models and the suggestions there, we're now holding a moonlight earthlight party using Gazebo, by simply replacing SkyX_Moon.png with an earth image included in this PR.

tetris simulation with earth from the lunar surface

I think the flaring rim surrounding the earth was suitable for the moon seen from the earth, but not the other way round. Where should I edit SkyX to remove it? Thank you.


UPDATE: Thanks to @iche033's answer, we now enjoy even more serene moment.

earth w/o fragment

$ diff /usr/share/gazebo-2.2/media/skyx/SkyX_Moon.fragment.org /usr/share/gazebo-2.2/media/skyx/SkyX_Moon.fragment
60c60
<   haloIntensity = pow(haloIntensity, uMoonPhase.z);
---
>   haloIntensity = pow(0.0, uMoonPhase.z);

Catch for me was that this .fragment file seems to not work right with some comment-out formats; I was trying to use # and it just didn't show the earth at all.

2015-09-07 19:13:31 -0500 received badge  Notable Question (source)
2015-08-18 20:57:02 -0500 received badge  Necromancer (source)
2015-08-18 20:57:02 -0500 received badge  Teacher (source)
2015-08-18 20:56:18 -0500 received badge  Notable Question (source)
2015-08-01 08:39:41 -0500 received badge  Notable Question (source)
2015-07-04 12:15:30 -0500 received badge  Popular Question (source)
2015-07-03 18:02:11 -0500 commented answer Reuse .sdf using different mesh files

Thanks. Originally I was hoping for a way to "reuse" a single SDF, not replicating SDF files, but after having seen discussions at another places (e.g. this) I now understand using erb is the best available option for SDF.

2015-07-03 17:39:47 -0500 commented answer Parameterizing elements of an SDF model

@nckswt Although I agree with you on not duplicating SDF files, its challenge is explained here by @scpeters, which I don't quite understand but I just took it as a compelling reason.

2015-07-03 12:42:49 -0500 asked a question Inertial parameters not taken into effect

A .dae file (representing a pile of books) stands on the wrong side (I expect the long side to sit on the floor). The pink portion at the bottom is the center of mass Gazebo shows. image description

Indeed the CoM in the .dae file is skewed [according to Meshlab]](http://gazebosim.org/tutorials?tut=inertia&cat=build_robot).

Opened mesh books1.dae in 66 msec
All files opened in 1802 msec
Loading textures
Texture[ 0 ] = '../shelf_books.png' ( 1024 x 1024 ) -> ( 1024 x 1024 )
Mesh Bounding Box Size 0.290330 0.172450 0.120600
Mesh Bounding Box Diag 0.358573 
Mesh Volume is 0.005539
Mesh Surface is 0.647713
Thin shell barycenter 1.319048 0.488971 0.060420
Center of Mass is 1.318931 0.489051 0.060878
Inertia Tensor is :
| 0.000020 0.000000 -0.000000 |
| 0.000000 0.000045 0.000000 |
| -0.000000 0.000000 0.000052 |
Principal axes are :
| 0.999999 0.001423 -0.000027 |
| -0.001423 0.999999 0.000014 |
| 0.000027 -0.000014 1.000000 |
axis momenta are :
| 0.000020 0.000045 0.000052 |

Then I thought I can overwrite the CoM in the model's SDF as below, which takes no effect on Gazebo except for the mass (values are set at random here. I'm just trying to see if values in SDF are reflected), according to Gazebo's model view pane.

<model name="book1">
  <static>false</static>
  <link name="body">
    <inertial>
      <pose>0 0 0 0 0 0</pose>
      <mass>2</mass>
      <inertia>
        <ixx>0.004878</ixx>
        <ixy>-6.2341e-07</ixy>
        <ixz>-7.4538e-07</ixz>
        <iyy>0.00090164</iyy>
        <iyz>-0.00014394</iyz>
        <izz>0.0042946</izz>
      </inertia>
    </inertial>

Am I missing anything or doing wrong?

2015-07-02 19:28:29 -0500 received badge  Popular Question (source)
2015-06-30 16:45:42 -0500 received badge  Popular Question (source)
2015-06-27 19:56:27 -0500 asked a question Strange Hokuyo laser range with libgazebo_ros_gpu_laser.so

In a trial to publish laser output to ROS world, I followed the tutorial and the range of visualized laser on Gazebo is very short while using the same value from the tutorial (min: 0.1 and max: 30.0). ROS topic was published but due to this shortest range nothing could be detected.

image description

<sensor type="gpu_ray" name="head_hokuyo_sensor">
  <pose>0 0 0 0 0 0</pose>
  <visualize>true</visualize>
  <update_rate>40</update_rate>
  <ray>
    <scan>
      <horizontal>
        <samples>720</samples>
        <resolution>1</resolution>
        <min_angle>-1.570796</min_angle>
        <max_angle>1.570796</max_angle>
      </horizontal>
    </scan>
    <range>
      <min>0.10</min>
      <max>30.0</max>
      <resolution>0.01</resolution>
    </range>
    <noise>
      <type>gaussian</type>
      <!-- Noise parameters based on published spec for Hokuyo laser
           achieving "+-30mm" accuracy at range < 10m.  A mean of 0.0m and
           stddev of 0.01m will put 99.7% of samples within 0.03m of the true
           reading. -->
      <mean>0.0</mean>
      <stddev>0.01</stddev>
    </noise>
  </ray>
  <plugin name="gazebo_ros_head_hokuyo_controller" filename="libgazebo_ros_gpu_laser.so">
    <topicName>/spur/laser/scan</topicName>
    <frameName>/hokuyo_sensor_link</frameName>
  </plugin>
</sensor>

Is this bug or am I doing something wrong?

Btw, cince I switched to libgazebo_ros_laser.so by following this blog with the following config and I got the laser range I wanted, my issue is resolved.

image description

<sensor type="ray" name="laser">
  <pose>0 0 0 0 0 0</pose>
  <visualize>true</visualize>
  <update_rate>40</update_rate>
  <ray>
    <scan>
      <horizontal>
        <samples>720</samples>
        <resolution>1</resolution>
        <min_angle>-1.570796</min_angle>
        <max_angle>1.570796</max_angle>
      </horizontal>
    </scan>
    <range>
      <min>0.1</min>
      <max>4.0</max>
      <resolution>0.01</resolution>
    </range>
    <noise>
      <type>Gaussian</type>
      <mean>0.0</mean>
      <stddev>0.01</stddev>
    </noise>
  </ray>
  <plugin name="hokuyo_node" filename="libgazebo_ros_laser.so">
    <topicName>/spur/laser/scan</topicName>
    <frameName>/hokuyo_sensor_link</frameName>
  </plugin>
</sensor>

Ubuntu 14.04, Gazebo 2.2.5, ROS Indigo

2015-06-27 19:47:28 -0500 asked a question Strange Hokuyo laser range with libgazebo_ros_gpu_laser.so

In a trial to publish laser output to ROS world, I followed the tutorial and the range of visualized laser on Gazebo is very short while using the same value from the tutorial (min: 0.1 and max: 30.0). ROS topic was published but due to this shortest range nothing could be detected.

image description

<sensor type="gpu_ray" name="head_hokuyo_sensor">
  <pose>0 0 0 0 0 0</pose>
  <visualize>true</visualize>
  <update_rate>40</update_rate>
  <ray>
    <scan>
      <horizontal>
        <samples>720</samples>
        <resolution>1</resolution>
        <min_angle>-1.570796</min_angle>
        <max_angle>1.570796</max_angle>
      </horizontal>
    </scan>
    <range>
      <min>0.10</min>
      <max>30.0</max>
      <resolution>0.01</resolution>
    </range>
    <noise>
      <type>gaussian</type>
      <!-- Noise parameters based on published spec for Hokuyo laser
           achieving "+-30mm" accuracy at range < 10m.  A mean of 0.0m and
           stddev of 0.01m will put 99.7% of samples within 0.03m of the true
           reading. -->
      <mean>0.0</mean>
      <stddev>0.01</stddev>
    </noise>
  </ray>
  <plugin name="gazebo_ros_head_hokuyo_controller" filename="libgazebo_ros_gpu_laser.so">
    <topicName>/spur/laser/scan</topicName>
    <frameName>/hokuyo_sensor_link</frameName>
  </plugin>
</sensor>

Is this bug or am I doing something wrong?

Btw, cince I switched to libgazebo_ros_laser.so by following this blog with the following config and I got the laser range I wanted, my issue is resolved.

image description

<sensor type="ray" name="laser">
  <pose>0 0 0 0 0 0</pose>
  <visualize>true</visualize>
  <update_rate>40</update_rate>
  <ray>
    <scan>
      <horizontal>
        <samples>720</samples>
        <resolution>1</resolution>
        <min_angle>-1.570796</min_angle>
        <max_angle>1.570796</max_angle>
      </horizontal>
    </scan>
    <range>
      <min>0.1</min>
      <max>4.0</max>
      <resolution>0.01</resolution>
    </range>
    <noise>
      <type>Gaussian</type>
      <mean>0.0</mean>
      <stddev>0.01</stddev>
    </noise>
  </ray>
  <plugin name="hokuyo_node" filename="libgazebo_ros_laser.so">
    <topicName>/spur/laser/scan</topicName>
    <frameName>/hokuyo_sensor_link</frameName>
  </plugin>
</sensor>

Ubuntu 14.04, Gazebo 2.2.5, ROS Indigo

2015-06-26 07:41:18 -0500 received badge  Notable Question (source)
2015-06-25 10:28:50 -0500 received badge  Famous Question
2015-06-22 05:15:11 -0500 commented answer Increase Ground Plane Grid Size

In my application I replaced planes with boxes, with their width = 0.01. I don't know if that's appropriate but seems to be working fine for my purpose (I just needed stairs).

2015-06-22 02:21:53 -0500 received badge  Popular Question (source)
2015-06-21 20:38:02 -0500 commented question To visualize collisional region

@chapulina that does it. If you repost it as an answer I'll mark it as an answer. Thanks!

2015-06-21 20:24:52 -0500 asked a question To visualize collisional region

Is there a way to visualize collision (box, cylinder etc.) defined in SDF? If I'm not mistaken, we still need to give Gazebo visual and collision information separately (as found in another thread). So I'm debugging the collisional region by iterating the following steps many times, which is very cumbersome to me.

  1. Edit sdf
  2. Run Gazebo
  3. Run a robot to try hitting the defined but transparent collision region. If it fails to hit, go back to step 1.

User's operation environment: Gazebo 2.2, ROS Indigo on Ubuntu Trusty

Since I'm using ROS, I can use RViz if there's a feature for this. Also for development purpose, upgrading Gazebo can be an option if only higher version software has a functionality, but the users will run the resulted files on Gazebo 2.2 (or any version that is compatible with ROS Indigo without tweak).

2015-06-20 18:16:25 -0500 asked a question Reuse .sdf using different mesh files

Say I have an sdf file like below:

<?xml version="1.0" ?>
<sdf version="1.4">
    <model name="bookertshelf">
      <static>true</static>
      <link name="body">
        <visual name="visual">
          <geometry>
            <mesh><uri>model://bookertshelf/dummy.dae</uri></mesh>
          </geometry>
        </visual>
      </link>
    </model>
</sdf>

I have bookertshelf-%X%.dae files for all of which I like to use the same SDF config above. Is there a way to reuse this SDF file without doubling the file?

In my world file I tried the following that doesn't seem to be doing what I want (without error on console).

<include>
  <name>bookertshelf1</name>
  <pose>0 -6.0 0 1.5708 0 -1.5708</pose>
  <static>true</static>
  <uri>model://bookshelf</uri>
  <mesh><uri>model://bookertshelf/bookertshelf1.dae</uri></mesh>
</include>

I'm on Ubuntu Trusty, Gazebo 2.2.5. Upper version of Gazebo can't be an option since I'm using ROS Indigo where 2.2 seems like a must.

2015-06-20 02:35:09 -0500 commented answer Is there a way to modify the default camera position in the world file?

With SDF1.4, data format is as what @chapulina mentions. I think tuple (that can be commonly embraced in parenthesis) stated in the answer might be a bit confusing.

2015-06-20 02:19:30 -0500 received badge  Popular Question (source)
2015-06-17 18:14:37 -0500 received badge  Famous Question (source)
2015-06-09 01:35:14 -0500 commented answer OpenID2.0 Google log in issue?

With your suggestion, OpenID 2.0 issue still remains but I was able to login with my Google account.