Suggestion for new dynamic detachable joint plugin (Issue #2362) #3086

AdarshKaran · 2025-09-11T14:52:49Z

🎉 New feature

Summary

Created a dynamic_detachable_joint system as an extension of the detachable joint system where the childModelName and childLinkName can now be passed through a gz service or a ROS2 service (a bridge has also been added for this). A command: attach or detach can be specified in the service call. I have also added an attachDistance option that allows you to specify how far the child should be to be considered attached.

Most of the code is based on the already existing DetachableJoint Plugin logic

Test it

Adding the plugin to robot model URDF/SDF

    <gazebo>
      <plugin filename="gz-sim-dynamic-detachable-joint-system"
            name="gz::sim::systems::DynamicDetachableJoint">
        <parent_link>robotiq_85_left_finger_tip_link</parent_link>
        <service_name>/payload/attach_detach</service_name>
        <output_topic>/child_state</output_topic>
        <attach_distance>0.25</attach_distance>
      </plugin>
    </gazebo>

GZ Service call command

# Attach
gz service -s /payload/attach_detach \
    --reqtype gz.msgs.AttachDetachRequest \
    --reptype gz.msgs.AttachDetachResponse \
    --timeout 3000 \
    --req 'child_model_name: "cube", 
           child_link_name: "link", 
           command: "attach"'

# Detach
gz service -s /payload/attach_detach \
    --reqtype gz.msgs.AttachDetachRequest \
    --reptype gz.msgs.AttachDetachResponse \
    --timeout 2000 \
    --req 'child_model_name: "cube", 
           child_link_name: "link", 
           command: "detach"'

ROS2 Service call command

# Attach
ros2 service call /payload/attach_detach \
    ros_gz_interfaces/srv/AttachDetach \
    "{child_model_name: 'cube', 
      child_link_name: 'link', 
      command: 'attach'}"

# Detach  
ros2 service call /payload/attach_detach \
    ros_gz_interfaces/srv/AttachDetach \
    "{child_model_name: 'cube', 
      child_link_name: 'link', 
      command: 'detach'}"

Checklist

Generated-by: Remove this if GenAI was not used.

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by and Generated-by messages.

ahcorde

It will be great to add some details in the header file as documentation

ahcorde · 2025-09-12T08:18:56Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+using namespace systems;
+
+/////////////////////////////////////////////////
+void DynamicDetachableJoint::Configure(const Entity &_entity,


hi! could you please clarify what header is missing here?

https://github.com/gazebosim/gz-sim/blob/361af45888b96fd860f56c9c2c785fe61e339113/src/systems/dynamic_detachable_joint/DynamicDetachableJoint.hh#L40C1-L64C64

I have added these comments in the header file similar to what was done in the existing DetachableJoint.hh plugin. If you could clarify if i need to add more detailed comments with usage example in the .cc source file above the Configure function then I shall do that.

ahcorde · 2025-09-12T08:19:19Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+                EntityComponentManager &_ecm,
+                EventManager &/*_eventMgr*/)


include header for EntityComponentManager and EventManager

ahcorde · 2025-09-12T08:19:34Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+
+  if (_sdf->HasElement("parent_link"))
+  {
+    auto parentLinkName = _sdf->Get<std::string>("parent_link");


include <string>

ahcorde · 2025-09-12T08:20:05Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+#include <gz/plugin/Register.hh>
+#include <gz/transport/Node.hh>
+
+#include <gz/common/Profiler.hh>
+
+#include <sdf/Element.hh>


alphabetize

ahcorde · 2025-09-12T08:21:05Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+  gzdbg << "using service: "
+        << this->serviceName << std::endl;


Suggested change

gzdbg << "using service: "

<< this->serviceName << std::endl;

gzdbg << "Using service: " << this->serviceName << std::endl;

ahcorde · 2025-09-12T08:22:13Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+      gzwarn << "Child Model " << this->childModelName
+              << " could not be found.\n";


Suggested change

gzwarn << "Child Model " << this->childModelName

<< " could not be found.\n";

gzwarn << "Child Model " << this->childModelName

<< " could not be found.\n";

ahcorde · 2025-09-12T08:22:41Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+     _res.set_message("Attached to child model " + this->childModelName +
+                    " at link " + this->childLinkName + ".");


Suggested change

_res.set_message("Attached to child model " + this->childModelName +

" at link " + this->childLinkName + ".");

_res.set_message("Attached to child model " + this->childModelName +

" at link " + this->childLinkName + ".");

ahcorde · 2025-09-12T08:23:28Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.hh

+                           EntityComponentManager &_ecm,
+                           EventManager &_eventMgr) final;


