Troubleshooting
Sensor Homepage and HTTP Server
The sensor HTTP server at http://os-991900123456.local/ provides system info, status, firmware version, diagnostics, configuration, and API documentation. See the web-interface section of this manual for more details.
Networking
Most initial connection problems stem from the sensor not receiving a valid IP address from the DHCP server or network switch. Check networking settings, the steps in connecting-to-sensor, and that all cables are firmly seated. The sensor stops sending data and outputs an error code if it cannot establish a 1000 Mb/s+ full-duplex link. See the networking-guide for full setup instructions.
Using Latest Firmware
Upgrading to the latest firmware resolves many issues found in earlier versions. Download the latest firmware from Ouster Downloads. The Support team can best assist when you are on the latest firmware. See update-firmware for upgrade instructions.
Note: Contact our Field Application Team for application guidance.
For detailed alert semantics, cursor behavior, and response examples, see the Alerts and Errors page.
Errata & Notices
Firmware v3.0.x Safety Notice
Change Type: Firmware 3.0.x
Date: May 2024
Description of change:
A scenario has been identified in firmware v3.0.x where valid point-cloud data between the sensor window and 6 m is removed when the sensor window is dirty or partially obscured. Data beyond 6 m is unaffected. For users relying on Ouster sensors for near-field obstacle detection in dirty environments, this can lead to unsafe assumptions at the system level.
Affected Products: All configurations of Rev 7 OSDome, OS0, and OS1 sensors running any firmware version prior to v3.1.
Resolution: Upgrade to firmware v3.1 or later (Download Page). Firmware v3.1 resolves the issue robustly and also adds improved obscurant/dirty-window operation, new features, and other quality-of-life improvements. See the Firmware Changelog for a full list of changes.
Proposed workaround:
Some customers may not be able to upgrade immediately. As a temporary mitigation while continuing to operate v3.0.x:
- Regularly clean the sensor window (see Sensor Cleaning).
- Avoid placing reflective surfaces closer than 1 m to the sensor window.
For questions or concerns, contact Ouster Support.
Sensor restarts after long-term continuous operation
Change Type: Firmware Bug (Affects FW v3.0, FW v2.5.2 and prior)
Approximate implementation date of bug fix in Firmware: FW 2.5.3 and FW 3.1 will be available in Q1 2024.
Description of change:
All Ouster lidars running firmware versions prior to v2.5.3 and v3.1 will restart approximately every 36 - 118 days when left continuously operating in the RUNNING state; after three of such restarts sensors will enter ERROR state requiring a power cycle of the sensor. The issue is fixed in firmware versions v2.5.3 and v3.1. This issue can be mitigated by proactively fully power cycling the sensor at least once every 36 days.
Benefit of change:
All customers are strongly recommended to upgrade to the latest firmware version that fixes this issue. If this is not possible, refer to proposed-workaround section for a way to mitigate the issue.
Affected Products:
- For sensors running firmware versions 1.x or 2.x, all firmware versions prior to 2.5.3.
- For sensors running firmware versions 3.x, all firmware versions prior to 3.1.
Across all HW versions (Gen1, RevC, RevD, Rev5, Rev6, Rev7), all sensor variants OS0, OS1, OS2, OSDome.
Detailed description:
Sensors operating in the RUNNING state continuously (without restart/Power-cycle) will continue to operate until approximately the specified number of days in the table below have elapsed. This timeframe is contingent on the configured lidar mode. After this number of days elapses, if the sensor remains in the RUNNING state, it will restart automatically and raise alerts 0x100003d and 0x100003e, and go back to the RUNNING state. After this time period elapses 3 times, the sensor will transition to the ERROR state and log the alert 0x1000040.
Proposed workaround
Some customers may not be able to update the firmware version to the latest firmware version. In such cases the following workarounds can be used:
Mitigation 1
The error condition can be preempted by the user proactively power cycling the sensor at a convenient time before the error occurs.
Mitigation 2
Send any compatible Ouster firmware update to the sensor using the dry_run=1 argument. This will not actually perform any update and the sensor will restart afterwards.
Example Command (Linux):
Mitigation 3
Update the sensor firmware with the same firmware version running on the sensor. The sensor will automatically restart after the update completes.
Example Command (Linux):
Sensor Firmware can also be updated by using the Sensor WebUI. Please refer to the web-interface for more information on how to update the firmware using the Sensor WebUI.
Mitigation 4
Alternatively, performing DELETE of the sensor configuration will also cause the sensor to reboot and reset the internal counter. After DELETE of the sensor configuration is performed, the sensor can be reconfigured. Issuing a reinit command or reconfiguring the sensor will not reset this counter or prevent this error condition from occurring.
Example HTTP command:
Example curl command:
Recovery:
If the sensor reaches the ERROR state because it operated for long enough and a workaround was not performed, the counter can be reset by reconfiguring the sensor or issuing a reinit API command.
In case of any questions or concerns, Please contact Ouster Support.