element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
RoadTests & Reviews
  • Products
  • More
RoadTests & Reviews
Blog Omron HVC-P2 Roadtest - Application Results
  • Blog
  • RoadTest Forum
  • Documents
  • RoadTests
  • Reviews
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join RoadTests & Reviews to participate - click to join for free!
  • Share
  • More
  • Cancel
  • Author Author: ralphjy
  • Date Created: 25 Nov 2018 4:18 AM Date Created
  • Views 566 views
  • Likes 8 likes
  • Comments 4 comments
Related
Recommended
  • omron roadtest
  • image recognition

Omron HVC-P2 Roadtest - Application Results

ralphjy
ralphjy
25 Nov 2018

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.

  • Sign in to reply

Top Comments

  • ralphjy
    ralphjy over 6 years ago in reply to Gough Lui +2
    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…
  • ralphjy
    ralphjy over 6 years ago in reply to Gough Lui +2
    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…
  • Gough Lui
    Gough Lui over 6 years ago in reply to ralphjy +1
    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…
  • Gough Lui
    Gough Lui over 6 years ago 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

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • ralphjy
    ralphjy over 6 years ago in reply to Gough Lui

    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.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • ralphjy
    ralphjy over 6 years ago in reply to Gough Lui

    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

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Gough Lui
    Gough Lui over 6 years ago

    ralphjy - 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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube