RGB image incompatibility with firmware 16.23

[lola-masson]

There is a bug in ifm3d-ros2 used in combination with the O3R firmware version 0.16.23 which makes it impossible to get RGB data.

[PGotzmann]

According to the release notes O3R firmware 0.16.23 requires ifm3d-libaray >=1.1.1 but both ifm3d-ros and ifm3d-ros2 only support up to ifm3d-libaray 0.93.0 at the time of writing (at least that is what the readme says).

Can you confirm that apart from this issue ifm3d-ros and ifm3d-ros2 are still supposed to work with FW 0.16.23 and specify which ifm3d-libaray version should be used with it?

I know that this is probably hard to answer but do you have at least a rough estimate when this bug will be fixed?
We would really like to upgrade to FW 0.26.23 but can not do that without ROS2 support or RBG data.

[lola-masson]

ifm3d-ros and ifm3d-ros2 are both only compatible with ifm3d 0.93.0. FW 16.23 should work with ifm3d 0.93.0 and ifm3d-ros(2) for the 3D streams. Unfortunately as you saw there is an issue with the 2D stream.

We have a large development effort focusing on ROS starting mid-March. I would expect at least a couple of weeks for the first release to come out, but at least this provides a rough time-frame.

[PGotzmann]

Thank you for the fast reply.
So, there is no chance for a fix for this particular issue before the new ifm3d_ros2 release with the 1.x.x ifm3d-libary?

[lola-masson]

Unfortunately, we have no resources available at the moment for this. But we will make sure to address this first mid-March.

[PGotzmann]

I had a closer look at this issue and from what I can tell this is not a bug in ifm3d-ros2 but rather an incompatibility of ifm3d 0.93.0 with FW 0.16.23.

The call to FrameGrabber::waitForFrame() by default calls ifm3d::ByteBuffer<Derived>::Organize() which for some reason reports a wrong format for JPEG data.
JPEG are expected to be unsigned 32bit int, not: 0

Just from a quick comparison between ifm3d 1.2.1 and 0.93.0 it looks like the relative position of the format specifier has not changed (chunk offset 24). Not sure what else has has changed here than.What's interesting though is that the JPEG data itself appears to be at the expected data chunk and is parsed correctly if the format check is skipped.

@lola-masson do you have any insight into the protocol changes that you can share or can you say if it should be acceptable to use the 2D data without this check for the time being?
(However I admit, that probably the only clean way to solve this is to adapt the interfaces to a compatible ifm3d version)

[PGotzmann]

Since this is a blocking Issue for me I did a quick port of the ros2 driver. It offers the same functionality and interfaces but works with firmware 0.16.23 and ifm3d lib 1.1.1.

Limitations:

• still uses the frame grabber in polling mode
• extrinsic publisher still missing (could not find the corresponding docs)
• not yet extensively tested

https://github.com/PGotzmann/ifm3d-ros2/tree/fw0.16.23

[lola-masson]

Hi @PGotzmann,

Thank you so much for this! I hope this is sufficient for you until we are able to release a new official version of the wrapper.
Can you confirm that with your fix for fw16.23 and ifm3d 1.1.1 you can retrieve the RGB data?

[PGotzmann]

@lola-masson,
Thank you for your reply. I can use this for testing purposes for the time being.
Still looking very much forward to a new official version 😉

I can confirm that it is possible to retrieve RGB data with this port.

Just want to point out that as in the current master branch the RGB data here is of type sensor_msgs/CompressedImage. Thus it can not be directly viewed e.g. with rviz2 without an additional decompression e.g. image_transport.

[gilduz]

Same problem here, thank you for sharing @PGotzmann.
I've tried to build your porting on galactic, with ifm2d v.1.1.1 installed. I got a compilation error:

CMake Warning at /usr/lib/cmake/ifm3d-1.1.1/ifm3d-config.cmake:24 (message): ifm3d could not find component: camera
CMake Warning at /usr/lib/cmake/ifm3d-1.1.1/ifm3d-config.cmake:24 (message): ifm3d could not find component: stlimage

Any idea on how to fix it?

EDIT: my mistake, with branch fw0.16.23 it builds. Now I'll test it!