Installation and OpenGl error

Hi!
I just bought a Zed Box and tried to run the global localization recording script in the samples (python).
I get the following error:
“ModuleNotFoundError: No module named ‘OpenGL’”.
I thought all the packages needed where already included in the installation, am I wrong? Which package should I install and how? I know it migth seem extremely trivial but I fear to mess up smth.
Bonus question, during installation I get the following error: onnx-graphsurgeon 0.3.12 requires onnx, which is not installed. Shall I worry?

Hi @Prospecto

All the needed packages should be installed, but there may have been a miss.

  • If you run pip install pyopengl, does it work afterward?

To be sure, you can also run the get_python_api.py located in your zed install folder (/usr/local/zed).

For your bonus question:

  • Does ZED Depth Viewer run correctly? (not Explorer, Depth Viewer)

Thanks for the support!
I have relaunched the get_python_api but it doesn’t install pyopengl (I wonder why).
By manually installing (pip install pyopengl) I didn’t get errors and the script runs.

I tried ZED Depth Viewer and it looks ok except that the “measure window” flashes (always black except some flashes of the room distances) unless I select SVGA (then it works).
The erratic behavior stops if I use the neural mode so I am assuming it depends on the quality of the depth map right? Can I just ignore the “onnx-graphsurgeon 0.3.12 requires onnx” error?

@Prospecto

I don’t recommend ignoring the error :sweat_smile:

You can try reinstalling jetpack via:
sudo apt install --reinstall nvidia-jetpack

You shouldn’t have to reinstall anything afterwards I think.

Will do but meanwhile I got an error. While running the global localization example (playback) I got the following error:

