Cannot initialize with sensor status: ERROR. Please ensure operating mode is set to NORMAL

[fraserdrops]

Summary
Ouster OS1 sensor gets into an ERROR state for an unknown reason

Setup

Model: OS-1-64
Firmware: v2.3.0
Python SDK version: 0.4.0
OS: Windows 11

(note, I've been testing another OS-1-64 sensor and a OS-0-32-U1 and they've both had this issue)

Scenario

I am running python code that is similar to the open 3d viz example

Most of the time, this works fine. Sometimes, the sensor gets into an error state and several client methods return this error
Cannot initialize with sensor status: ERROR. Please ensure operating mode is set to NORMAL

When the sensor gets into this state, some of the client methods throw the above error, including
client.Scans.stream(hostname, lidar_port, complete=False)
client.Sensor(hostname)

however,
client.get_config(hostname)
does still work.

Interestingly, get_config reports that the sensor is in NORMAL mode

client_config: {
    "azimuth_window":
    [
        0,
        360000
    ],
    "columns_per_packet": 16,
    "lidar_mode": "1024x10",
    "multipurpose_io_mode": "OFF",
    "nmea_baud_rate": "BAUD_9600",
    "nmea_ignore_valid_char": 0,
    "nmea_in_polarity": "ACTIVE_HIGH",
    "nmea_leap_seconds": 0,
    "operating_mode": "NORMAL",
    "phase_lock_enable": false,
    "phase_lock_offset": 0,
    "signal_multiplier": 1,
    "sync_pulse_in_polarity": "ACTIVE_HIGH",
    "sync_pulse_out_angle": 360,
    "sync_pulse_out_frequency": 1,
    "sync_pulse_out_polarity": "ACTIVE_HIGH",
    "sync_pulse_out_pulse_width": 0,
    "timestamp_mode": "TIME_FROM_INTERNAL_OSC",
    "udp_dest": "fe80::dd32:5d1:30f5:9404",
    "udp_port_imu": 7503,
    "udp_port_lidar": 7502,
    "udp_profile_imu": "LEGACY",
    "udp_profile_lidar": "LEGACY"
}

This occurs even when using the exact same example code, which was previously working before the sensor entered the ERROR state:
Streaming Live Data
Visualization with Open3d

Fix

The current fix is to turn the power off to the sensor then back on. Then the same code starts working again.

Issue

I'm trying to work out what is causing the sensor to enter this state, especially what code I might be running that is triggering it. Any help is much appreciated!

[kairenw]

I'm guessing that this is not an issue at the SDK level, but is something on the sensor itself. It's hard to know for sure, however!

The easiest thing you can do is collect a diagnostic bin for us (go to your sensor homepage at os-XXXX.local or the IP address assigned to your sensor and click the "Diagnostics" tab. That'll let us know what sorts of errors/alerts are coming off the sensor. Then submit the diagnostic bin and a link to this issue at our sensor technical support.

Thanks! I'll leave this open for a bit in case you don't hear back.

[kairenw]

Hey @fraserdrops, did you manage to resolve the sensor issue? If so, I'll close this out

[fraserdrops]

Hi @kairenw ,

Thanks for your response! I just managed to get a diagnostics bin of the issue so I will lodge that with the technical support you linked. Perhaps we could keep this open until I hear back if that's ok?

My gut feeling is there's something my software is doing that is putting the sensor into this state, I'll just add a couple of extra details to explain why that is.

• The sensor runs fine without any issues normally. I can see this by inspecting it via Ouster Studio
• When running my software, the sensor seems to very quickly end up in this error state. It seems weird if it's a hardware issue that it would so frequently be entering this state?

[kairenw]

That's interesting! With that extra information, that seems likely. Tell you what, when you submit your diagnostics bin to our technical support, do you mind adding a zip of your code as well? (Any code related to interacting with sensor/client; downstream perception stuff is unnecessary). Link this GH ticket and say that I (kairenw) explicitly asked to be pulled in. I'll poke around and see if I can find anything aswell.

Will keep this open -- if you don't hear back or w/e on the ticket, poke us again here (:

[kairenw]

HI @fraserdrops,

Checking back on your internal support ticket, I think this is mostly resolved. Thanks for catching that bug with our print out - we'll update that in the future. Gonna close this out, but feel free to reopen if there's more issues.

[kairenw]

My apologies. I shouldn't have closed this since it's a bug we haven't fixed!

[kairenw]

Thank you again for this bug report. The error print out has been fixed in the latest push to master located here. Closing this out now.