Stress Tests
The stress testing results in assessing the performance, reliability and stability of the O3R system. These tests will be performed by subjecting the hardware components to extreme stress conditions(internal and external) under different conditions.
The external stress factors include:
Vibration
Shock
EMV
Temperature
The internal stress (as induced by the O3R system itself) includes:
VPU stressing: CPU, GPU, RAM
Head stressing: maximum load, that is maximum framerate and acquisition times for all camera heads
To monitor the system’s operational state, ifm suggests monitoring the following O3R system data steams and diagnosis outputs:
Diagnosis information
O3R internal temperatures
(O3R data availability)
Specifications
The technical specification is available from the ifm.com under respective product’s page. The following table is used for demonstration purposes only.
Test type |
Norm |
description |
---|---|---|
EMC |
EN IEC 61000-6-4 |
radiation of interference / residential, commercial and light-industrial environments |
EN IEC 61000-6-2 |
noise immunity / industrial environments |
|
Shock resistance |
DIN EN 60068-2-27 |
50 g / (11 ms) not repetitive |
DIN EN 60068-2-27 |
40 g / (6 ms) repetitive |
|
Vibration resistance |
DIN EN 60068-2-6 |
2 g / (10…150 Hz) |
DIN EN 60068-2-64 |
2.3 g RMS / (10…500 Hz) |
|
Electrical safety |
DIN EN 61010-2-201 |
electrical supply only via PELV circuits |
Test type |
Range |
description |
---|---|---|
Temperature |
[°C] -10…40 |
Ambient temperature |
1. Vibration and Shock
These tests are independent of the system’s live operation, that is can be performed in an offline state - without monitoring the live status.
The O3R systems functionality can be verified explicitly by comparing sets of functionality before and after the test runs. These sets of functionality can include:
complete boot-up of the system
availability of all connected cameras (heads) and a review of their data streams
Alternatively, the functionality can be verified implicitly by testing a complete system behavior (for example your AGV / AMR) before and after the test. The benchmarking results should stay the same within the boundary of the benchmark’s repeatability.
2. EMV Testing
These tests typically involve testing for EMV emission, EMV emission, and self-interference immunity. Depending on the norm not all parts may apply and different thresholds may be required.
During testing the operation of the device may be interrupted for short amounts of time, according to the norm, and live operation has to be resumed within its time tolerance. Please test the O3R system in its intended mounting place including all surrounding components.
The system’s operational state can be determined by the time difference between consecutive timestamps: for example O3R VPU CPU clock-based timestamps or an independent test machines clock.
The (CPU-based) data frame timestamp is generated by the IPC (VPU) clock when new data is acquired from a camera head. For test purposes, the timestamp latency and jitter should be sufficiently low (latency and jitter).
This may either be done on a recorded dataset in the post or on data retrieved in live operation.
Note
**Please compare these statistical values against typical values under undisturbed operation conditions, to ensure the system's capability to retrieve the required data at full framerate!**
3. Temperature Testing
A first set of temperature tests is typically run during a proof of concept phase on a component level, that is the O3R system and its intended (prototype) mounting setup are tested in a smaller temperature chamber. This is a good indication of whether the passive cooling capabilities of the camera and VPU mounting are sufficient for the full ambient temperature range.
Please set all 3D camera heads to their maximum allowed framerate: 20 Hz
. Additionally you can change the exposureShort
from 400 to 1000.
Load on the VPUs CPU and GPU can be introduced by running a functional ODS application instance, or by artificially introducing CPU and GPU load via tools such as stress and gpu-burn.
In a secondary step temperature tests are repeated on a fully assembled machine level, for example the complete AGV / AMR is tested in larger temperature chambers, with all active components in live operation. This may include:
The battery management system (BMS) is under full load.
Active cooling of the battery cells if applicable.
Additional heat introducing “computers,” for example: IPCs, PLCs, …
Active cooling, that is fans that distribute energy over larger passive heat sinks or perform an exchange of air from the inside to the outside of the machine
…
Additionally “heat” is introduced via the temperature chamber to mimic maximum ambient heat levels during operation. This test will determine the operability of the O3R system, based on the effectiveness of the whole cooling concept.
The external temperature ratings of the O3R system components (VPU and O3R camera heads) are rated for external temperatures up to 40°C ambient temperature. This temperature threshold should only be used as an indication value. The internal temperature of each part (VPU device and one temperature value per camera head) has to stay below their respective threshold values. If this can be assured the external temperature values are only of secondary importance, as the device can perform under these ambient temperatures.
Temperature Monitoring
The O3R cameras provide real-time temperature readings as part of the read-only values in the JSON configuration. These temperatures are measured by a sensor integrated into the ICC (Illumination Control Circuit), which resides within the STM32G071 microcontroller. The ICC is responsible for managing the illumination, automatically shutting it down when overtemperature conditions occur and turning it back on when the temperature falls below a specified threshold.
For both the O3R-222 and O3R-225 camera heads, the shutdown temperature is set to 85°C, while the restart temperature is 79°C. These thresholds are hardcoded into the ICC firmware.
While the script below can be used to track temperature values, it’s important to note that the ICC only updates its temperature readings once per minute in the JSON output. Due to this update frequency, the exact shutdown and restart temperatures may not always be reflected in the JSON data at the precise moments these events occur. If an overtemperature event takes place, an error message will be triggered in the diagnostic logs, which will include a reference to “ICC”. For more details about diagnostics, see Diagnostic error codes.
In addition to ICC temperatures, you can also read the illumination temperature of O3R devices. However, this value is primarily used for temperature drift calibration and applied to the depth map for distance correction. It is not linked to the ICC, and as such, it neither influences the system shutdown nor matches the ICC temperature values. In fact, the illumination temperature may differ by more than 10°C and typically runs higher than the ICC temperature.
Note: The illumination temperature serves a different purpose and does not indicate any operational risks related to system overtemperature.
#!/usr/bin/env python3
#############################################
# Copyright 2023-present ifm electronic, gmbh
# SPDX-License-Identifier: Apache-2.0
#############################################
"""_summary_
This examples shows how to retrieve the internal
temperature values from the O3R platform, for
the VPU, the IMU and any connected camera.
:raises RuntimeError: If overtemperature is reached.
"""
import logging
from datetime import datetime
from ifm3dpy import O3R
logger = logging.getLogger(__name__)
def main(ip: str):
dt_string = datetime.now().strftime("%Y_%m_%d-%H_%M_%S")
logging.basicConfig(
filename=f"temperature_test_{dt_string}.log",
level=logging.INFO,
format="%(asctime)s.%(msecs)03d %(levelname)s: %(message)s",
datefmt="%Y-%m-%d %H:%M:%S",
)
logger.info(f"IP: {ip}")
o3r = O3R(ip=ip)
temperatures = o3r.get(["/device/diagnostic/temperatures"])["device"]["diagnostic"][
"temperatures"
]
logger.info(f"{temperatures}")
for e in temperatures:
# test for tuple: ('overtemperature', True)
if ("overtemperature", True) in list(e.items()):
logger.warning(f"overtemperature reached: {e}")
raise RuntimeWarning(f"overtemperature reached: {e}")
if __name__ == "__main__":
logging.basicConfig(level=logging.INFO, format="%(message)s")
try:
# If the example python package was build, import the configuration
from ovp8xxexamples import config
IP = config.IP
except ImportError:
# Otherwise, use default values
logger.warning(
"Unable to import the configuration.\nPlease run 'pip install -e .' from the python root directory"
)
logger.warning("Defaulting to the default configuration.")
IP = "192.168.0.69"
main(ip=IP)
$ ifm3d dump | jq '.device.diagnostic.temperatures'