RuntimeError: Shader compilation failed: b’0:2(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.00 ES, and 3.00 ES\n’

I guess I should install a specific version of pyopengl, am I wrong? If so, which one it is and how should i cancel the previous installation?
Sorry for asking trivial questions but I am terrified of messing up dependecies/environment and not being able to recover.

@Prospecto

Sorry I didn’t mention it, yeah, you should install PyOpenGL 3.1.5 if you use Python before 3.10, and 3.1.6 for Python 3.10 or 3.11 (there could be an issue with Python 3.12).

I installed 3.1.5 version (I have python 3.8.10) with pip install PyOpenGL==3.1.5. Still getting the same error.
“RuntimeError: Shader compilation failed: b’0:2(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.00 ES, and 3.00 ES\n’”
Any clue? :frowning:

@Prospecto

Did you try reinstalling jetpack?

This error can come from installation issues.

Yea, I did it but still didn’t work, this guy over here got a similar problem. Shall i purge nvidia and reinstall the SDK? I fear to mess up the environment

Hi,
Installing nvdia-jetpack with the command from before is pretty safe. Purging nivida is not recommended if you don’t want to mess up the environment.
Can you tell us a bit more about your system?

  • Are you using your box remotely, for example with SSH or VNC
  • Are you in a conda virtual environment?

Hi thanks a lot for stepping in and sorry for the late answer.
I am not using the box remotely (even if I am planning to do so in the future with ssh).

I am not in a conda environment, I installed the sdk from “ZED_SDK_Tegra_L4T35.3_v4.1.0.zstd.run” by simply going into the download folder, making it executable (chmod +x ) and running ./ZED_SDK_Tegra… . Now I am launching the python files from terminal python3 examplexyz.py.

  1. Any solution to the
    “RuntimeError: Shader compilation failed: b’0:2(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.00 ES, and 3.00 ES\n’” ?

  2. Do i have to take some adjustements if I want to use the ZED box remotely?

Some more infos:
nvidia jetpack installed is 5.1.1
python3 version is 3.8.10

Thanks a lot for your time.

EDIT:
I downloaded the sample HERE and tried to playback it with the “zed/samples/global localization/playback/python/playback.py” sample and got the error described before:

RuntimeError: Shader compilation failed: b’0:2(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.00 ES, and 3.00 ES\n

Surprisingly If i run the “zed/samples/global localization/recording/python/recording.py” I don’t get the previous error but the I get following:
AttributeError: module 'pyzed.sl' has no attribute 'GNSS_CALIBRATION_STATE' .

I tried to substitute the line

            if current_geopose_satus == sl.GNSS_CALIBRATION_STATE.OK:
                viewer.updateGeoPoseData(current_geopose, zed.get_timestamp(sl.TIME_REFERENCE.CURRENT))

with

           if 1:
                print(current_geopose_satus)
                viewer.updateGeoPoseData(current_geopose, zed.get_timestamp(sl.TIME_REFERENCE.CURRENT))

just to make it run.
Now the program runs but I get the following message:

Ingest error occurred when ingesting GNSSData:  GNSS DATA COVARIANCE MUST VARY
CALIBRATION_IN_PROGRESS
CALIBRATION_IN_PROGRESS
CALIBRATION_IN_PROGRESS
....
....
Ingest error occurred when ingesting GNSSData:  GNSS DATA COVARIANCE MUST VARY

When I stop the acquisition it saves a svo2 file and json file (empty) and it always give me a core dump.
I’m a bit lost here :frowning: :frowning: :frowning:

Tried to run ZED diagnostic here’s the log, in case it’s useful…
dmesg.log (10.4 KB)

If more info needed please let know :frowning:

Hi,

About the OpenGL issue: I’m not sure why OpenGL is not working on it. When using it remotely, it’s normal that it does not work because the graphical context is not initialized, this is why I asked. If you don’t need OpenGL, you can just comment the relevant parts in the sample.

Now, about the GNSS sample itself. GNSS_CALIBRATION_STATE is an old API, and does not exist anymore. We need to update the sample. Now you can use GNSS_FUSION_STATUS instead.

The GNSS DATA COVARIANCE MUST VARY indicates that the covariance you are giving to the SDK is always the same. It’s not really an issue, but we output this message to “educate” people about giving right covariances matrices. Without covariance matrices, the fusion will not have the same quality.

If you are ingesting “dummy” covariance matrices, just alternate the values.

Thanks a lot for your answer.

The OpenGL would be really useful to check the recorded data, furthermore I would like to understand what’s wrong in my installation to avoid further errors. How can I check my installation is ok?

For what concerns the “GNSS DATA COVARIANCE MUST VARY” I do have some questions.
Right now I am using the code provided in your samples and I see that in gpsd_reader the covariance is specified as follows:

            position_covariance = [
                gpsd_data["eph"] * gpsd_data["eph"],
                0.0,
                0.0,
                0.0,
                gpsd_data["eph"] * gpsd_data["eph"],
                0.0,
                0.0,
                0.0,
                gpsd_data["epv"] * gpsd_data["epv"]
            ]

Basically it sets the diagonal terms using the standard deviation of the GPS (eph,epv) while it sets to 0 the cross terms. Shall I change this approach? How? (I am using the ublox included in the zedbox).
Do I have to move my system at the beginning? By how much? In the code there’s this comment:

# Get position into the GNSS coordinate system - this needs a initialization between CAMERA 
# and GNSS. When the initialization is finish the getGeoPose will return sl.POSITIONAL_TRACKING_STATE.OK

I couldn’t find positional_tracking_fusion_parameters.gnss_initialization_distance though and I am confused.
Furthermore, if I use the recording.py sample the json gnss file is always empty.
Finally when I try to replay the svo2 files I get a segmentation error, so I fear smth is wrong…

You are having the right approach, injecting the data from GPSD.
The GNSS DATA COVARIANCE MUST VARY may be a bug - the 4.1.1 that we will release in a few way will patch it. Actually, it’s just the string print that is wrong, not the actual error code.
If you print the error code as an int, you may obtain -9, which should be GNSS_DATA_NEED_FIX.

What gnss_status are you putting inside the GNSSData you ingest? We might have forgotten to put this in the python sample, but it is in the C++ one. basically, our SDK will reject the GNSSData if you don’t have a GNSS fix.

    enum class GNSS_STATUS {
        UNKNOWN = 0, /**< No GNSS fix data is available. */
        SINGLE = 1, /**< Single Point Positioning */
        DGNSS = 2, /**< Differential GNSS */
        PPS = 5,  /**< Precise Positioning Service */
        RTK_FLOAT = 4, /**< Real Time Kinematic Float */
        RTK_FIX = 3, /**< Real Time Kinematic Fixed */
}

I’m afraid our python sample are outdated on this, if you also encounter issues with playback / recording. We will provide a fix.

thanks for reaching out.
Yea i’m encountering multiple problems with these samples, thanks for taking care of it, how long will it be before 4.1.1?
Another question regarding the calibration between camera and GNSS. By how much should I move the system and how to perform this calibration? I couldn’t find any information about that in the docs.

4.1.1 will be very soon.
The calibration can be quite long, depending on your GNSS accuracy. For a non-RTK configuration, where GNSS position can make jumps up to a meter, the full calibration can take 50 meters. However it is a rolling calibration, meaning you’ll have data before the calibration ends, and it will be refined.