Home | Tutorials | Wiki | Issues
Ask Your Question

SImone's profile - activity

2015-10-28 10:56:51 -0600 received badge  Famous Question (source)
2014-07-03 01:49:19 -0600 received badge  Famous Question (source)
2013-08-02 14:45:57 -0600 received badge  Notable Question (source)
2013-07-27 12:02:38 -0600 received badge  Famous Question (source)
2013-06-25 19:58:19 -0600 received badge  Famous Question (source)
2013-05-08 02:14:21 -0600 answered a question unexpected results from laser sensors

This was solved since version 1.6.3 (see change log http://gazebosim.org/wiki/Change_log)

2013-05-07 03:12:53 -0600 commented answer unexpected results from laser sensors

I was not using the latest version, now I've upgraded to the repo version and it seems to be fixed. @dejanpan: the problem seems to be fixed in version 1.6.3 (http://gazebosim.org/wiki/Change_log)

2013-04-17 07:21:23 -0600 received badge  Popular Question (source)
2013-04-12 06:52:49 -0600 commented answer unexpected results from laser sensors

It seems exactly the same problem!

2013-04-10 17:21:20 -0600 received badge  Notable Question (source)
2013-04-09 05:23:21 -0600 commented answer unexpected results from laser sensors

This is not the case of the simple test I've conducted: walls are quite far from the sensor, the minimum measure is 2.91 m. However, I've tried to change both resolution and minimum range parameters without any difference. This seems to be a problem related to ray tracing, because measured values change with beam angle.

2013-04-08 15:35:21 -0600 received badge  Famous Question (source)
2013-04-08 07:21:32 -0600 received badge  Famous Question (source)
2013-04-04 02:22:05 -0600 commented question unexpected results from laser sensors

no, this is not my the case for two reasons: 1) the bug you refer was noticed by me 2) the errors are in the ray length, as clearly demostrated with the second experiment I've posted, where measurement are expressed in laser reference frame and not in world reference frame

2013-04-03 10:19:32 -0600 commented question unexpected results from laser sensors

any news on this topic?

2013-03-28 09:38:34 -0600 commented question unexpected results from laser sensors

I've created a very simple sdf model, with only a laser scanner and some wall as references. I've packed in this file both the model, the world and the results of the scans plotted with an octave script: https://www.box.com/s/bgclvkgn6rtbuzyd9uua. The problem is still present: ranges does not correspond to a line, but have a bell shaped curve. In the packed file you can find a readme.txt file that explain all the details.

2013-03-27 12:39:21 -0600 received badge  Good Question (source)
2013-03-26 16:32:11 -0600 received badge  Notable Question (source)
2013-03-26 09:50:15 -0600 received badge  Editor (source)
2013-03-25 10:39:18 -0600 commented question unexpected results from laser sensors

here https://www.box.com/s/1r97diyyes6ye2tty06w there is the model, sorry for the late in the answer. I've commented out all my plugins invocation, they do not perform anything more than logging data.

2013-03-21 08:31:39 -0600 received badge  Popular Question (source)
2013-03-19 06:33:34 -0600 received badge  Notable Question (source)
2013-03-19 06:32:09 -0600 asked a question unexpected results from laser sensors


I've configured my robot with two inclined laser scanner, then I've wrote some plugin to record laser data and ground truth pose of the robot. I've tried a very simple environment with only the z=0.

I notice that taking the data acquired by sensor, converting them from polar to cartesian and composing with the robot pose, the reconstructed plane is slightly different from the z=0 plane: the minimum height of the point cloud is about 0.002m (~2mm), while the maximum height is about 0.015mm (~1.5cm).

The curious thing is that height is maximum with laser beam acquired at small angles, while decrease with lateral angles. I was expecting that, since there is no noise addition, all the points should be exactly at z=0.

Why this does not happens? Is it related to the ray tracing process performed in the simulation? It depends on the surface of the objects?

2013-03-18 04:14:52 -0600 received badge  Popular Question (source)
2013-03-18 00:56:25 -0600 received badge  Nice Question (source)
2013-03-14 11:31:40 -0600 received badge  Student (source)
2013-03-14 10:55:47 -0600 asked a question Multilple plugin loading


I've noticed that it is not possible to load more than one time a plugin

e.g., if I want to use the "rubble plugin" to generate rubble in two different areas, I can't load it two times, even if I change the "name" attribute

