Ricardo Tellez's profile - activity

No, it doesn't, as indicated in http://answers.ros.org/question/10299/rospy-logging/

I'm trying to launch a node with the --pid option to obtain a file with the pid of the process, like in this example:

nohup python -u `rospack find roslaunch`/bin/roslaunch --wait --pid=/tmp/pid_file $* &> /tmp/${1}.roslaunch.log &

By launching our processes like this, we observe that sometimes the pid file is generated but whithout the pid value inside (empty file). We observed that this problem usually happens when the CPU load is very high.

I don't know who is responsible of generating the pid (either ROS infrastructure or something in the linux kernel). The thing is that the same behavior (more or less) can be observed if we use the following command to generate the pid file:

nohup python -u `rospack find roslaunch`/bin/roslaunch --wait $* &> /tmp/${1}.roslaunch.log &
echo $! > /tmp/pid_file

That smells like something in the kernel behavior, but not sure. Any idea why the pid is not generated?

Gmapping does not publish the pose of the robot as a pose per se (within a topic), but as a transform from 'map' to 'odom'.

In order to get the pose of the robot in the map that is built you have to get the current odometry of the robot (read your odometry topic) and then ask for the transform of that odometry (that is in 'odom' frame) to the 'map' frame. The result will be a pose in 'map' frame (the coordiantes of the robot in the map)

Then, in order to visualize the robot path through the map being built you have to create a node that asks periodically for that transform, store it in some place, and publish all the stored points as a path in a given topic (you decide the name).

Key point here is to understand the difference between 'tf transform' and 'topic'. Gmapping publishes a topic named '/map' which contains the current map, but it also publishes the tf transform 'map' (to 'odom').

Every time that smach performs a transition to a new state, it issues an Info log message indicating the time and the transition made. Is there a way of disabling those messages?.

I have read the following related questions, but found no answer to this problem:

http://answers.ros.org/question/10299/rospy-logging/

http://answers.ros.org/question/10269/rospy-logging-configuration/

http://answers.ros.org/question/9802/change-python-node-log-level-while-running/

In this page http://www.ros.org/wiki/move_base it is explained how the recovery behaviors are activated.

I would like to know which are the criteria that activate any of the recovery behaviors included in the recovery_behaviors.yaml file?

I had a similar problem with with LMS111. I discovered that the publish rate on the laser was simply too high. To solve the problem, I loaded the manufacturer's software (a Windows program) and turned down the frequency of the laser. I believe that I dropped it from its default 50Hz to 25Hz. It has worked without fail since then.

To address the disconnection problem, you could add a check to queryStatus() every so often, and if no messages are received, you could disconnect() and then login(). I haven't needed this functionality, but it's just my thought on the matter.

Also, it is not uncommon for the laser to take ~30 seconds to begin publishing to the ROS graph properly. While this only happens once in a while, don't panic if you see it.

~ Brian

Thank you Brian for your answer. I made the change on the laser configuration and tested the laser along yesterday. It looks like the problem is solved. Thank you for your help!

Ricardo

Hi all,

I am using the RCPRG_laser_drivers pkg to obtain laser measurements from a sick LMS-100 laser and from a sick LMS-151 laser (each laser on a different robot, no connection between them at all).

The thing is that the laser topic stops generating messages after a while ('rostopic echo /LMS1xx/LAS_00' returns nothing when the node fails). In both cases.

Does anybody have experienced this problem?. Any suggestion how to trace this problem?

I am using Diamond Back with Ubuntu 10.04. Some weeks ago I was using CTurtle with the same laser package and I had no problem at all (tested along weeks).

Some tests I've made:

• You can ping the laser once it starts to fail, even if it is not generating any message from the laser
• If the node fails, you can kill the node and restart it again, and the flow of messages will start again without problem
• I've observed that the node cannot recover from a disconnection of the laser. If you disconnect the ethernet cable to the laser, the node cannot reconnect to the laser and keep generating messages once you put the cable back. Only option is to restart the node
• I've also checked that when the node stops generating messages, there is no disconnection at all (I used a ping -f to the laser while the node was active. Once the node failed, I checked the report of ping -f (Ctrl-C) and said 0% packet loss, so there was no disconnection at all)

Any idea, comment, suggestion, bad joke, will be welcomed (specially the last one... I need jokes now :-(

Best

Ricardo