• Community

  • Building a C++ app without cmake issue

I made a simple visual studio project based on the sample project files in depthai-core and the C++ code for the spatial location example and combined it with downloaded core 2.17.4 and opencv 4.55. I don't have visual studio 2022 so it's 2019 and toolset 142.
The app runs, but something is "off" because x and y are always zero and z is larger than it ought to be. The colors also doesn't look like other snapshots of similar things in python.
Has anyone seen this before and knows what's wrong?

  • erik replied to this.

    Hi dexter ,
    Seems good to me. You are visualizing depth (not disparity), that's why it "looks" off. X/Y are calculated from Z, and if you move the ROI completely up/down/left/right it will change as well. Regarding Z accuracy - there are number of factors to consider, I'd start with docs here.
    Thanks, Erik

      Thanks for confirming that it looks ok!

      I have been running this a number of times and never seen any XY values other than zero until today when I tried again...
      I was starting to think that there was a mismatch with firmware. If I understood things correctly the device will get the correct firmware when the pipeline is connected to the device which ought to be 2.17.4 in my case. I find it confusing that the device manager (from 2.17.4) utility says that the current depthai version is 2.16.0.0 for my device.

      Do you think it would be feasible to get something similar to the gen2_ocr experiment converted to C++? I need to interface with other C++ project code so having all in C++ seems to be the easiest solution...

      Thanks!

      • erik replied to this.

        Hi dexter ,
        If you run device manager with python then try using python -mpip show depthai to check depthai version, you might have different environemnts (due to different python versions, or venv).
        Yes, depthai API is 1:1 when converting python to c++ (and vice-verca) so there shouldn't be any problem converting depthai code. You might get some challenges when converting logic that uses numpy though.
        Thanks, Erik

          Thanks, I'll give it a try and see if I can get through numpy.

          I searched for a c++ example of blobconverter.from_zoo without anything obvious popping out. How would that be done in c++?

          • erik replied to this.

            Hi dexter ,
            You can download the model from https://blobconverter.luxonis.com and use the blob with your app. ANother solution would be to rewrite the blobconverter library to c++ (it's a simple library that just calls the blobconverter server API and returns the downloaded file). Thoughts?
            Thanks, Erik

              Before I saw your reply I found the blobconverter tool and run it manually with the parameters from the code and got a local file. That local file seems to load fine using setBlobPath. At least for now that seems easier than rewriting the tool.
              Thanks!

              6 days later

              Hi - I'm running a similar configuration (core 2.17.4 and opencv 4.55. Visual Studio 2019 toolset 142) on a similar project.
              The project compiles cleanly (in Debug mode) but I run into an exception executing
              auto monoLeft = pipeline.create<dai::node::MonoCamera>();
              The exception comes from line 89 in Pipeline.hpp
              nodeMap[id] = node;
              I'm wondering whether there is a compiler setting that I may have missed that you may be aware of.
              Thanks!

                Hi GeorgeVP
                I got it to work with fairly small changes compared to a standard C++ vcxproj file.
                Both debug and release have an additional "XLINK_USE_MX_ID_NAME=ON;PC=ON" to the preprocessor defs.
                Added "d" versions of the libs to the debug build and the ones without to release.
                Then running x64 worked for both debug and release.

                  Thanks for that. Using the correct libraries to link to was the key. I had inadvertently linked to the Release libraries. I am testing a RealSense D415 and the Oak D and the RealSense support is better in C++. So I now have the application for the Oak D working in C++. The Python version had been running so I was certain it was something straight forward, overlooking the use of the Debug libraries was a bit of a blunder.