• Author Author: ralphjy
  • Date Created: Date Created
  • Views 432 views
  • Likes 8 likes
  • Comments 4 comments
Related
Recommended

Omron HVC-P2 Roadtest - Application Results

ralphjy

When I first read about the Omron HVC-P2 roadtest I was excited about the possibility of implementing a security monitoring application with a camera/image processor that had human image recognition built in.  Based on the specs I thought I could monitor an area 20 feet deep by 10 feet wide (about the size of either the outside or inside entry area to my house).  I discussed the applicable parameters in my "Application Feasibilty" blog post.  As I've been testing the unit, I've come to doubt whether the unit could actually work in this application but thought that I'd give it a try.

 

I have a fairly straightforward implementation.  The HVC-P2 does all of the image processing internally and provides the detection result via a USB UART.  I added a Raspberry Pi Zero W to provide remote communication and control.  The RPi handles all the configuration and result processing for the HVC-P2.  Omron provides sample programs in C and Python.  I elected to use Python.

 

Basic Requirements:

1) Detect Human Body, Face or Facial recognition based on configuration

2) Perform some logic to determine if there is an alert condition

3) Send alert (initially just send email)

 

That's all I intended to implement.  If things worked well I could extend the functionality.

 

Requirement 1 is easy because that's the primary function of the HVC-P2.  Main concerns here are reliability and accuracy of detection (based on poor repeatability in static testing).

The provided Omron software provides an execution API that returns an hvc_tracking_result object that has all the relevant detection properties.

Here is the Class Diagram: I apologize that it isn't easily readable - you may have to copy the image if you are interested.

image

Just by way of example:

To initiate a detection sequence you just call the API execute function

    (res_code, stb_status) = hvc_p2_api.execute(output_img_type, hvc_tracking_result, img)

    and you get back the tracking_result and an image if that was enabled

 

In my application I write the tracking result to a log file and save the image.

    Here is an excerpt from the log file when I only had Body detection enabled:

 

          Image name: img_1_112418_164331.jpg

          Face Count = 0

          Body Count = 1

                Detection     X:1152 Y:416, Size:384 Conf:739

          Hand Count = 0

          ==== Elapsed time:270.56[msec] ====

 

    You can see the X, Y coordinates of the body center and the body size and detection confidence

     I also timestamp the image because I need to post process the image to insert the detection bounding box.

     I don't process real time to not slow down the detection frequency.

 

Here is the post processed image that corresponds to this log result:

image

 

One interesting aspect is that the application has to initiate the detection process.  So, for continuous detection it has to always stay in a loop.

 

It is also easy to satisfy the requirement for creating alert logic by using the hvc_tracking_result properties.

    e.g. hvc_tracking_result.bodies is the array of bodies that has been detected, so that len(hvc_tracking_result.bodies) >= 1 indicates that a body has been detected

I'm not doing any specific processing, but I could use the x,y position to determine if a body were in an off-limits location or moving inappropriately.

 

Once an alert condition is encountered then I send an email with the alert condition and also attach the detection image.

To send the email from the RPi I needed to use the smtplib and to attach the image I needed to use MIME.  I used my account at zoho.com to do the mail forwarding.

 

image

 

So, here's the punchline.......  I ran into a problem that I haven't solved that makes my application not usable.  And as a result I won't be able to do any performance testing unless I can find a workaround.

 

You can see from my log result that the detection time was 270 msec which might be marginal for a moving target.  However, as I looked at the timestamps of sequentially captured images, I realized that the images were only being captured about every 4 seconds.  I put a debug timer in the loop and measured about 4500 msec.  I discovered that the culprit was the save of the captured image using the GrayScaleImage() function from the Omron software.  I have to do some further testing - it may be an issue with using the SD card on the RPi for storage.  It definitely correlates to the amount of data being stored.  The 4500 msec was to save a 320x240 pixel image.  It reduced to 1200 msec with a 160x120 pixel image.

 

