How to interpret the meaning of scan_msg?
Hi,
This might be a silly question but I have a small doubt regarding the scan_msg in the Laser_scan topic. I am using SICK LMS-200 laser scanner with Pioneer3DX robot for navigation. As I run my code, I notice that the rostopc /scan tells me that scan_time = 0.013s whereas if I check the computation time within my code using something like ros::Time::now().toSec() (present time - past time) I notice that it takes at least 0.1s between each Callback. I am slightly confused as to why there is a difference between the two as the code that I am running is pretty simple and just prints out the elements of the messages in the /scan topic. One guess at it would be that when I run ros::spin(), it goes through all the topics and this takes time. But considering I am not calling any other topic, I am not sure whether this is the reason. Could anyone please help me in understanding what exactly is this scan_msg and why is it different from the Callback time period? Thanks a lot in advance.
Here is the code snippet:
void scanCallback (const sensor_msgs::LaserScan::ConstPtr& scan_msg)
{
size_t num_ranges = scan_msg->ranges.size();
std::cout<<"Number of range values: "<<num_ranges;
std::cout<<"\nangle_min: "<<scan_msg->angle_min;
std::cout<<"\nangle_max: "<<scan_msg->angle_max;
std::cout<<"\ntime_increment: "<<scan_msg->time_increment;
std::cout<<"\nscan_time: "<<scan_msg->scan_time;
std::cout<<"Time difference: "<<ros::Time::now().toSec() - present_time<<"\n";
std::cout<<"\nNow looking at the ranges**************************** \n";
present_time = ros::Time::now().toSec(); // for timing calculation
std::cout<<"\nFinishing one scan";
}
int main(int argc, char** argv)
{
ros::init(argc, argv, "laserdata");
ros::NodeHandle n;
ros::Subscriber scan_sub = n.subscribe("scan", 100, scanCallback); // I changed buffer rate over here
ros::spin();
}
On adding the header and executing the code, I get the following output:
Number of range values: 181
angle_min: -1.5708
angle_max: 1.5708
time_increment: 3.7037e-05
scan_time: 0.0133333
Header seq: 13070
stamp: 1405978337.781919948
frame_id: laser
Time difference: 0.107676
Finishing one scan
Also, on checking the rostopic hz /scan (with and without running my code), I get the following
average rate: 9.378
min: 0.106s max: 0.108s std dev: 0.00049s window: 9
average rate: 9.374
min: 0.106s max: 0.108s std dev: 0.00069s window: 19
average rate: 9.372
min: 0.106s max: 0.108s std dev: 0.00076s window: 28
average rate: 9.372
min: 0.106s max: 0.108s std dev: 0.00073s window: 38
average rate: 9.371
min: 0.106s max: 0.108s std dev: 0.00077s window: 47
average rate: 9.373
min: 0.106s max: 0.108s std dev: 0.00078s window: 56
average rate: 9.373
min: 0.106s max: 0.108s std dev: 0.00076s window: 66
what is the buffer size you are using in subscriber ? Increase it and check the difference.
Even if I increase the buffer size, it makes no difference
can you post your code, as mentioned in below answer rostopic hz /scan should work.
I have posted the code snippet. As you will see, it is a very simple code to just check the timing for obtaining the laser data. There must be something very silly which I might be overlooking.
Also you can print scan_msg->Header.seq to verify sequence, and increase buffer to 1000. and as mentioned below you should able to get rostopic hz /scan which should be your expected frequency.
I made the changes as you mentioned. Even after increasing the buffer to 1000, I still get "Time Difference = 0.1s". Can you shed some light into this. I have provided all the outputs and other things that might give you more information. Thanks
you are getting messages at around 9.3 hz, . you can print scan_msg->Header.seq for messages and can find if you are getting all the messages or missing some. Header.seq filed shows sequence number of message. can you find messages are coming slow or some messages are dropped.
According to the rostopic hz output it seems that messages are only being sent at 10 Hz. This looks like it's maybe some setting in the driver limiting that. It's very likely not your code.