View my account

D457 Infrared projector fails to restart after overheating shutdown

Follow
Layth Mahdi
  • Edited
Hello, We are deploying multiple D457 cameras for outdoor use in extremely harsh environmental conditions where ambient temperatures reach up to 50 degrees Celsius. Based on our understanding from previous posts and the D400 documentation, we have notcied that if the temperature exceeds 60 degrees Celsius for few seconds, the laser power is reduced and eventually the projector shuts off. Even after the camera cools down, the projector remains off. Our question is whether there is any way for the projector to automatically resume operation once the temperature decreases. If this is not currently possible, could RealSense consider incorporating this functionality in a future firmware update? Additionally, is there a way to interface with the projector to manually initiate a restart? Current Firmware: 5.16.0.1
0

Comments

5 comments

Date Votes
  • MartyG
    • Edited

    Hi Layth Mahdi  What you describe is correct.  The RealSense firmware driver contains a laser safety mechanism that shuts off the projector's laser if the internal Projector temperature of the camera exceeds 60 degrees C for several seconds.  

     

    The camera is able to continue operating when the projector is off, though there may be a decrease in detail on the depth image and the camera would be unable to see a real-world scene whose lighting is dim or dark.

     

    The internal temperature of the camera is influenced by the  temperature of the camera's casing.  Intel lab tests found that the Projector temperature should not exceed 60 degrees C if the casing temperature does not exceed 44 degrees C.  This test was on models preceding the D457 though that have a ventilation grille in their casing, whilst D457 has an environmentally sealed casing to defend against dust and water spray entry.

     

    If the environment continues to severely heat the outer casing then it may be difficult for the internal temperature of the camera to fall.

     

    You could write a program code routine to continually check if the IR emitter (i.e the projector) is disabled, and if it is AND the Projector temperature is < 60 then enable it.  Both the emitter status and Projector temperature can be queried with code.

    0
    Comment actions Permalink
  • Layth Mahdi

    Hi Marty,

    The issue is, when the IR projector goes off, we no longer see the camera through rs-enumerate-devices, so we cannot communicate with it. Although, we do receive point cloud information.
    When we send rs-enumerate-devices, we get:
    “ 22/07 15:59:27,950 ERROR [281473202063616] (librealsense-exception.h:52) xioctl(VIDIOC_S_EXT_CTRLS) failed Last Error: Invalid argument
    22/07 15:59:27,950 ERROR [281473202063616] (rs.cpp:237) [rs2_create_device( info_list:0xaaab27f82190, index:1 ) Backend] xioctl(VIDIOC_S_EXT_CTRLS) failed Last Error: Invalid argument
    22/07 15:59:27,950 ERROR [281473202063616] (rs.cpp:237) [rs2_delete_device( device:nullptr ) UNKNOWN] null pointer passed for argument "device"
    Could not create device - xioctl(VIDIOC_S_EXT_CTRLS) failed Last Error: Invalid argument . Check SDK logs for details”

    The questions we have are:
    1. Why we no longer see the camera if the projector is down?
    2. Why can’t RealSense firmware automatically restart the projector if the right conditions were met.

    0
    Comment actions Permalink
  • MartyG

    1.  The camera should not become inaccessible when the projector is shut off.  VIDIOC_S_EXT_CTRLS errors indicate that there is likely a conflict between the program and the kernel version on your computer.  Building the librealsense SDK from source code with the libuvc backend method using a build script at the link below can enable it not to be dependent on specific Linux versions or kernel versions.

    https://github.com/IntelRealSense/librealsense/blob/master/doc/libuvc_installation.md

     

    2.  I am not involved in RealSense firmware driver development and so cannot offer advice about this question, unfortunately.

    0
    Comment actions Permalink
  • Layth Mahdi

    1. We are using apt install librealsense2. Not sure what you mean by conflicting between the program and the kernel. Do you mean we should always compile from the source code rather than using the apt binary?
    2. Who should we contact to potentially, include this in the next firmware?

    0
    Comment actions Permalink
  • MartyG

    1.  Yes, if you have potential conflicts with your computer's kernel then I would always recommend building from source code with a method that enables librealsense to bypass the kernel.  This would be the libuvc method mentioned above, or the RSUSB backend method at the link below.

    https://github.com/IntelRealSense/librealsense/issues/9931#issuecomment-964289692

     

    2.  I would strongly recommend addressing the issue by writing a checking routine in a program as suggested above, as a firmware feature request is not likely to be successful.  It is significantly more complex to implement a change in the firmware driver than in the SDK's code, and new firmwares have to be tested very extensively before being cleared for release.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post