At this point, I think I'm going to work on my review summary.  I believe that even without this last glitch that the HVC-P2 probably isn't a good fit for what I had intended.  I think that the lack of certain features combined with poor repeatability will limit the scope of its usability.  I'll cover that in my review.

  • in reply to ralphjy

    Nice to see you published the RoadTest Review with your fair assessment of the product. Indeed, you have put in a lot of effort - I haven't had the time to follow everything you've written but it seems that their code support is indeed somewhat lacking.

     

    Good to see it a bit snappier on a Win10 machine, but I'd have to say that nowadays, perhaps software-based solutions (e.g. OpenCV) running on a small computer may offer better value for money and some embedded devices can offer a decent power consumption too, so proprietary solutions like this may not be as flexible or preferable in the long run.

     

    - Gough

  • in reply to Gough Lui

    - just a quick update I haven't had a chance to run this on a Linux box yet because I am having 32/64 bit issues.  I'll probably need to do a 32 bit install on my laptop.  I did try this on a Win10 box that I used to execute the Python code earlier.  The overhead for saving the image is 200-250ms rather than the 4s that I am seeing on the RPi0W, so I'm going to have to do some further investigation.

  • in reply to Gough Lui

    - thanks for the comments.  I have to admit that I'm perplexed by the data.  Must be making a mistake somewhere.  The timer for the detection time starts right before the call to the execute function and ends right after.

                start = time.time()

                (res_code, stb_status) = hvc_p2_api.execute(output_img_type, hvc_tracking_result, img)

                elapsed_time = str(float(time.time() - start) * 1000)[0:6]

    The execute function should return the image.  This all seems to be working as I expected (takes about 270 msec for body detection and less for face) but as you pointed out may not account for the the time to transfer the image at the max baudrate.  I am making the assumption that the image is transferring within the time window for that command.  When I include the time for the rest of the loop it goes to 4.5 secs.  If I just comment out the image save it goes back to 270 msec (alternately I can set the image type to NONE with the same effect)..

               #            if output_img_type != p2def.OUT_IMG_TYPE_NONE:

               #                img.save(img_fname)

    So, I tried altering the baudrate as you suggested (I had set it to max based on the sample code instructions).  Here is where I am confused - there is a perceptible change on the order of 200 ms, i.e. 4.5 -> 4.7 sec in the overall loop time as I change the baudrate to 115200, 38400, 9600.  I would have expected a much larger effect on the image transfer during the execute function.  It turns out that this time does not change.

     

    Anyway, I don't have a lot of time available this week to work on this.  I'll write up the review as I'm late already.  This problem doesn't change my overall impression of the device although it is something that would need to be fixed to use it.  I'll give it a try on a Linux laptop when I get a chance and post the result.  The data seems to tell me that I am misinterpreting what the code is doing, so it may not make a difference.

     

    Ralph

  • - just a thought when you mentioned that an image took about 4 seconds to save 320x240. I suspect this is an interface issue - 320x240 @ 8-bit = 76,800 bytes to transfer. At 4.5 seconds, this implies a transfer rate of ~170kbit/s (inc serial start/stop bit overhead). With the 160x120 image @ 8-bit/px = 19,200 bytes to transfer - at 1.2s, this is ~160kbit/s. So it does sound like you have a throughput bottleneck somewhere.

     

    I'm not familiar with the product but the datasheet seems to imply that there is a UART interface and a USB interface which is CDC compliant. In case it is not implemented by a USB-TTL bridge chip, maybe it would be worth hooking up the UART directly to a known good USB-TTL device (like a CP2102/FT-232) to see whether this helps. Also see the code if it's commanding the device to operate at the maximum 921600bps baud rate - although be warned that some devices could be "lost" if you command it to a baud rate you cannot then receive/transmit reliably. At that rate, I'd expect the 320x240 image to only take 0.83s to transmit over the bus assuming full utilisation.

     

    I would expect a Raspberry Pi to not have major issues with storing images, although the Python code could be consuming a lot of CPU time causing overhead. Most SD cards should easily handle a few MB/s. Perhaps try a laptop running Linux?

     

    - Gough