include headers for EntityComponentManager and EventManager

ahcorde · 2025-09-12T08:23:37Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.hh

+    private: bool OnServiceRequest(const gz::msgs::AttachDetachRequest &_req,
+                                  gz::msgs::AttachDetachResponse &_res);


Suggested change

private: bool OnServiceRequest(const gz::msgs::AttachDetachRequest &_req,

gz::msgs::AttachDetachResponse &_res);

private: bool OnServiceRequest(const gz::msgs::AttachDetachRequest &_req,

gz::msgs::AttachDetachResponse &_res);

ahcorde · 2025-09-12T08:24:27Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.hh

+    private: Entity detachableJointEntity{kNullEntity};
+
+    /// \brief Whether detachment has been requested
+    private: std::atomic<bool> detachRequested{false};


include <atomic>

arjo129 · 2025-09-13T07:18:01Z

Thanks for this contribution @AdarshKaran! Please sign off your commits. You can see how here: https://github.com/gazebosim/gz-sim/pull/3086/checks?check_run_id=50152759632

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

…, added clearer loggin Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

AdarshKaran · 2025-09-17T07:58:11Z

I have addressed the comments. Once my doubt regarding the documentation comment is clarified, I'll add that commit.

arjo129

Thanks for the contribution! This can be super useful.

I'm being a bit picky, but:
(1) We should at least have an integration test for this system.
(2) Check indentation + Address the comments I've left for you.
(3) You may need to use a lock instead of atomics as we are configuring multiple parameters at once.

arjo129 · 2025-09-17T22:00:07Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+              << std::endl;
+      }
+      else
+      {


Knit: I recommend applying the error-first pattern (also called "happy path" programming) here. By checking for and returning early on error conditions, we can significantly reduce code nesting and enhance the overall readability.

Reference: https://preslav.me/2023/09/22/ditch-that-else/

arjo129 · 2025-09-17T22:05:27Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+               << " could not be found.\n";
+      }
+    }
+    else if (!this->suppressChildWarning)


Knit: Why do we need this. Can't we just rely on gazebo's verbosity level?

I actually followed the same pattern as the existing Detachable Joint cc for this.
https://github.com/gazebosim/gz-sim/blob/5dfe0ad1e6e01b8ddb915981e6b3da2efd3cf673/src/systems/detachable_joint/DetachableJoint.cc#L306C1-L311C2
Do we still keep it or remove it for now?

Yeah, that plugin does need a refactor.

So, do you suggest to remove suppressChildWarning and instead just have

// if child model is not found if (kNullEntity == modelEntity) { gzdbg << "Child Model " << this->childModelName << " could not be found.\n"; return; }

gzdbg instead of gzwarn?

No keep it as gzwarn just dont bother with the suppress child option.

