[Docking] Create API to enable / disable detector

[SteveMacenski]

This would be useful so that the detector running for docking (which may be very computationally expensive, like AI) doesn't need to be always running when not in a docking situation. You can enable it when starting to dock and disable it once done - then the detector can be a task server instead of an always-on node (optionally)

[ayushkumar8340]

Hi,
I am interested in working on this problem statement. Could you please assign this issue to me and provide further details?

[SteveMacenski]

@ayushkumar8340 thanks for showing interest!

I think what we want to do here is to:

• Update the Dock Plugin API to include a new "startDetection()" "stopDetection()" methods
• Update documentation in the readme and nav2 website about them
• Implement these 2 functions in the 2 plugins: Set a service name parameter to enable and disable the task server doing dock detections, with the dock type name as a request field (in case multiple dock types, to enable detections on the the current right one). If none provided (make the default empty string), then we skip and don't do anything, meaning the detector is always on

That would allow the explicit start/end of detections when they're needed for docking in case a high computation cost detector is being used (like AI)

Does that make sense? 😄

[ayushkumar8340]

Yup got it. I'll keep you posted about the updates.

[ayushkumar8340]

I had a few doubts regarding the implementation of this problem statement :

1. As you mentioned, there should be a mechanism to turn on/off the task server doing docking detection but when i went through the code i found out that both the plugins: simple charging dock and simple non-charging dock subscribes to a topic to get the dock pose and there no such mechanism to trigger the detection node as it is a separate package.

Source : https://github.com/open-navigation/opennav_docking/tree/ubr1_testing

So do you want me to add some logic inside the detection node but according to me that would not be a good and scalable solution.
Or do I need to use the std::system() function to start a process (the detector node) and then kill it using the same.

I don't think both the solutions are good enough. What do you recommend ?

2. Does the service which i have to create will have 1 field (Just confirmation):
   a. type -> dock plugin type to enable

[mikeferguson]

Since the image_proc nodes are lazy, if you have the plugin unsubscribe from the detected_dock_pose topic then the track_marker_node will continue to run but have pretty much zero overhead (as it will also unsubscribe from the image_raw topic)

[SteveMacenski]

1. This is true for the current detectors, but not all detectors are that way. Many are based on AI solutions which are heavy to run continuously and should only be enabled when required.

However, as Fergs points out, we can still subscribe and unsubscribe from that topic to automatically start/stop the detection within our new APIs (rather than calling a service) to do the same for the case of the Apriltag detector. The way I'm suggesting you implement this has service calls (if configured) to enable / disable -- but also would be good to subscribe / unsubscribe as well for those that implement lazy publishers instead! The service calls using a std_srvs/Trigger - if the service_name is set as an available option. Otherwise, just subscribe / unsubscribe

2. Maybe actually use a std_srvs/Trigger. We can have the user set the service_name to be matched to the proper detector server interface. We should just put that into the docs.

[ayushkumar8340]

Thanks for the clarification. I'll start working now.

[SteveMacenski]

@ayushkumar8340 any updates? :-) Its been a little while and I think this should be relatively straight forward

[bkoensgen]

hi @SteveMacenski,

since there hasn't been activity on this issue for a while, I'd be happy to take it on if thats okay. I've looked at the discussion and i understand the approach; adding service calls to enable/disable detectors while keeping the lazy subscribe/unsubscribe as fallback.

i can have a draft PR ready by tomorrow for feedback.

Thanks!

[SteveMacenski]

Please! I appreciate it thanks!