Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CUSTOM_BOX_OBJECTS support #92

Open
2 tasks done
osu-uwrt-bot opened this issue Apr 26, 2022 · 8 comments
Open
2 tasks done

CUSTOM_BOX_OBJECTS support #92

osu-uwrt-bot opened this issue Apr 26, 2022 · 8 comments
Labels
feature_request New feature or request

Comments

@osu-uwrt-bot
Copy link

Preliminary Checks

  • This issue is not a duplicate. Before opening a new issue, please search existing issues.
  • This issue is not a question, bug report, or anything other than a feature request directly related to this project.

Proposal

Support for the CUSTOM_BOX_OBJECTS from the ZED object detection module. The ZED SDK has a parameter which allows users to submit custom detections to it and it is able to track the objects as well as output the position and 3d bounding boxes for the objects.

Currently the wrapper doesn't expose that part of the SDK and it isn't possible to access that part of the SDK through another ROS node while running the wrapper due to the wrapper having control of the camera.

Would it be possible to enable that as an option within the launch file and then accept the objects as a message to which the wrapper outputs a Detections3Darray (or even a custom message with the info from the SDK).

Use-Case

I would be able to use a custom detector in ROS with 3D bounding boxes

Anything else?

No response

@osu-uwrt-bot osu-uwrt-bot added the feature_request New feature or request label Apr 26, 2022
@Myzhar
Copy link
Member

Myzhar commented Apr 26, 2022

We are working on this feature. The only issue is the latency:

  1. The zed_node publishes the rgb image (dT_1)
  2. The detector_node receives the rgb image (dT_2)
  3. The detector_node extracts the 2D bounding box and publishes it (dT_3)
  4. The zed_node receives the 2D bbox and starts the tracking

If dT_1+dT_2+dT_3<T_grab then there is only one frame of latency and the tracking can work correctly, otherwise it can be not so precise.

Furthermore, ROS introduces latency in the communication process... to know if this engine works we can only put all the gears together and test it.

@MrOCW
Copy link

MrOCW commented Oct 7, 2022

Hi @Myzhar, how is the progress of this feature? Will it be implemented anytime soon?

@Marketos-Damigos
Copy link

Hi @Myzhar any progress on that? Would it be possible to change the underlying model of the base functions and theoretically have our own custom detection model run?

@Myzhar
Copy link
Member

Myzhar commented Jan 30, 2023

I'm sorry but this is not currently planned.
We suggest you add custom detection to the main code.

@Marketos-Damigos
Copy link

I'm sorry but this is not currently planned. We suggest you add custom detection to the main code.

Could you elaborate on how to approach it?

@shaoyifei96
Copy link

@Mat198
Copy link

Mat198 commented Sep 28, 2023

Any news about this resource? It would be very helpful in my project.

Meanwhile, I'll be working on a way to do this following the approach suggested above.

@creminem94
Copy link

Hi, did anyone actually implemented a custom detector in ROS2?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature_request New feature or request
Development

No branches or pull requests

7 participants