Skip to content

Improve robotic_manipulation_node stability #8

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

Merged
merged 4 commits into from
Mar 28, 2025

Conversation

knicked
Copy link
Contributor

@knicked knicked commented Mar 5, 2025

This PR:

  • improves the stability of the robotic_manipulation_node by waiting for the simulation to open before making any requests to moveit actions, in case the node is launched before the simulation.

  • updates the MoveThroughWaypoints method not to fall into an infinite loop if moveit decides not to work correctly, but rather abandon making a move after a chosen number of tries (currently 10).

  • adds a /reset_manipulator service of type std_srvs/srv/Trigger that allows to reset all the manipulator joints back into the starting positions (useful when after making a few moves the manipulators ends in an unnatural positions and the chance of moveit failing rises)

knicked added 2 commits March 5, 2025 14:13
Signed-off-by: Kacper Dąbrowski <[email protected]>
Signed-off-by: Kacper Dąbrowski <[email protected]>
@jmatejcz
Copy link

jmatejcz commented Mar 20, 2025

Tested on Ubuntu 22 + humble, branch -> https://github.com/RobotecAI/rai/tree/jm/feat/o3de-bench-more-tasks
I've run benchmark for 30 scenarios:
python src/rai_bench/rai_bench/examples/o3de_test_benchmark.py

I didn't see weird, ineffective movements of the arm, which was the case in some scenarios earlier. It could be the infinite loop you mentioned above.

Service /reset_manipulator appeared and was available.
After every call arm came back to starting position properly.

Overall works fine for me!

Copy link
Collaborator

@jhanca-robotecai jhanca-robotecai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not like the blocking call in the constructor, but the code does the job. Since it is a minimal codebase, I could live with it.

The whole workspace should get some attention: I would suggest at least adding a license note in every file and clang-format the files.

@@ -19,10 +19,12 @@ class ArmController {
bool GetGripper();

std::vector<double> CaptureJointValues();
void SetJointValues(std::vector<double> const &jointValues);
bool SetJointValues(std::vector<double> const &jointValues);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of the scope of this change: some consistency with const T & vs. T const & would be an added value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see my latest comment

ArmController::ArmController() {
m_node = rclcpp::Node::make_shared("arm_controller");
m_node->set_parameter(rclcpp::Parameter("use_sim_time", true));

WaitForClockMessage();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if a constructor is the best place to put a blocking call.

@knicked
Copy link
Contributor Author

knicked commented Mar 24, 2025

Thanks for the review @jhanca-robotecai! I created a separate PR to this branch containing the suggested changes and a few more to generally improve the code quality of the package: #11. If you have any other suggestions, please leave comments in that PR.

@jhanca-robotecai jhanca-robotecai merged commit d6dd247 into development Mar 28, 2025
@jhanca-robotecai jhanca-robotecai deleted the kd/wait_for_clock branch March 28, 2025 12:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants