Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
322 Views

NCS2 in docker container on RPI results in RuntimeError: Can not init Myriad device: NC_ERROR

Jump to solution

I have been using two test platforms: RPI3B+ running Ubuntu 20.04LTS and a RPI4B running Raspbian.  Both exhibit exactly the same problem.

I have a simple test program that runs OK on the RPI hosts but fails when run in a docker container (built FROM ubuntu:bionic):

 

E: [ncAPI] [     85611] [python3] ncDeviceOpen:1003     Failed to find booted device after boot
Traceback (most recent call last):
  File "debug.py", line 34, in <module>
    sys.exit(main() or 0)
  File "debug.py", line 30, in main
    exec_net = ie.load_network(network=net, device_name=device)
  File "ie_api.pyx", line 178, in openvino.inference_engine.ie_api.IECore.load_network
  File "ie_api.pyx", line 187, in openvino.inference_engine.ie_api.IECore.load_network
RuntimeError: Can not init Myriad device: NC_ERROR

 

lsusb output on the host is:

 

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 033: ID 03e7:2485 Intel Movidius MyriadX
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

In the container running on that host the lsusb output shows the device but not the associated name:

 

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 033: ID 03e7:2485
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

The container was adapted from the openvino instructions  for building docker images.  I saw the error when running using the suggested:

 

docker run --privileged -v /dev:/dev --network=host openvino-debug

 

So I tried solution 2 in the instructions and built a libusb without UDEV support but also had the same problem.  When it crashes I was also no longer able to run the test program on the host - it would also terminate with the same error.

I noticed that despite following the instructions, the libmyriadPlugin.so was still dependent upon the shared library pointed to by /lib/arm-linux-gnueabihf/libusb-1.0.so.0 (as was lsusb).  [I also had to run libtoolize before the bootstrap.sh execution otherwise it would fail.  I wonder if those instructions are correct for all linux variants?]

I changed that link to point to the libusb built and installed into /usr/local/lib.  Now I still get the same error but if I run the test program on the host it still succeeds.  So at least it isn't crashing the NCS2 but I am unable to run in the container and don't know what to do to fix it.

0 Kudos

Accepted Solutions
New Contributor I
194 Views

This worked first time, thanks!  I have also gone back and managed to create working images based on ubuntu:bionic.  I then went on to try and incorporate the udev workaround described here.  That did not work because, for whatever reason, the library /lib/arm-linux-gnueabihf/libusb-1.0.so.0 does not link to the newly compiled library with udev disabled.  If you fix that by:

ln -fs /usr/local/lib/libusb-1.0.so.0.1.0 /lib/arm-linux-gnueabihf/libusb-1.0.so.0

Then you can start the container with a cgroup rule to avoid using --privileged as the instructions suggested:

docker run -it --device-cgroup-rule='c 189:* rmw' -v /dev/bus/usb:/dev/bus/usb <image_name>

 Works fine, even if you remove and reinsert the stick.

Thanks!

View solution in original post

0 Kudos
6 Replies
Highlighted
Employee
311 Views

Hi Hawkes__Rycharde,

Thanks for reaching out. Could you please answer the following:

  • Which OpenVINO™ toolkit version are you using?
  • Have you tried with a docker image in a Linux machine, or just with Rpi?
  • Could you share the sample program you are using for us to reproduce your issue on our end?

Best regards,

David C.


0 Kudos
Highlighted
New Contributor I
293 Views

Hi David,

I'm using 2020.03.220 (downloaded as l_openvino_toolkit_runtime_raspbian_p_2020.3.220.tgz).  No, I haven't tried the docker images on anything other than those RPIs.  

The test program uses the face-detection-adas-0001 model:

import sys
import os
import logging as log
from openvino.inference_engine import IENetwork, IECore

