Errata and Notices

Note

This section provides more information on new feature releases and certain bug fixes which might help users understand correct working/operation of the sensor.

Firmware v3.0.x Safety Notice

Date:

May 2024

Change Type:

Firmware 3.0.x

Description of change

Ouster is issuing a safety notice for all Ouster lidar sensors running firmware v3.0.x. Ouster has identified a scenario where sensors running firmware v3.0.x will remove valid data from the point cloud between the sensor window and 6 m, when the sensor window is dirty or partially obscured. In this scenario, data beyond 6 m is unaffected. However, valid data between the sensor window and 6 m is removed.

For users that rely on Ouster lidar sensors for obstacle detection in a dirty environment within 6 m, this unanticipated removal of data may lead to unsafe assumptions at the system level.

As an immediate solution, we recommend all users upgrade to firmware v3.1 or later (Download Page). Firmware v3.1 solves this issue robustly, in addition to providing several benefits such as improved obscurant/dirty window operation, new features, and other quality-of-life improvements. Please refer to the Firmware Changelog for more information on the additional changes, features, and fixes.

For customers who may be unable to upgrade firmware immediately, but are reliant on data between 0 m - 6 m in a dirty or obscurant-filled environment, we recommend regularly cleaning the sensor window and avoid placing reflective surfaces closer than 1m to the sensor window.

Affected Products

All configurations of Rev7 OSDome, OS0, and OS1 sensors running Firmware 3.0.x (all firmware versions prior to 3.1).

Approximate implementation date of bug fix in Firmware

Firmware v3.1 is available today (May 2024) - Download Page.

Proposed workaround

Some customers may not be able to update the firmware version v3.1 and later. In such cases, the following workarounds can be used TEMPORARILY:

For customers who may be unable to upgrade firmware immediately, but are reliant on data between 0m - 6m in a dirty or obscurant-filled environment, we recommend regularly cleaning the sensor window and avoid placing reflective surfaces closer than 1m to the sensor window.

In case of any questions or concerns, Please 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.

Table
Sensor state	Lidar mode	Approximate time until automatic restart	Maximum restarts until ERROR state
INITIALIZING	N/A	N/A	N/A
ERROR	N/A	N/A	N/A
STANDBY	N/A	N/A	N/A
RUNNING	2048x10, 1024x20	~36 days	3
RUNNING	1024x10, 512x20	~67 days	3
RUNNING	512x10	~118 days	3

Note

All customers are strongly recommended to upgrade to the latest firmware version that fixes this issue. If this is not possible, please refer to the Proposed workaround section below for a way to mitigate the issue.

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):

curl -vH 'Content-Type: application/octet-stream' --data-binary @ousteros-image-prod-bootes-v3.0.1+20230209044733.img 'http://192.0.2.123/api/v1/system/firmware?dry_run=1'

POST /api/v1/system/firmware?dry_run=1 HTTP/1.1
Host: 192.0.2.123


User-Agent: curl/7.68.0
Accept: */*
Content-Type: application/octet-stream
Content-Length: 42134428
Expect: 100-continue


Mark bundle as not supporting multiuse
HTTP/1.1 100 Continue
We are completely uploaded and fine
Mark bundle as not supporting multiuse
HTTP/1.1 204 No Content
Server: nginx
Date: Thu, 28 Apr 2022 17:49:58 GMT
Connection: keep-alive

Connection #0 to host 192.0.2.123 left intact

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):

curl -vH 'Content-Type: application/octet-stream' --data-binary @ousteros-image-prod-bootes-v3.0.1+20230209044733.img 'http://192.0.2.123/api/v1/system/firmware'

POST /api/v1/system/firmware HTTP/1.1
Host: 192.0.2.123


User-Agent: curl/7.68.0
Accept: */*
Content-Type: application/octet-stream
Content-Length: 42134428
Expect: 100-continue


Mark bundle as not supporting multiuse
HTTP/1.1 100 Continue
We are completely uploaded and fine
Mark bundle as not supporting multiuse
HTTP/1.1 204 No Content
Server: nginx
Date: Thu, 28 Apr 2022 17:49:58 GMT
Connection: keep-alive

Connection #0 to host 192.0.2.123 left intact

Sensor Firmware can also be updated by using the Sensor WebUI. Please refer to the Sensor 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.

DELETE /api/v1/sensor/config

Example HTTP command:

http DELETE 192.0.2.123/api/v1/sensor/config

Example curl command:

curl -i -X DELETE http://192.0.2.123/api/v1/sensor/config -H 'Content-Type: application/json'

http

DELETE /api/v1/sensor/config HTTP/1.1
Host: 192.0.2.123

curl

curl -i -X DELETE http://192.0.2.123/api/v1/sensor/config

httpie

http DELETE http://192.0.2.123/api/v1/sensor/config

python-requests

requests.delete('http://192.0.2.123/api/v1/sensor/config')

response

HTTP/1.1 204 No Content
Connection: keep-alive
Date: Mon, 10 Jul 2023 17:12:47 GMT
Server: nginx

Note

In addition to the sensor configuration being reset to the factory default settings, fields such as Static IP override, PTP profiles and the User Editable Data filed will be reset. Each of these mitigations resets the internal counters and will need to be performed periodically before the error occurs to be effective.

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.

