Gazebo | Ignition | Community
Ask Your Question

ThomasK's profile - activity

2019-04-10 06:01:47 -0500 received badge  Famous Question (source)
2018-07-23 07:26:42 -0500 received badge  Enlightened (source)
2018-07-23 07:26:42 -0500 received badge  Good Answer (source)
2017-03-26 13:23:38 -0500 received badge  Nice Answer (source)
2016-09-25 10:20:15 -0500 received badge  Nice Answer (source)
2015-10-31 12:30:19 -0500 marked best answer powerplant model
// This will make the model the correct size, but cause the mdoel to
// rotate. The powerplant model is a good example.

Where do we get the powerplant model? :) It doesn't seem to be in the repository.

2015-10-31 12:11:53 -0500 marked best answer Multiple materials per link

How can you use multiple textures per link in SDF? I tried assigning names to the material and script tag(s) and different combinations of using separate or combined material tags but gazebo always only uses the first material. One example is the Atlas robot that uses multiple textures for some links (e.g. legs).

For example for atlas I created an atlas.material script with Atlas/Carbon and Atlas/Dark materials for two different textures which I then try to make available to Gazebo via

    <material name="mat_carbon">
    <material name="mat_dark">

But it only takes the first material (i also tried fusing both material tags and naming the script tags). What's the correct way of doing this?

After reading the OGRE documentation on materials I'm guessing that only one <material> tag in the sdf is required and the material needs to load the multiple textures. I've tried using multiple texture_unit blocks with names according to the ones in the collada file and different texcoordset ids but still haven't managed to make it load more than one texture per link.

2015-10-31 12:06:24 -0500 marked best answer Commenting

Hi Nate,

I'm not sure whether this is a bug specific to my account, but I'm not able to comment on anyone's posts, all I can do is post a new answer or comment on my own posts. Is there a way for you to fix this?

Thanks, Thomas

2014-01-28 12:02:28 -0500 commented question choosing a GPU card for a high-end simulation machine

Getting a $3k GPU won't resolve that problem though as physics & collision detection runs on the CPU (until Bullet's GPU support is added). If you want to make simulation run faster your best bet is to work on simplifying your collision models and terrain (feel free showing a screenshot of your current model + environment if you can). If you have any laser scanners on your robot you can also test using the GPU variant of the sensor instead of CPU if you're not already doing so.

2013-09-25 19:26:16 -0500 received badge  Taxonomist
2013-06-28 01:33:10 -0500 received badge  Famous Question (source)
2013-06-18 18:00:10 -0500 answered a question Is there and visualization software to create a sdf file? Eg-: can we create a sdf file from a CAD model etc.

You can use the SolidWorks URDF exporter to export from SolidWorks to URDF and then you can convert URDF to SDF (or simply stick with URDF and have Gazebo convert it at runtime).

2013-06-05 06:45:45 -0500 received badge  Nice Answer (source)
2013-06-04 09:22:06 -0500 answered a question IMU sensor plugin in drcsim
2013-05-30 19:16:47 -0500 answered a question including multiple copies of the same model in the

Use the <name> tag to give different names to each model. e.g.

    <pose>-0.0 -2 0 0 0 0</pose>

    <pose>-0.0 -5 1 0 0 0</pose>
2013-05-18 11:26:14 -0500 answered a question Gazebo 1.8 & DRCSim 2.6 doesn't see new DRC World models

There's a ticket for this.

2013-05-09 14:34:22 -0500 received badge  Nice Answer (source)
2013-05-07 03:03:36 -0500 received badge  Notable Question (source)
2013-05-07 03:03:36 -0500 received badge  Popular Question (source)
2013-04-25 19:20:34 -0500 commented answer DRCSIM: Simulating the hands is killing performance

That might work with the new synchronized msgs though? John will need a lightsaber!

2013-04-20 23:15:40 -0500 answered a question Gazebo 1.8.0 , typo?

I'm assuming you installed from default? It's correct in the latest release branches (1.7 and 1.7.1) ... default often gets pushed to the next minor version to make it easier to separate it from already released versions I think.

2013-04-17 14:56:45 -0500 received badge  Famous Question (source)
2013-04-16 23:15:56 -0500 commented question DRC Vehicle - Handbrake functionality broken

Told Steve about this a few weeks ago, he didn't believe me though! :P The way it is it works for manual manipulation though as far as I remember, just drive by wire is a little screwed up (you have to send e.g. 0.5 first prior to sending 1 or 0), same goes for the steering wheel which has lowered gains which makes drive by wire slower. When you increase those gains though it gets more difficult to drive / turn the steering wheel.

2013-04-09 23:52:19 -0500 answered a question Model caching process leaves files in /tmp
2013-03-16 17:35:42 -0500 answered a question why does the torque speed control panel of gazebo GUI disappear?

It's just hidden by default - just clock and drag the right side of the Gazebo window (there's a small "grip", three horizontal white lines) and you'll get the window.

2013-03-13 20:56:01 -0500 answered a question Command line options for ROS and Gazebo

