Rosanswers logo

Hi everyone !

I am currently working on LaserScan messages and I don't quite understand how time related attributes should be filled. If I look at the documentation :

Header header            # timestamp in the header is the acquisition time of 
                     # the first ray in the scan.
                     # in frame frame_id, angles are measured around 
                     # the positive Z axis (counterclockwise, if Z is up)
                     # with zero angle being forward along the x axis
float32 angle_min        # start angle of the scan [rad]
float32 angle_max        # end angle of the scan [rad]
float32 angle_increment  # angular distance between measurements [rad]

float32 time_increment   # time between measurements [seconds] - if your scanner
                         # is moving, this will be used in interpolating position
                         # of 3d points
float32 scan_time        # time between scans [seconds]

float32 range_min        # minimum range value [m]
float32 range_max        # maximum range value [m]

float32[] ranges         # range data [m] (Note: values < range_min or > range_max should be discarded)
float32[] intensities    # intensity data [device-specific units].  If your
                         # device does not provide intensities, please leave
                         # the array empty.

I understand that scan_time is the total duration of one scan (i.e. duration of my n measurements) and that time_increment is the duration of one measurement (so scan_time = time_increment x n).

But then, I began to play around with this bag file, which replay Laser Scan messages (https://github.com/mlab-upenn/f1_10_code_public/tree/master/Week%203), and I realized that my assumption are not right. By doing :

rostopic echo /scan

I got one of the message:

  seq: 40906
    secs: 1458504920
    nsecs: 148172000
  frame_id: "laser"
angle_min: -1.57079637051
angle_max: 1.56643295288
angle_increment: 0.00436332309619
time_increment: 1.73611115315e-05
scan_time: 0.0250000003725
range_min: 0.0230000000447
range_max: 60.0

I know I have n=720 measurements, because I watched for ranges size and because:

full_angle/angle_increment = (1.56643295288+1.57079637051) / 0.00436332309619 = 719 (+ 1 for the first element).

But when I do the same with time, I get 2 x n as result:

scan_time/time_increment = 0.0250000003725÷1.73611115315×10^05 = 1440

So why is that ? Am I missing something ?

This bag file seems correct, beacause I managed to reproduce the simulation as the author did in a video (https://www.youtube.com/watch?v=3C_eRtSoU78).

Originally posted by erenaud on ROS Answers with karma: 28 on 2018-05-16

Post score: 1


1 Answer 1


Rosanswers logo

scan_time will only be equal to time_increment x number_of_samples if it is a full 360 degree scan.

In the case of the message you showed it is only a 180 degree scan therefore the scan time is twicetime_increment x number_of_samples.

As described scan_time is # time between scans [seconds] not the duration of the scan. Think of scan time as the time taken for a full rotation of the sensor even if it's only producing data for part of that revolution.

Originally posted by PeteBlackerThe3rd with karma: 9529 on 2018-05-16

This answer was ACCEPTED on the original site

Post score: 4

Original comments

Comment by erenaud on 2018-05-17:
Oh okay, thanks ! So does it mean that a device that produces laser scan messages MUST be constantly rotating ? So I can't have a laser travelling from -pi/2 to pi/2 ? If yes, can I have a laser measuring from -pi/2 to pi/2 and then pi/2 to -pi/2 and so on ?

Comment by erenaud on 2018-05-17:
I have another question. Let's say I have a laser scan that is actually doing a full 360° scan. But when placed below the robot, the wheels are obstrucating parts of the field. Let's say that I can't scan from -pi/4 to -3pi/4 and pi/4 to 3pi/4. What should I do then ? Several messages ? Use filters?

Comment by PeteBlackerThe3rd on 2018-05-17:
All of the real world laser scanners I can think of have a rotating element, the mechanics of these sensors has driven the design of this sensor message.

Comment by PeteBlackerThe3rd on 2018-05-17:
As described in the message definition the scan time is the time between scans, it doesn't make any assumptions about how they are produced so you could scan from -/+ pi with no delays using a rotating prism design. Some high performance 3d scanners do just this.

Comment by PeteBlackerThe3rd on 2018-05-17:
Finally if you had a 360 degree scanner under your robot then you don't need to do anything. If the wheels are closer than the minimum sensing distance there will simply be null values for those samples.

Comment by erenaud on 2018-05-17:
Okay, thank you for your help !


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.