Firmware Changelog

Firmware versions (3.0 & later) are only compatible on OS0/OS1/OSDome Hardware versions Rev7 and later. Please refer to FW 2.x or prior if you have hardware version Rev7 OS2, Rev 06 OS0/OS1/OS2 and prior generation sensors.

Firmware v3.1.0

Date:: May 2024
Description:

“Added”

Add Low Data Rate Dual Return profile i.e., FUSA_RNG15_RFL8_NIR8_DUAL Return Profile.
Add config parameter for min_range_threshold_cm (Refer to min_range_threshold_cm for more information).
Add config parameter for return_order (Refer to return_order for more information).
Add config parameter for Delete Config (Refer to DELETE /api/v1/sensor/config for more information).
Add PTP L2 E2E support, via a new PTP profile “default-l2-relaxed”.
Add new alerts, please refer to Table of All Alerts and Errors section for more information.
Add config parameter for User Editable Data section in the API user guide, this field can be used for a number of purposes such as storing specific information about the sensor, qualifying a sensor, calibration data, or any other information.
Add config parameter for POST /api/v1/system/restart to restart sensor or reinitialize a sensor.
Add End-to-End Cyclic Redundancy Check (CRC) in configurable data packet format.
Add config parameter for GET /api/v1/sensor/metadata/imu_data_format. User can get imu_data_format and POST config to change gyro_fsr and accel_fsr from NORMAL to EXTENDED.
Add Alert Flags in Lidar data packet. All of the udp_lidar_profile have been updated to include alert flags at the packet level.

“Improved”

Improved robustness for cold start.
Reduced the occurrence of false alerts for VCSEL_CURRENT_LOW.
Improved motor stability when decelerating to lower RPM during lidar mode switches.
Minor PTP software update and reduced fault recovery time.
Improved existing alerts to notify users when the network is not reachable. This enhancement enables users to promptly address connectivity issues, improving the overall reliability of the system.
Improved startup time/reinit time by ~10-15 seconds.
Improved sensor’s webUI (Sensor Web Interface) to display client and UDP destination address.
Allow IMU port to be set to 0 to disable IMU packet transmission.
Improved recovery after Ethernet link loss that previously caused UDP stream to stall.

“Fixed”

Apply PPS setting in STANDBY in order for api/v1/time/sensor to reflect provisioned configuration in STANDBY.
Fixed handling of NMEA messages with fractional seconds. Previously, If NMEA sentence contains a fraction of a second time, the sensor would round the fraction up resulting into a future timestamp. This has been fixed.
Fixed PPS/NMEA lock and time synchronisation. Previously, Sensor does not lock when gps is connected and Sync pulse in is selected. The sensor does not lock to an external PPS signal from GPS. This has now been fixed.
Correct IMU polling rate to 100hz.
Fixed GET /api/v1/sensor/alerts input cursor correctly limits alert log.
Fixed timestamp loop in PPS mode when PPS signal is lost. Timestamp will free-run instead of looping.
Fixed sensor error that occurred when using continuously for 1-4 months depending on mode. Please refer to Errata and Notices for more information.
Support for local udp_dest address via sensor Web_UI.
Fixed a bug where the lidar starts to send data when powering ON before establishing connection with the client machine.
Fixed a bug where the sensor would be stuck in UNKNOWN state during multiple API requests while streaming point clouds.
Fixed Alert section i.e., categories changed from WARNING to ERROR. No functional changes to alert behavior.
Fixed a bug in point cloud behaviour that caused highly reflective objects below min_range to make other objects disappear.
Fixed a bug that prevents sensor from going into ERROR stopped state or restarting while doing cold start. This improves the reliability and overall robustness of the cold start path.

“Changed”

Replaced mDNS name from _roger._tcp to _ouster-lidar._tcp. _roger._tcp is in planned deprecation.
Replaced alert category for CONFIG_INVALID to `CONFIG. Please refer to alerts and error section in the firmware user manual.

“Removed”

TCP API has now been DEPRECATED in FW 3.1. Please refer to HTTP API Reference Guide section instead.
LEGACY Data packet profile has been DEPRECATED, please refer to Lidar Data Packet Format for more information.

Firmware v3.0.1

Date:: February 2023
Description:

“Updated”

beam_to_lidar_transform for Rev7 OS0 and OS1 sensors.
lidar_to_sensor_transform for Rev7 OSDOME sensors.

“Added”

New HTTP Command to configure speed override (Refer to System)

Firmware v3.0.0

Date:: January 2023
Description:

“Fixed”

Bug Fix in High Input Voltage Alert behavior.
Bug in keep-alive behavior for HTTP 1.1.
Bug fix in get_lidar_data_format.

“Improvements”

Improved point cloud behavior due to enhanced retro-reflector range accuracy improvement.

“Changed”

Default value of udp_profile_lidar will be set to single return profile. For more information refer to RNG19_RFL8_SIG16_NIR16 Return Profile.

“Added”

1024x20 and 2048x10 lidar modes with dual returns.
Shot limiting status flags and thermal shutdown.
Azimuth laser masking.
Two new Signal multiplier modes - 0.25 and 0.5 Mode.
New alerts, refer to Table of All Alerts and Errors.