Timeout waiting for camera

[GoodTekken]

Hello, sir. Today I found that the camera will take several seconds to get an image use the code under:

        stopWatch.reset();
        fg->SWTrigger(); //TRIGGER
        if (! fg->WaitForFrame(im.get(), 0))
        {
          std::cerr << "Timeout waiting for camera!" << std::endl;
          return -1;
        }
        double time = stopWatch.getTime();
        std::cerr<< "elapsed_time:" << time << std::endl;

And I notice that when camera temperature is up to 50℃ will cause that to happen. But It can work normally when the temperature is around 30℃.

(When Temperature 36.7℃，the elapsed_time:18435ms)

Do you have any advice?

[graugans]

Hey @GoodTekken , what type of camera are you using? I guess it is an O3D3xx am I right? The general recommendation is to mount the camera in a way that there is a good heat dissipation provided.

[GoodTekken]

Yes,sir. The camera is O3DP03. And Ping is okay.

jt@JT:~$ ping 192.168.0.69
PING 192.168.0.69 (192.168.0.69) 56(84) bytes of data.
64 bytes from 192.168.0.69: icmp_seq=1 ttl=64 time=0.276 ms
64 bytes from 192.168.0.69: icmp_seq=2 ttl=64 time=0.359 ms
64 bytes from 192.168.0.69: icmp_seq=3 ttl=64 time=0.365 ms
64 bytes from 192.168.0.69: icmp_seq=4 ttl=64 time=0.405 ms

Now I switch the camera to Streaming mode and use the order with"ifm",It hints "Timeout waiting for camera!" too.

[ INFO] [1652252488.667637285]: Loading nodelet /ifm3d_ros_examples/camera of type ifm3d_ros/camera_nodelet to manager camera_standalone_nodelet with the following remappings:
[ INFO] [1652252488.671071466]: waitForService: Service [/ifm3d_ros_examples/camera_standalone_nodelet/load_nodelet] has not been advertised, waiting...
[ INFO] [1652252488.677003864]: Initializing nodelet with 4 worker threads.
[ INFO] [1652252488.692297637]: waitForService: Service [/ifm3d_ros_examples/camera_standalone_nodelet/load_nodelet] is now available.
[ INFO] [1652252488.756652292]: IP default: 192.168.0.69, current 192.168.0.69
[ INFO] [1652252488.757925027]: pcic port check: current 50010, default 50010
[ INFO] [1652252488.849718817]: Running dtors...
[ INFO] [1652252488.849813273]: Initializing camera...
[ INFO] [1652252489.866697382]: Initializing framegrabber...
[ INFO] [1652252489.867918164]: Nodelet arguments: 16, 50010
[ INFO] [1652252489.868028264]: Initializing image buffer...
[ WARN] [1652252490.369207744]: Timeout waiting for camera!
[ WARN] [1652252490.869767394]: Timeout waiting for camera!

[GoodTekken]

The mounting is the same as before. And the camera can run well a few days ago. What can make the camera timeout? Or XMLRPC ?

[graugans]

Okay, it looks like you are using the O3DP03 with the standard ROS node. Typically the O3DP03 comes with its own interface which configures the camera to software trigger. As in your example above one has to trigger the camera. As far as I know the standard ROS node expects the camera to be configured in continuous mode. This means it times out because no data is received because no one triggers the camera.

Can you please describe what is your goal and what data you are looking for?

[GoodTekken]

Yes, I have set the camera in continuous mode, but still "TimeOut".

jt@JT:~$ ifm3d hz --nframes=100 --sw
Timeout waiting for camera!
jt@JT:~$ ifm3d ls
[
  {
    "Active": false,
    "Description": "",
    "Id": 476707713,
    "Index": 1,
    "Name": "ifm Pallet Detection System v2.10.12 - Triggered"
  },
  {
    "Active": true,
    "Description": "",
    "Id": 964899043,
    "Index": 2,
    "Name": "ifm Pallet Detection System v2.10.12 - Streaming"
  }
]

I want to get the point cloud from the camera and make a test for pallet detection.

How odd! I can get the data from the camera before. no matter triggered mode or continuous mode.

[graugans]

Can you please grab the trace logs from the camera?

$ ifm3d trace

[GoodTekken]

No , it cannot.

