[Wheel Chair Detector] w/ RPLidar - cut_outs[i,:] = cv2.resize(window[None], (npts,1), interpolation=interp)[0] error: /home/followinspiration/opencv-2.4.9/modules/imgproc/src/imgwarp.cpp:1834: error: (-215) ssize.area() > 0 in function resize

[filipetrocadoferreira]

I'm trying to test the detector with RPLidar (with the real resolution (1º) and a virtual (0.5º, with duplicated beams). But i'm having an error in the function generate_cut_outs.

This laser sends 'inf' when does not have info and its max_angle is -3.14 and min_angle : 3.14 (weird right?)

[filipetrocadoferreira]

This seems to solve

s_np[s_np==np.inf] = 6 #or other big value

[Pandoro]

We only used SICK S300 with an angular resolution of 0.5º and I think we
cut off everything above 14m. So while 6m could work I'd maybe try
something bigger.

What will definitely not work though, is the max and min angle unless it is
a 360º laser. We use these two to create a laser field of view, which,
given your numbers, would be 2pi = 360º. Considering an angular increment
of 0.5º the detector will expect that there are 720 laser beams (I might be
off by one here, but this should not make it fail). Also in case it is a
360º laser, you might have artifacts on the boundaries since we never
assumed that the left and right border of the data are connected in any way.

On Wed, May 11, 2016 at 1:06 PM, filipetrocadoferreira <
[email protected]> wrote:

This seems to solve

s_np[s_np==np.inf] = 6 #or other big value

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#196 (comment)

[filipetrocadoferreira]

Yes I'm using 360º lidar with 1º resolution. And it has that strange feature of min_angle and max_angle being switched.

I'll create a "virtual" laser with 270º fov and 0.5º. How do you encode your max and min angle?

[Pandoro]

Aah! I didn't notice the flipped sign, that is weird indeed. The range should still be fine, but we never took the absolute value of the range in our code. This I guess suggests that the data is in a reverse order? It could still be valid, but I know that we didn't account for that.

For 270° it should be something like:

scan_msg.angle_increment = 0.00872664619237 #0.5°
scan_msg.angle_min = -1.96349537373 #-135°
scan_msg.angle_max = 1.96349537373 #135°

[filipetrocadoferreira]

Ok, doing that the results were not better. So i guess the only possibility is to train the classifier on this laser data.
Here in red - original laser data , green - virtual laser data.

[Pandoro]

Hmmm, this is hard for me to judge since I don't know what kind of stuff
the laser actually sees. The height of the laser also makes quite a big
difference. Our laser scanner scans at a height of approximately 37cm. You
might play around with the threshold to reduce false positives. The big
question is, is there actually a wheelchair or a walker in the field of
view of the virtual laser? Apart from that I can imagine that the laser has
just different characteristics, which would indeed mean that you might need
to retrain the model.

On Wed, May 11, 2016 at 3:51 PM, filipetrocadoferreira <
[email protected]> wrote:

Ok, doing that the results were not better. So i guess the only
possibility is to train the classifier on this laser data.
Here in red - original laser data , green - virtual laser data.

[image: drow]
https://cloud.githubusercontent.com/assets/14791576/15183135/b6bfc7a4-1787-11e6-9358-b998174f2009.png

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#196 (comment)

[filipetrocadoferreira]

Our laser is a bit higher(~50cm) and yes, there is a guy seated on a wheelchair. I guess it also depends on which wheel chair the detector were trained because Health Facilities' wheelchairs are very different from the "usual" ones.