possible workaround are: - copy the library.so with a different name - write my own plugin and manage multiple zones

If it is not so complicated I think that multiple loading of plugins may be an interesting feature

what do you think?

2013-03-11 05:48:31 -0600 received badge  Popular Question (source)
2013-03-07 08:08:00 -0600 asked a question sensors lastMeasurementTime

I've configured a robot with 2 laser scanners and a IMU all the sensors have 10Hz update rate

now, If I look at sensor datas I notice that datas have different time stamp: e.g. by using gztopic echo, IMU time stamps are 0.1, 0.2 and so on the first laser produces data at 0.101, 0.201, 0.301 and so on and the second laser at 0.102, 0.202, 0.203

notice that my simulation time is 1ms, so exactly the 0.001 differences between sensors

it is that normal? why this happens? I was expecting that all the sensors were acquired exactly at the same time since they have the same update rate.

2013-03-06 15:13:25 -0600 received badge  Scholar (source)
2013-03-06 11:47:34 -0600 asked a question math::pose and raySensor

I've a question about pose management and in particular regarding the world pose of a RaySensor calculation

the line 265 in RaySensor.cc calculate the world position of the raySensor as

this->parentEntity->GetWorldPose() + this->GetPose()

while in other part of code, e.g., IMU use (at line 140-141 of ImuSensor.cc)

math::Pose parentEntityPose = this->parentEntity->GetWorldPose();
math::Pose imuPose = this->pose + parentEntityPose;

Now, I've done some experiment with the math::Pose class and I think that the second way is the right one, since pose composition uses a postfix notation. So, imho this is a bug in the RaySensor implementation. Someone have experienced problems with this?

2013-02-28 12:24:32 -0600 received badge  Notable Question (source)
2013-02-21 07:53:31 -0600 received badge  Notable Question (source)
2013-02-19 07:59:30 -0600 received badge  Popular Question (source)
2013-02-17 20:21:22 -0600 received badge  Popular Question (source)
2013-02-13 10:31:02 -0600 asked a question gzclient crash with heightmap


I obtain an ogre exception each time I try to use an heightmap e.g., using

gzserver -u worlds/heightmap.world

the gzclient crash with the following output

Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'Ogre::Exception'
what():  OGRE EXCEPTION(2:InvalidParametersException): Named constants have not been initialised, perhaps a compile error. in GpuProgramParameters::_findNamedConstantDefinition at /build/buildd/ogre-1.7.4/OgreMain/src/OgreGpuProgramParams.cpp (line 1425)

I'm running Gazebo 1.4 by repository binary packages on a xubuntu 12.04 in virtual machine. In particular I've tried both vmware and virtualBox, both with the same results.

I've found online other thread about similar problems, but I can't face a solution for my one. Any suggestion? Avoid the usage of virtual machines? Compile and install from source code?


2013-02-11 08:42:48 -0600 asked a question Installation from source in XUbuntu 12.10 with urdf


I'm trying to install gazebo 1.4 on my Xubuntu 12.10 from source code

analyzing the output of "cmake .." I've noticed that URDF module can not be recognized, altough I've added the ros groovy repository to my system.

In particular, I've done the following things:

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu quantal main" > /etc/apt/sources.list./ros-latest.list'
wget http://packages.ros.org/ros.key -O - | sudo apt-key add -
sudo apt-get update
sudo apt-get install ros-groovy-urdfdom ros-groovy-urdfdom-headers
sudo apt-get install ros-groovy-urdf ros-groovy-urdf-interface ros-groovy-urdf-parser

and then I've run

cmake ..

and also tried

CMAKE_PREFIX_PATH=/opt/ros/groovy/ cmake -DCMAKE_MODULE_PATH=/opt/ros/groovy/share ..

I always obtain that the urdf modules are not found, altought they are installed

moreover, if I disable the "QUIT" flag in the find_package commands of SearchFroStuff.cmake I obtain the next warning:

checking for module 'urdfdom_headers'
package 'urdfdom_headers' not found
urdfdom_headers not found, urdf parser will not be built.
CMake Warning at cmake/SearchForStuff.cmake:258 (find_package):
  Found package configuration file:


  but it set urdfdom_FOUND to FALSE so package "urdfdom" is considered to be
Call Stack (most recent call first):
  CMakeLists.txt:142 (include)

(I obtain a similar output for urdfdom_headers and console_bridge

any suggestion?

thanks in advance SImone