SImone's profile - activity

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

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)

It seems exactly the same problem!

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.

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

any news on this topic?

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.

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.

Hi

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?

Hi

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?

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.

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?

Hi

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)
Aborted

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?

SImone

Hello

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:

    /opt/ros/groovy/share/urdfdom/cmake/urdfdomConfig.cmake

  but it set urdfdom_FOUND to FALSE so package "urdfdom" is considered to be
  NOT FOUND.
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