scan array values

[radu-diaconescu13]

Hello,

Thank you for the nice dataset!
I have two questions about it:

1. I have seen in the paper that the sensor Hokuyo UTM-30LX was used
   which, from I saw in the specs sheet, has the scanning range of 0.1 to 30m.
   This is would make me expect that the max values of distances in the scans would be 30.
   However, there seems to be quite a few points with distance bigger than 30 m as can be seen in the histogram.
   Is there a reason for this? Were these values treated differently somehow?

2. I found quite a few values of inf and nan in the scans and I am not quite sure how to handle them.
   I am trying to train the DR-SPAAM network with the code from here
   https://github.com/VisualComputingInstitute/2D_lidar_person_detection
   but the cutout creating part is failing because of these inf and nan values.
   Do you have any suggestion on how to deal with these values?
   In the DROW dataset they replace the nan with the "magic" value of 29.96
   but there is no mention of how to deal with inf values.

Thank you

[feramozur]

Thank you for your interest on the FROG dataset. Regarding your questions:

1. According to the Hokuyo UTM-30LX specifications, the detection range is "0.1 to 30m(White Square Kent Sheet 500mm or more),Max.60m". In particular, the environment at the Alcázar contains many dimly lit areas, and as such high reflectivity objects will be more easily visible at distances beyond 30m; so it is perfectly normal and within spec for those points to be returned by the sensor. In any case, we only consider a maximum distance of 10m for person annotations and also in the detectors, so these points are anyways ignored.
2. We modified the DROW3/DR-SPAAM codebase you linked to in order to evaluate those detectors on the FROG dataset. Here is a patchfile containing our changes: https://robotics.upo.es/datasets/frog/laser2d_people/data/drspaam-frog-support.patch

I hope this answers your questions.

[radu-diaconescu13]

Hello,

Thank you for the answers.

I tried the code you shared, but I am running into the issue of having loss as nan.
From what I can tell, the issue is the presence of infs and nans in the dataset.
How was this issue handled on your side?

Thank you

Later edit:
I have replaced the nan's and inf's with 59.99 because its close to maximum distance and tried to overfit an example. It seems to learn the ground truth, but there are also a lot of false positives (light green), as can be seen in the screenshot. Did you use a specific loss to combat this or just the binary cross entropy that is available in the repo?

[feramozur]

We recently discovered that the training/validation file we uploaded was an incorrect version; and we reuploaded the file. Could you please try training the network again?

[radu-diaconescu13]

Thank you @feramozur

I will try it later this week.

Can you please tell me difference between this one and the old one?

Thank you

[feramozur]

There was an error in the dataset post-processing script that caused the circle list->scan assignments to be incorrect. We replaced the incorrect file with the version that we used for training all detectors.

[radu-diaconescu13]

Hello @feramozur

I have trained with the data you mentioned and got comparable results to the one in the paper for single scan DR-SPAAM.
Thank you!

I have another issue. I have tried to train a DR-SPAAM using 5 scans and both training and inference time are a lot longer.
The issue is because of the for loop in line 102 in https://github.com/VisualComputingInstitute/2D_lidar_person_detection/blob/master/dr_spaam/dr_spaam/model/dr_spaam.py

In the FROG paper i see similar values for run times for these networks.
How did you resolve the issue of the linearly increasing execution based on the number of scans used?
Thank you

[feramozur]

We tested the ROS node provided in the same repo, and it is entirely possible that there are other aspects of the implementation bottlenecking the output rate in a way that masks the difference in processing speed between T=1 and T=5 for DR-SPAAM. We were unable to test the more efficient "DR-SPAAM*" implementation mentioned by the authors in their paper because, to the best of our knowledge, it is not published.