Ben_S's profile - activity

You made some really large (and some even absurd) changes to some of the gmapping parameters, which may lead to the observed behaviour...

<param name="linearUpdate" value="0.01"/>
<param name="angularUpdate" value="0.01"/>
<param name="temporalUpdate" value="0.1"/>

These settings will force an update with almost every new scan and benefit the accumulation of even small errors in scan matching. This may be the main culprit and what makes your odometry mostly meaningless.

Try setting these parameters closer to the default like linear 0.2, angular 0.3 and especially temporal to something like 5-10 (or even -1 to turn it off completely).

<param name="particles" value="1"/>

Now regarding the "even absurd" part of your config. GMapping is a particle filter based SLAM approach. So it needs some particles with each representing one "guess" of the current position and traveled path. When setting particles to 1 you are in fact doing dead reckoning based on scan matching, odometry and even some (intentionally!) added noise. You should set particles to at least the default value of 30 or even better higher! (Whatever your CPU can support. We typically use between 50 and 80 particles.)

In general i would advise you to start of with the default GMapping config and change only those parameters you really need and even then not by a factor of over 30 to begin with...

Thanks for the additional informations. Would it be possible to post a similar video while having the fixed frame set to /odom?

Is your laser scanner mounted in a somewhat unusual position? (Like facing backwards, seen from positive x of your base_link) What are your transforms from base_link to laser? Would it be possible to post your launch file(s) and maybe a small bag recording?

cloudcb is not a member of your class Listener. Thats why it won't be possible to call publishBbox() from within. Make it a class method and add your object reference to the subscriber like you did for the publisher.

You should also get your variable names right and think about moving the subscriber and publisher into your class, initializing them in the constructor.

You should use a combination of spinOnce() and sleep (have a look at the tutorials). spin() blocks until an error occures or the program receives a sigint (ctrl+c).

Also it may be a good idea to move the spinning to the main loop. A blocking constructor seems like rather bad design... :)

This will most likely not work. Laser parameters in GMapping are determined from the first received message. After that it will always use that frame, scan-count, angle increments etc... So no, using GMapping with multiple laser scanners is impossible or at least extremly difficult.

Maybe the mongodb_wrapper is used through service calls and not topics. (Which would make sense in my opinion...)

These will not be visible in rqt_graph.

Can you post your launch files and maybe a bag file of your data? Guessing from your description seems rather problematic. Normally the odometry by laser_scan_matcher should be sufficient for amcl...

1. Remove the static transforms from map -> odom and odom -> base_link. You want them dynamic from amcl and the laser_scan_matcher and not static.
2. fixed_frame for the laser_scan_matcher has to be set to /odom and not map, since the node is responsible for your odom -> base_link transform and not the localization within your map.

amcl receives its odometry informations through the /odom -> /base_link transform. (Or whatever you have set as odom_frame_id and base_frame_id parameters)

This means that you need a node (typically your hardware abstraction) that accumulates odom information from your base-robot and publish the aggregated pose as a transform.

So no, laser only will not be sufficient.

Try initializing depth_image.data with an properly sized array. Also you should check if the size of the incoming image and the output match. (Or set width, height and step accordingly to the input)

Have you set ROS_IP or ROS_HOSTNAME? Do some of the PCs have Firewalls installed?

Well, in this case there was a real problem with GMapping and how it handles incoming data. There is no way, that this would have worked with the data "as is". :)

One thing i saw in the small bag is that the robot sometimes seems to roll or tilt, so that a part of the floor is seen by the laser. This may confuse pure 2d slam approaches as they may interpret that measurement as a wall.

I will be able to look into it on wednesday. Are you using the latest version from Github? GMapping in general has problems with non-symmetrical scanners. (e.g. min_angle != -max_angle) This will lead to problems like rotation by 180 degrees in your case...

Could you upload the bag file somewhere? I would love to take a closer look. I wrote the last patch regarding gmapping and inverted (and rear facing) lasers. Try checking out the last gmapping versions for your ros-version from the git-repo. I dont know if the binary already includes the patches...

Its also important, that there is some kind of base_link. Currently released gmapping uses odom -> base_link tf for motion estimation. Newest version from git uses odom -> laser frame for motion, but needs base_link -> laser to find out about the orientation of the laser.

Can the device ping your pc by its name? ("laptop") Try setting ROS_IP to the IPs on both sides and use the IPs in the ROS_MASTER_URI.

Ok, so the driver itself is working. Do you see the IR projector turning on, when you subscribe to the depth topics? Try disabling depth registration and then subscribe to the non registered depth topics. Is there any error message in rviz? Did you set a fixed frame?

Yes, that is possible. Also have a look at this answer if you want your callback to have a custom parameter, to know which topic (/robot) is the source.

Edit:

You could use only one topic and let every robot send messages with a unique id to it.