jt@JT:~$ ifm3d trace
ifm3d error: -100001
Lib: XMLRPC Timeout - can you `ping' the sensor?
jt@JT:~$ ping 192.168.0.69
PING 192.168.0.69 (192.168.0.69) 56(84) bytes of data.
64 bytes from 192.168.0.69: icmp_seq=1 ttl=64 time=0.243 ms
64 bytes from 192.168.0.69: icmp_seq=2 ttl=64 time=0.341 ms

[graugans]

Please try

$ ifm3d trace --limit 100

There is a known bug in the libxmlrpc when it comes to larger chunks of data

[GoodTekken]

I can use "ifm3d trace" after restart the device.

jt@JT:~$ ifm3d trace
T: 10.5315, P: 371,  C: INFO,  S: qt_dbus_web_bridge,  M: qt_dbus_web_bridge: Enabled Logging via Redis
T: 10.5348, P: 371,  C: WARN,  S: qt_dbus_web_bridge,  M: Starting ...
T: 10.5342, P: 375,  C: WARN,  S: iom,  M: Program starting ...
T: 10.7041, P: 375,  C: INFO,  S: iom,  M: DIAGC_DBUS_EVENT_DIAGC_BOOTED
T: 10.7120, P: 375,  C: WARN,  S: diagCtrl,  M: do_conv_ana_out_calib[89]: invalid ana out calib params
T: 10.7127, P: 375,  C: WARN,  S: diagCtrl,  M: drv_cfg_hw_late_init[249]: calib_dac failed
T: 10.7131, P: 375,  C: INFO,  S: diagCtrl,  M: sysboot_hw_evt[132]: successfully init HW : ###
T: 10.7134, P: 375,  C: WARN,  S: diagCtrl,  M: do_conv_ana_out_calib[89]: invalid ana out calib params
T: 10.7137, P: 375,  C: WARN,  S: diagCtrl,  M: do_conv_ana_out_calib[89]: invalid ana out calib params
T: 11.2138, P: 409,  C: WARN,  S: suprge,  M: suprge: supervision activity starting, Bello the watchdog, is unfused ...
T: 11.3720, P: 409,  C: WARN,  S: suprge,  M: Registerinng services for the O3D3XX family of devices
T: 12.2123, P: 399,  C: INFO,  S: gecco,  M: gecco: Enabled Logging via Redis
T: 12.2134, P: 399,  C: WARN,  S: gecco,  M: Starting ...
T: 13.2648, P: 395,  C: INFO,  S: imager,  M: imager: Enabled Logging via Redis
T: 13.2660, P: 395,  C: WARN,  S: imager,  M: Starting ...
T: 13.3737, P: 399,  C: WARN,  S: gecco,  M: No Fieldbus selected!!! 
T: 13.5146, P: 387,  C: INFO,  S: GECOM,  M: DBUS connection successful
T: 13.5224, P: 395,  C: WARN,  S: imager,  M: HawkeyeStepperMotor initialization (): No motor is available for this article
T: 13.9748, P: 399,  C: ERROR,  S: gecco,  M: bool ifm::O3D3xxDevice::activateApplication(): application activation failed, probably no imager process running
T: 15.7964, P: 399,  C: WARN,  S: gecco,  M: Imager is available again
T: 15.7979, P: 395,  C: WARN,  S: imager,  M: LRAE is available again
T: 16.7911, P: 399,  C: WARN,  S: gecco,  M: Finished imager configuration
jt@JT:~$ ifm3d trace --limit 100
ifm3d error: too many positional options have been specified on the command line
jt@JT:~$ ifm3d trace --limit 1
ifm3d error: too many positional options have been specified on the command line

[graugans]

Sorry there was a typo:

$ ifm3d trace --limit=100

[GoodTekken]

$ ifm3d trace --limit=100 20220511 ifm trace

[graugans]

T: 366.4476, P: 375,  C: WARN,  S: iom,  M: DIAGC_DBUS_EVENT_UB_UNDERVOLT
T: 366.4504, P: 375,  C: WARN,  S: iom,  M: DIAGC_DBUS_EVENT_VLED_UNDERVOLT
T: 366.4521, P: 375,  C: WARN,  S: iom,  M: DIAGC_DBUS_EVENT_UB_UNDERVOLT
T: 395.5820, P: 375,  C: WARN,  S: iom,  M: DIAGC_DBUS_EVENT_VLED_UNDERVOLT

Indicates your power supply is not able to provide the specified current and voltages. Please check your power-supply

[GoodTekken]

I have charged the battery yesterday.

It can get the Image suddenly , the trace below: can get the image

[graugans]

May I suggest to use a power-supply for testing, to get it out of the loop.

[GoodTekken]

Thank you, sir. And sorry for the late reply. when I use the power supply, It can work quite well.