def main():
    log.basicConfig(format="[ %(levelname)s ] %(message)s", level=log.INFO, stream=sys.stdout)

    device = "MYRIAD"
    model_xml = "face-detection-adas-0001.xml"
    model_bin = os.path.splitext(model_xml)[0] + ".bin"
    ie = IECore()
    net = ie.read_network(model=model_xml, weights=model_bin)

    log.info("Loading Inference Engine")
    log.info("Device info:")
    versions = ie.get_versions(device)
    log.info("{}MKLDNNPlugin version ......... {}.{}".format(" "*8, versions[device].major, versions[device].minor))
    log.info("{}Build ........... {}".format(" "*8, versions[device].build_number))

    input_blob = next(iter(net.inputs))
    n, c, h, w = net.inputs[input_blob].shape
    log.info("inputs {}, {}, {}, {}".format(n, c, h, w))

    out_blob = next(iter(net.outputs))

    log.info("Loading model to the device")
    exec_net = ie.load_network(network=net, device_name=device)


if __name__ == '__main__':
    sys.exit(main() or 0)

Obviously, it fails on the load_network() call.

Thanks,

Rych

 

0 Kudos
Highlighted
Employee
289 Views

Hi Hawkes__Rycharde,

Thanks for the information provided. We tested a docker image in a Raspberry Pi 4B with Raspbian GNU/Linux 10 (buster) and it worked successfully. Also, the lsusb command showed the same output on both host and container.

Try to follow this guide and tell us if the issue persists.


Best regards,

David C.


0 Kudos
Highlighted
New Contributor I
236 Views

Unfortunately, those instructions didn't yield a working image either.   The example dockerfile has a typo and the test images can't be fetched as required because they are hidden by a captcha, but fixing those issues still yields an image that exhibits the same problem using the two test applications.

In the container, lsusb gives:

 

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 03e7:2485 Intel Movidius MyriadX
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

So that's promising, but, for example, running openvino_fd_myriad.py results in:

 

E: [ncAPI] [    260210] [python3] ncDeviceOpen:844      Failed connection to device (1.1.3-ma2480) with error 7
Traceback (most recent call last):
  File "openvino_fd_myriad.py", line 9, in <module>
    out = net.forward()
cv2.error: OpenCV(4.1.1-openvino) /home/jenkins/workspace/OpenCV/OpenVINO/build/opencv/modules/dnn/src/op_inf_engine.cpp:477: error: (-215:Assertion failed) Failed to initialize Inference Engine backend: Can not init Myriad device: NC_ERROR in function 'initPlugin'

 

lsusb after the crash shows:

 

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 010: ID 03e7:f63b Intel
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

And the details for the NCS2 are now truncated.  After this I can't even run on the host without the same error.  [If I run the container using --device /dev/bus:/dev/bus rather than -v /dev:/dev --privileged, then I get the same error but I can still run apps successfully on the host after failure in the container.]

I am using a fully up-to-date Raspberry Pi 4B with Raspbian GNU/Linux 10 (buster). 

Have you built and run the image in the guide you sent me?

0 Kudos
Highlighted
Employee
221 Views

Hi Hawkes__Rycharde,

Thanks for your reply. Please try using the Dockerfile attached (which is using the latest OpenVINO™ toolkit version and the 2019.R3 face-detection-adas-0001 IR files). Follow the instructions from the guide provided and remember the path to the build directory for this installation is now:

/opt/intel/openvino/deployment_tools/inference_engine/samples/cpp/build

We tested it on a Raspberry Pi 4B with Raspbian GNU/Linux 10 (buster) and it worked. Let us know if  you have any issues during the installation.

Best regards, 

David C.

0 Kudos
New Contributor I
195 Views

This worked first time, thanks!  I have also gone back and managed to create working images based on ubuntu:bionic.  I then went on to try and incorporate the udev workaround described here.  That did not work because, for whatever reason, the library /lib/arm-linux-gnueabihf/libusb-1.0.so.0 does not link to the newly compiled library with udev disabled.  If you fix that by:

ln -fs /usr/local/lib/libusb-1.0.so.0.1.0 /lib/arm-linux-gnueabihf/libusb-1.0.so.0

Then you can start the container with a cgroup rule to avoid using --privileged as the instructions suggested:

docker run -it --device-cgroup-rule='c 189:* rmw' -v /dev/bus/usb:/dev/bus/usb <image_name>

 Works fine, even if you remove and reinsert the stick.

Thanks!

View solution in original post

0 Kudos