Home | Tutorials | Wiki | Issues
Ask Your Question

Nevik's profile - activity

2019-02-26 16:11:39 -0500 received badge  Taxonomist
2014-01-27 22:51:44 -0500 received badge  Famous Question (source)
2013-10-15 03:43:07 -0500 received badge  Famous Question (source)
2013-09-15 18:40:58 -0500 received badge  Notable Question (source)
2013-08-30 03:16:54 -0500 received badge  Notable Question (source)
2013-08-24 16:54:26 -0500 received badge  Supporter (source)
2013-08-24 16:54:23 -0500 received badge  Scholar (source)
2013-08-23 10:18:09 -0500 received badge  Popular Question (source)
2013-08-22 13:03:05 -0500 commented answer How to run Gazebo 1.9 headless

Does the server try to run any OpenGL when the robot model uses a camera sensor plugin? I have one in my model and when I try to spawn the model with the server running, it crashes with an OGRE error about a texture or whatnot. I had assumed cameras would just be disabled, but could it be that I have to manually remove them from the model?

2013-08-21 08:55:07 -0500 received badge  Editor (source)
2013-08-21 08:39:45 -0500 asked a question How to run Gazebo 1.9 headless

For a series of unattended simulations, we'd like to utilize a bunch of VMs on a server. For this, we'd like to run a Gazebo simulation server in headless mode (since a] the server has no graphics card and b] Gazebo does not like VirtualBox's OpenGL capabilities).

I've found a few mentions of using the commandline argument -r to run in headless (no OGRE/OpenGL) mode, but this seems to have changed in recent Gazebo. In the --help screen of Gazebo 1.9.5, the -r option is listed as "record", and no mention is made of a headless mode.

So my question is, how do I run a Gazebo 1.9 server in headless mode?

PS: If this is not available in the standard binary releases (we're using the DEB packages at the moment), I could also recompile Gazebo. I just need to find out how to use a Gazebo 1.9 with a ROS-fuerte.... (but that's not part of this question)

2013-08-13 12:43:45 -0500 received badge  Popular Question (source)
2013-07-29 07:56:12 -0500 commented question Robot-Plugin is Loaded again when spawning another Robot

I know this might be not the best thread to post this, but the multi-instance problem is probably related to a namespace (topic name) in your robot URDF file. You will need to override this when adding more than one instance, either by overriding certain parameters in the call, or by creating slightly modified URDF files to override the namespace settings.

2013-07-29 07:46:56 -0500 commented question How does Gazebo (1.0) derive the tf (transform) tree

@evilBiber, I have found out more about the transforms and topics, and will add more details to my question and probably post an answer later. But I'm very much interested in your port to groovy+1.9 (especially if you converted it all to a catkin workspace). Please drop me an email (just added my address to my profile), and we can discuss this further.

2013-07-29 04:41:07 -0500 asked a question How does Gazebo (1.0) derive the tf (transform) tree

When used in conjunction with ROS, Gazebo naturally makes use of the tf package to transform between different local coordinate systems ("poses"?). To this end, it somehow derives a tf frame tree from the model's link structure (as described in the URDF/SDF file).

How does it do this?

I am asking because I'm having trouble with certain tf prefixes, and using a ROS-like name (like /commonprefix/specific_base_link) for the base-link of the model does not work (the /commonprefix part is ignored).

This is especially a problem since I use multple robot instances in one simulation -- the plugins for which I didn't write myself (I use a slightly modified TUM Simulator which in turn is based on the TU Darmstadt Hector packages). For certain visualizations in RViz, I need a common root frame -- which I can't seem to achieve, since Gazebo derives the frame tree for the robot models itself, without being told how in any of the description (URDF) files I've found so far.

A note on my environment: Ubuntu 12.04 with ROS fuerte and its builtin/packaged Gazebo 1.0.2. I know this Gazebo is REALLY old, but the mentioned packages only properly work with this version combination for now, and I do not have the time to update it all to Hydro+1.9, since the alterations are rather significant.

2013-07-29 04:29:19 -0500 commented question Gazebo being moody (sometimes starting, sometimes not)

@gerkey @trinighost thanks for your input; the problems were "solved" by "acquiring" an Nvidia graphics card. It took a long time to figure that out, since I had not expected Gazebo to be so picky, and had not seen it mentioned anywhere that non-Nvidias are just about completely incompatible.

2013-07-25 06:08:13 -0500 received badge  Nice Question (source)
2013-06-13 10:17:48 -0500 received badge  Famous Question (source)
2013-04-30 10:37:07 -0500 received badge  Notable Question (source)
2013-04-29 17:37:33 -0500 received badge  Popular Question (source)
2013-04-29 02:48:16 -0500 commented question Gazebo being moody (sometimes starting, sometimes not)

@Davinci: this does indeed happen most often with launch files, but it also sometimes happens when I launch Gazebo manually. Since the launch files haven't been developed by myself, I'll take a look at them and see if I can improve the launch order (and maybe add some delays).

2013-04-28 14:19:44 -0500 received badge  Student (source)
2013-04-28 11:11:38 -0500 asked a question Gazebo being moody (sometimes starting, sometimes not)

I have set up ROS (fuerte) with Gazebo 1.7.1 (current from repo) on a Xubuntu 12.04 and finally got it halfway working. I have set up a rosws workspace and added the setup scripts for that and for gazebo to my .bashrc.

However, what I still often observe is that Gazebo is very moody when it comes to launching. By "moody" I mean that it sometimes starts fine and sometimes just crashes -- and with different causes, too.

This is on a different computer so I can't post logs right away; but I think the logs themselves wouldn't be that helpful anyway.

I'm much more interested in why Gazebo is that sensitive to (I assume) minute differences in the environment. In most cases so far, re-sourcing the Gazebo setup.sh makes it start again, but sometimes I need to source it twice in a row. So I guess one of the questions here is: why does Gazebo change the environment during its execution, breaking itself on the next launch?