Invalid unit-vector from the O3D sensor at 0, 0

[bc-jmoork]

For some reason the first unit-vector for our latest O3D camera (with larger FOV) is invalid.

unit_vector[0, 0, :] = array([ 0.00000000e+00, 7.21781871e+14, 1.04866115e-28]

The value of e+14 is impossible and should not be present in the unit-vector. Our current fix or hack is to set the unit-vector for [0, 0] to the value in [0, 1]

HW info from o3d3xx-dump is shown below:

    "HWInfo":
    {
        "Mainboard": "#!02_M381_003_02888804_008022954",
        "Illumination": "#!02_I300_001_02895643_008001175",
        "MiraSerial": "1070-5908-00b4-08d0",
        "MACAddress": "00:02:01:40:65:12",
        "Frontend": "#!02_F342_C34_17_00012_008023607",
        "Diagnose": "#!02_D322_C32_02879150_008023267",
        "Connector": "#!02_A300_001_02870331_008001175"
    }

[graugans]

@bc-jmoork could you please be so kind and provide the software version and the article number from the dump?

o3d3xx-dump | jq '{"Article": (.o3d3xx.Device|.ArticleNumber), "Version":(.o3d3xx.SWVersion|.IFM_Software)}'

The output looks like:

{
  "Article": "O3D303",
  "Version": "1.8.1330"
}

[bc-jmoork]

Hi @graugans { "Version": "1.8.768", "Article": "" }

[bc-jmoork]

@graugans Any update on this?

[graugans]

@bc-jmoork could you please be so kind and send me the full dump, this empty article number looks a bit weired to me.

[bc-jmoork]

@graugans I updated the libo3d3xx from 1.42 to 1.50 and we are no longer seeing the issue with the unit vector. Thanks a lot for your assistance.

[tpanzarella]

@bc-jmoork I do not understand the version numbers you are citing. Where do you get 1.42 and 1.50?

[bc-jmoork]

@tpanzarella, I am sorry, we updated from v.0.42 to v.0.50 in libo3d3xx (https://github.com/lovepark/libo3d3xx/releases)

[tpanzarella]

Always be sure to consult the main README file at the top-level of this source distribution. It maintains a software compatibility matrix that maps versions of libo3d3xx to versions of the ifm firmware that have been tested to work properly. This table is rendered nicely at the source URL of this github repo.

Specific to this issue, I think the "fix" that corrected this was when libo3d3xx added support for the ifm image chunk headers version 2. Specifically, this support was added in 0.4.9. The ChangeLog has more details.