arjo129 · 2025-09-17T22:07:34Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+     if (this->isAttached) 
+     {
+       _res.set_success(false);
+      _res.set_message("Already attached to child model " + this->attachedChildModelName +


Knit: Indentation issue

arjo129 · 2025-09-17T22:10:52Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+  gz::msgs::StringMsg detachedStateMsg;
+  if (attached)
+  {
+    detachedStateMsg.set_data("attached to " +


Why are we publishing a custom message with custom semantics? I'm not sure we should publish this at all.

I followed the same pattern as DetachableJoint.cc

https://github.com/gazebosim/gz-sim/blob/5dfe0ad1e6e01b8ddb915981e6b3da2efd3cf673/src/systems/detachable_joint/DetachableJoint.cc#L370C1-L383C2

do we still remove this too?

DetachableJoint.cc publishes only 2 types of outputs: "attached" or "detached" (if I were redesigning this I'd just publish a bool), in your case you publish "attached to ..." . If I were writing a parser to interact with your software I'd have to look up this magic string. Its much better to either publish an empty string or just the linked name so end users dont have to write custom parsers. Alternatively publish the entity/knullentity that the object is attached to.

That's a good point. I did not think from that angle. But how exactly would we be able to differentiate bw attached and detached state in the case of an empty string or which model it is attached to in case of link name(when different models have same link names)?
So maybe in that case, using the entity/knullentity like you said is a better option?

void DynamicDetachableJoint::PublishJointState(bool attached) { gz::msgs::Entity stateMsg; if (attached) { stateMsg.set_id(this->childLinkEntity); stateMsg.set_type(gz::msgs::Entity::LINK); } else { stateMsg.set_id(kNullEntity); stateMsg.set_type(gz::msgs::Entity::NONE); } this->outputPub.Publish(stateMsg); }

and in the topic echo

id: 29 type: LINK id: 25 type: LINK

when i do

ros2 service call /payload/attach_detach ros_gz_interfaces/srv/AttachDetach "{child_model_name: 'can_2', child_link_name: 'body', command: 'attach'}" ros2 service call /payload/attach_detach ros_gz_interfaces/srv/AttachDetach "{child_model_name: 'can_2', child_link_name: 'body', command: 'detach'}" ros2 service call /payload/attach_detach ros_gz_interfaces/srv/AttachDetach "{child_model_name: 'can_1', child_link_name: 'body', command: 'attach'}" ros2 service call /payload/attach_detach ros_gz_interfaces/srv/AttachDetach "{child_model_name: 'can_1', child_link_name: 'body', command: 'detach'}"

so basically we could extract the model name from the link entity and in detach state we publish a knullentity so it's empty.
does this change seem good?

#include <gz/msgs/entity.pb.h>

Just this extra dependency though

Yeah that seems reasonable to avoid any sense of ambiguity.

arjo129 · 2025-09-17T22:11:59Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+ }
+
+//////////////////////////////////////////////////
+void DynamicDetachableJoint::OnAttachRequest(const msgs::Empty &)


Why are we passing an empty message for no reason? We don't actually need this method.

I actually kept the two function just to like separate concerns and to also keep it extensible in the future. But, if its better to simplify it then I'll remove it for now. Like you said it actually makes more sense to remove since there is an unwanted dependency on the empty proto msg.

I suggest removing it for now

arjo129 · 2025-09-17T22:17:16Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+    this->childModelName = _req.child_model_name();
+    this->childLinkName  = _req.child_link_name();
+     this->OnAttachRequest(msgs::Empty());
+     _res.set_success(true);


knit: Indentation

arjo129 · 2025-09-17T22:19:22Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+    // set the child model and link names from the request
+    this->childModelName = _req.child_model_name();
+    this->childLinkName  = _req.child_link_name();
+     this->OnAttachRequest(msgs::Empty());


directly assign the this->attachRequested = true; without calling the method,

arjo129 · 2025-09-17T22:22:29Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+     }
+
+    // set the child model and link names from the request
+    this->childModelName = _req.child_model_name();


Knit: I don't think atomics are sufficient here. You do need to use a lock to guarantee data consistency between
this->childModelName, this->childModelName and this->attachRequested.

Regarding mutex locks, I haven't worked much with them before so please guide me here.

@@ -158,6 +159,8 @@ void DynamicDetachableJoint::PreUpdate( EntityComponentManager &_ecm) { GZ_PROFILE("DynamicDetachableJoint::PreUpdate"); + std::lock_guard<std::mutex> lock(this->mutex); + // only allow attaching if child entity is detached if (this->validConfig && !this->isAttached) { @@ -265,6 +268,7 @@ bool DynamicDetachableJoint::OnServiceRequest(const gz::msgs::AttachDetachReques gz::msgs::AttachDetachResponse &_res) { GZ_PROFILE("DynamicDetachableJoint::OnServiceRequest"); + std::lock_guard<std::mutex> lock(this->mutex); // Check if the request is valid if (_req.child_model_name().empty() || _req.child_link_name().empty() )

is it right to add them to the top of PreUpdate loop?

and for the header file, I have removed atomic

/// \brief Whether detachment has been requested - private: std::atomic<bool> detachRequested{false}; + private: bool detachRequested{false}; /// \brief Whether attachment has been requested - private: std::atomic<bool> attachRequested{false}; + private: bool attachRequested{false}; /// \brief Whether child entity is attached - private: std::atomic<bool> isAttached{false}; + private: bool isAttached{false}; /// \brief Whether all parameters are valid and the system can proceed private: bool validConfig{false}; + /// \brief Mutex to protect access to member variables + private: std::mutex mutex; }; } }

Yeah this approach will work. Although it may be a bit heavy as ideally you'd only lock for the time period which you need access to the variable for. One option is to create a scope within preupdate, lock that scope then copy out the necessary details. For our purposes, I don't think it matters.

alright then. Thank you! I'll push these changes

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

arjo129 · 2025-09-25T07:31:02Z

I have one more ask that falls outside of the integration test. Please add a demo world of some form so I/users can test it.

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

arjo129 · 2025-09-25T10:19:47Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+       _res.set_success(false);
+       _res.set_message("Already attached to child model " + this->attachedChildModelName +
+                        " at link " + this->attachedChildLinkName + ".");
+       gzdbg << "Already attached" << std::endl;


Might be worth being a bit more descriptive with the error message. Mention the linkName.

arjo129 · 2025-09-25T10:24:29Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+     }
+
+    // set the child model and link names from the request
+    this->childModelName = _req.child_model_name();


Yeah this approach will work. Although it may be a bit heavy as ideally you'd only lock for the time period which you need access to the variable for. One option is to create a scope within preupdate, lock that scope then copy out the necessary details. For our purposes, I don't think it matters.

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

AdarshKaran · 2025-09-25T11:19:22Z

I have one more ask that falls outside of the integration test. Please add a demo world of some form so I/users can test it.

Yes. I will look into it

AdarshKaran · 2025-09-25T11:35:32Z

There is actually one issue. When i give attach request and specify a child_model_name that doesn't exist in the scene, we get a true response from the service. The main reason is because we can't access EntityComponentManager within the OnServiceRequest function. Do you think there is a better way to do it? or shall we just update the response message to something like "Attach request accepted" instead of the current "Attached to child model..."?

arjo129 · 2025-09-25T11:53:06Z

There is actually one issue. When i give attach request and specify a child_model_name that doesn't exist in the scene, we get a true response from the service. The main reason is because we can't access EntityComponentManager within the OnServiceRequest function. Do you think there is a better way to do it? or shall we just update the response message to something like "Attach request accepted" instead of the current "Attached to child model..."?

Yes, this is one of the less-than-ideal side effects of the way we mix pub/sub with ECM in Gazebo. I think "Attach request accepted" may be a reasonable thing and then log an error. If need be we could publish to a seperate topic, but I'd leave that as "future work".

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

AdarshKaran · 2025-09-26T05:49:46Z

There is actually one issue. When i give attach request and specify a child_model_name that doesn't exist in the scene, we get a true response from the service. The main reason is because we can't access EntityComponentManager within the OnServiceRequest function. Do you think there is a better way to do it? or shall we just update the response message to something like "Attach request accepted" instead of the current "Attached to child model..."?

Yes, this is one of the less-than-ideal side effects of the way we mix pub/sub with ECM in Gazebo. I think "Attach request accepted" may be a reasonable thing and then log an error. If need be we could publish to a seperate topic, but I'd leave that as "future work".

Done! Please let me know if it looks good. I have also added some additional logs and errors for more clarity

arjo129

I have a quick question here. It seems like I forgot to update the review.

In general the code looks ok but I cannot approve it without examples/tests.

arjo129 · 2025-09-26T06:33:14Z

src/systems/dynamic_detachable_joint/DynamicDetachableJoint.cc

+{
+  GZ_PROFILE("DynamicDetachableJoint::PreUpdate");
+  std::lock_guard<std::mutex> lock(this->mutex);
+


A quick question : is it intended that the plugin continues to work while paused?

I don't think it should work when the sim is paused. Should we track if it is paused and return in that case (following the error first approach)?

…tests Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

AdarshKaran · 2025-10-02T08:01:08Z

I was working on the tests and example world, please let me know if it looks good after testing

Example World.

I have added clean comments in the sdf for the commands to test it with.

Test

As for the integration test, I added both a test world and the test cpp file.
I tested it with the following command after building, run from /build/gz-sim9/ directory
ctest -V -R INTEGRATION_dynamic_detachable_joint

AdarshKaran requested a review from arjo129 as a code owner September 11, 2025 14:52

github-actions bot added the 🪵 jetty Gazebo Jetty label Sep 11, 2025

azeey added this to Core development Sep 11, 2025

github-project-automation bot moved this to Inbox in Core development Sep 11, 2025

AdarshKaran mentioned this pull request Sep 11, 2025

Make child model and link configurable in DetachableJoint System #2362

Open

ahcorde requested changes Sep 12, 2025

View reviewed changes

github-project-automation bot moved this from Inbox to In review in Core development Sep 12, 2025

AdarshKaran added 3 commits September 17, 2025 13:08

init

eb49fd1

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

better logs and comments

adf8da1

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

fixed an edge case where detach did not obey the requested model name…

33c1fd6

…, added clearer loggin Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

AdarshKaran force-pushed the plugin/dynamic_detachable_joint branch from 361af45 to 33c1fd6 Compare September 17, 2025 07:54

fixed indentation and headers

4134165

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

arjo129 requested changes Sep 17, 2025

View reviewed changes

AdarshKaran added 4 commits September 25, 2025 10:15

more indentation fixes - nits

3ec1aff

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

removed unwanted dependency on Empty proto

6474e12

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

used error first approach for better readability

15793fe

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

publishing link entity instead of string msg#

86eca08

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

removed suppress child option

36eaffa

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

arjo129 reviewed Sep 25, 2025

View reviewed changes

AdarshKaran added 2 commits September 25, 2025 16:45

added mutex lock guard instead of atomic

9204cc4

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

updated debug msg

99e2c62

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

improved logging, added reset for attachRequested flag

fc1cb56

Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

arjo129 reviewed Oct 1, 2025

View reviewed changes

Added example world, integration test and test worlds, also verified …

97fe177

…tests Signed-off-by: Adarsh Karan Kesavadas Prasanth <adarshkaran01@gmail.com>

		gzdbg << "using service: "
		<< this->serviceName << std::endl;

	gzdbg << "using service: "
	<< this->serviceName << std::endl;
	gzdbg << "Using service: " << this->serviceName << std::endl;

		gzwarn << "Child Model " << this->childModelName
		<< " could not be found.\n";

		_res.set_message("Attached to child model " + this->childModelName +
		" at link " + this->childLinkName + ".");

		EntityComponentManager &_ecm,
		EventManager &_eventMgr) final;

		private: bool OnServiceRequest(const gz::msgs::AttachDetachRequest &_req,
		gz::msgs::AttachDetachResponse &_res);

Suggestion for new dynamic detachable joint plugin (Issue #2362) #3086

Are you sure you want to change the base?

Suggestion for new dynamic detachable joint plugin (Issue #2362) #3086

Uh oh!

Conversation

AdarshKaran commented Sep 11, 2025

🎉 New feature

Summary

Test it

Checklist

Uh oh!

ahcorde left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arjo129 commented Sep 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AdarshKaran commented Sep 17, 2025

Uh oh!

arjo129 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AdarshKaran Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AdarshKaran Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arjo129 Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arjo129 commented Sep 13, 2025 •

edited

Loading

AdarshKaran Sep 25, 2025 •

edited

Loading

AdarshKaran Sep 25, 2025 •

edited

Loading

arjo129 Sep 25, 2025 •

edited

Loading

AdarshKaran Sep 25, 2025 •

edited

Loading