The option that is being used here is a ROS launch file argument. In order to be able to modify the argument passed to a node the launch file needs to be set up for it to take in an (optional) parameter and pass it down to whichever node makes use of it.

In general you can just open the launch file and look for <arg *=""> tags which specify the argument that can be passed to the launch file and its default value. So in the case of atlas.launch you could do "rosed atlas_utils atlas.launch" in order to open the file and then you'll see the lines

<arg name="gzname" default="gazebo"/>
<arg name="gzworld" default=""/>

which tells you that you're able to overwrite the gazebo world being used and whether you want to start it unpaused (default argument gazebo which causes the launch file to run the script run_gazebo in atlas_utils) or paused (by setting gzname to gazebo_paused which then runs the run_gazebo_paused script).

Regiarding the -u and -e options for gazebo you can type "gazebo --help" in order to see all of its available options.

2013-03-13 20:45:01 -0500 commented question DRCSIM: performance gone?

"So the rubble is killing us, and the hands aren't helping."

You wanna know what really gets you killed? Try subscribing to the lidar scan in vrc world 2 and watch the RTF drop all the way from 1.3 to 0.02 (no rubble, no hands).

2013-03-13 18:13:08 -0500 answered a question DRCSIM: performance gone?

What real-time factor did you used to get for the vrc tasks? I usually get 0.02-0.1 on an IntelĀ® Xeon(R) CPU E5-1620 0 @ 3.60GHz ... so your numbers look pretty normal to me. :)

The problem with vrc task 2 is all the dynamically simulated rubble which slows it down incredibly. The RTF you're getting for tasks 3 and 1 are also in the ranges that I've always been getting.

The qual tasks run much faster as they don't have any complex environments (e.g. no huge hose that has to be simulated and no 50 pieces of rubble).

2013-03-12 16:24:46 -0500 answered a question DRCSIM: simulation slows down as robot moves.

I've noticed the exact same behaviour, and it's rather annoying when testing other modules/behaviours. You don't even need to drive it through a complex behaviour, the bug (?) also occurs when using just Atlas + empty world.

I opened a ticket about it a few days ago:

2013-03-12 08:32:40 -0500 commented answer Atlas joints documentation. Where to find.

"sudo apt-get install ros-fuerte-robot-model-tutorials" ... should get you the package

2013-03-12 07:52:08 -0500 received badge  Popular Question (source)
2013-03-12 07:52:08 -0500 received badge  Notable Question (source)
2013-03-11 21:34:03 -0500 answered a question Atlas joints documentation. Where to find.

The best option is probably to run

roscd atlas
roslaunch urdf_tutorial display.launch model:=atlas.urdf gui:=True

and then play with the sliders to figure out which joint corresponds to which name.

2013-03-11 14:34:51 -0500 commented question What should we expect from Simbody?

Same question goes for RTQL8

2013-03-09 21:28:08 -0500 answered a question VRC task 3: file name error

Which branch are you using? Works for me.

2013-03-09 21:24:24 -0500 answered a question DRCSIM: VRC is Black and Gold

It's a bug of the "old" Gazebo. It's fixed in 1.5.

2013-02-22 21:00:58 -0500 answered a question Can Textures be added to simple objects from my own source?

So there's two ways (that I know of) that you can do this:

  • Within the model directory: create a materials/scripts and materials/textures directory in the directory of the corresponding model and put the texture into materials/textures and the corresponding *.material into materials/scripts ... have a look at your very own brick_box_3x1x3 for example. ;)

  • If you want to specify materials that can be used by multiple models you can create a folder "media" that, again, contains "materials/scripts" and "materials/textures" as sub-directories and then add the directory that your "media" directory is part of to your GAZEBO_RESOURCE_PATH. So for example with the default setup you have a "/usr/local/share/gazebo-1.4/media" directory (compiled from source, debian package installation would be in /usr/share/...) and "/usr/local/share/gazebo-1.4" is in the GAZEBO_RESOURCE_PATH. To add your own materials you simply create a "<my_package>/media/materials/" directory with the desired scripts and textures and add "<my_package>" to the GAZEBO_RESOURCE_PATH.

2013-02-21 02:13:08 -0500 received badge  Notable Question (source)
2013-02-13 17:39:06 -0500 commented question DRC Control issue: Bad joint_states when in Nominal mode

bugs can be reported in the bitbucket drcsim repo, i created an issue for you:

thanks for letting the other teams know!

2013-02-07 21:50:00 -0500 received badge  Popular Question (source)
2013-02-05 21:37:14 -0500 commented answer DRC Laser / Stereo Disparity between Collision and Visual Elements

Ah it's the vertical fov that is restricted to 90 degrees, it was late already yesterday :) ... all good then I guess, great

2013-02-05 20:17:03 -0500 commented answer DRC Laser / Stereo Disparity between Collision and Visual Elements

Partially ... GPU laser sensor is capped at 90 degrees as it's intended to be used for sensors with a 2d image sensor I think (e.g. TOF sensors or Kinect or other depth cameras), but you could use the GPU ray sensor to extend it to a lidar sensor, see my suggestion in my comment here: