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 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? |
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 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? |
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 while in other part of code, e.g., IMU use (at line 140-141 of ImuSensor.cc) 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 Hi I obtain an ogre exception each time I try to use an heightmap e.g., using the 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 |
2013-02-11 08:42:48 -0600 | asked a question | Installation from source in XUbuntu 12.10 with urdf 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: and then I've run and also tried 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: (I obtain a similar output for any suggestion? thanks in advance SImone |