M
mikegardner

  • Sep 25, 2024
  • Joined Aug 13, 2021
  • 0 best answers
  • @mikegardner

    The file that is used to provide this can be found by doing python -m pip show depthai and using the Location to see the filed under directory [Location]/depthai/__init__.pyi and node.pyi

    Regarding getFrame that could be fixed by specifying that DataOutputQueue.get could return ADatatype OR any of its descendants (As of right now, the typed information doesn't point to that, so IDEs cannot know that it might return subclasses as well). That could be done using overloads, similarly to Pipeline.create.

    If you'd like to check it out how these are done, see depthai-python/generate_stubs.py. It uses stubgen and mypy to check if stubs can be parsed correctly.

    Any improvements are welcome🙂

    Regarding VSCode, it AFAIK uses a different typing system underneath and it might have more issues without any additional configuration. I've only tested it briefly there.

    Best regards,
    Martin

    • Hi @mikegardner

      XLink is the dependency that provides communication between DepthAI host and our devices.
      Its dependent on libusb, but doesn't include it by itself. (Might do in future, TBD)

      As XLink is 3rdparty dependency and it unfortunately isn't well written to cover wide range of different environments, so you'll have to help XLink find the libusb library.

      To do that, you should add to a toolchain file, which specifies various cross compilation options already like:

      • Which compiler
      • Path to rootfs
      • ...

      The paths to target device libusb library using CMake variable like CMAKE_PREFIX_PATH or CMAKE_SYSTE_PREFIX_PATH (https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html) which is used by find_path and find_library calls in XLink.
      Or directly setting LIBUSB_INCLUDE_DIR and LIBUSB_LIBRARY variables to the their respective paths.

      Eitherway, you'll need the before mentioned toolchain and apply it while compiling the example using -D CMAKE_TOOLCHAIN_FILE=[path/to/toolchain] as well as having the actual library (ARM binaries not host x86_64) available somewhere for the CMake to find them (preferably you just install on the system itself using apt-get and then find them in the mounted rootfs of RPi.

      Let me know how it goes,
      Martin Peterlin