CODEWITHSUNDEEP
c++ros
user3180
user3180

Reputation: 1497

How to debug ROS error message with realsense camera

I'm running the following realsense2_camera launch command:

roslaunch realsense2_camera rs_rgbd.launch

I see this error:

04/01 22:02:12,523 WARNING [139805191870208] (types.cpp:49) Out of frame resources!
 04/01 22:02:12,523 ERROR [139805191870208] (synthetic-stream.cpp:47) Exception was thrown during user processing callback!

There's a few problems with trying to debug this: 1. We are using the compiled realsense-ros library, so there's no types.cpp we can find on our system.

  1. The message "Out of frame resources!" is uninformative. Looking at types.cpp here: http://docs.ros.org/kinetic/api/librealsense2/html/types_8cpp_source.html

It's still uninformative, as types.cpp line 47 is just generic error handling code:

45     recoverable_exception::recoverable_exception(const std::string& msg,
   46         rs2_exception_type exception_type) noexcept
   47         : librealsense_exception(msg, exception_type)
   48     {
   49         LOG_WARNING(msg);
   50     }

How do we see the code logic that actually explains this error message? I assume this would require going to the source of the message. How do we find that?

Upvotes: 1

Views: 2032

Answers (2)

Han Wang
Han Wang

Reputation: 1

Open your launch file, and modify the frame rate parameter. Your default value is 30, you can make it smaller.

  <arg name="depth_fps"           default="15"/>
  <arg name="infra_fps"           default="15"/>
  <arg name="color_fps"           default="15"/>

Upvotes: 0

Fruchtzwerg
Fruchtzwerg

Reputation: 11399

Intel® RealSense™ is open source, you can find the source code at GitHub. If you check the sources for the exception, you will find the

three lines 327, 388 and 411

the exception gets thrown (class wrong_api_call_sequence_exception : public recoverable_exception).

All of the exceptions are thrown based of an failed allocation like

_actual_source.alloc_frame(...);

where frame_source & _actual_source;. Digging deeper, you will find the definition of frame_source::alloc_frame which returns a nullpointer in our case. This nullpointer is returned by a virtual method alloc_and_track, whichs implementation leads to a failure of publish_frame.

For me it looks like there is a buffer of frames which are able to be published and reused later on if released. Your software (ROS in this case) is simply not releasing the frames fast enought to be reused again.

This should basically answer your question. If required, you now could dig deeper to find out how to parametrize the parameter of intrest uint32_t max_publish_list_size or try to find out why your frames are not released fast enough. The way to do this is exactly the same like done until this point. Just try to step through the code.

Upvotes: 3

Related Questions