ML-TN-002 - Real-time Social Distancing estimation

From DAVE Developer's Wiki
Revision as of 09:04, 28 January 2021 by U0001 (talk | contribs)

Jump to: navigation, search
Info Box
NeuralNetwork.png Applies to Machine Learning


History[edit | edit source]

Version Date Notes
1.0.0 February 2021 First public release

Introduction[edit | edit source]

Because of the Covid-19 pandemic, everyone has learned to deal with the so-called "Social Distancing" rules very well. When it comes to spaces shared by many people — such as squares, public or private offices, malls, etc. — it is not easy to monitor in real-time the compliance with these rules.

Automatic systems that are capable to do the job have been developed. Most of them are implemented as software running on camera-equipped PC's making use of visual techniques. This is not a one-size-fits-all solution, however. In many cases, the use of a properly designed embedded platform is mandatory, for example, because of tight space constraints, harsh environment operability, or cost constraints — requirements that are typical for industrial-grade applications.

To date, though, the computing power required for algorithms that complex has represented a hurdle difficult to overcome, hindering the adoption of embedded platforms for these tasks. Recently, new system-on-chips (SoC's) integrating Neural Network hardware accelerators have appeared on the market, however. Thanks to such an improvement in terms of computational power, these devices allow the implementation of novel solutions satisfying all the above-mentioned requirements.

This Technical Note illustrates one of these implementations regarding the real-time social distancing estimation issue. This work started off the publicly-available open-source Social-Distancing project released by the Istituto Italiano di Tecnologia (IIT), which is illustrated in this paper. The goal was to port the IIT code onto a DAVE Embedded Systems Single Board Computer (SBC) powered by the i.MX8M Plus SoC. This industrial/automotive-grade SoC is built around a 4-core ARM Cortex A53 CPU and has a rich set of peripherals and systems. It also integrates a 2.3 TOPS Neural Processing Unit (NPU) and native interfaces to connect image sensors making it suited for this kind of applications.

The hardware/software platform[edit | edit source]

The hardware platform consists of:

  • SBC
  • TBD

Regarding the software platform, it is based on the NXP BSP TBD. In addition to the default packages, a number of libraries were added to satisfy the application's requirements.

Main application[edit | edit source]

As stated previously, the main application derives from the IIT Social-Distancing project. It was developed in several steps starting when only a few alpha samples of the i.MX8M Plus were available thanks to the fact that DAVE Embedded Systems joined the the component's beta program.

Step #1[edit | edit source]

The first step was conducted using the official evaluation kit (EVK) by NXP. The goal was to make the Social-Distancing project to work on this platform maintaining the core functionalities. In essence, the code was modified in order to replace the OpenPose library with PoseNet. This was required to cope with the operations actually supported by the NXP eIQ software stack and the NPU. For those who are familiar with embedded software development, this should be unsurprising. When porting applications from PC-like platforms to embedded platforms, in fact, handling such hardware/software constraints is a common practice.

The resulting processing pipeline is shown in the following figure.

Processing pipeline

The yellow box indicate processing performed by the ARM cores while the green one refers to the computation carried out by the NPU.

The following screenshots show the application running on the EVK.

The step 1 application running on the EVK (1/2)
The step 1 application running on the EVK (2/2)

It is worth remembering that, even though OpenPose was replaced, the software interface between high-level layers and PoseNet was not altered. This allowed to keep untouched these layers.

Step #2[edit | edit source]

Step #2 concerned implementing some optimizations in order to increase the overall frame rate.

Testing and results[edit | edit source]

Conclusions[edit | edit source]

Future work[edit | edit source]