I added an example using the Isaac ROS cuMotion planner, you find a quickstart in this topic in NVIDIA Developer Forums.
I’ll try to share here some of the design choices and features I used in this repo when I can. To begin, one of the things I missed transitioning from industrial robot’s languages was a simple way to define a move or series of moves. Here’s how the move sequences are defined in the manymove_cpp_trees bt_client.cpp file:
std::vector<Move> rest_position = {
{robot_prefix, "joint", "", joint_rest, "", move_configs["max_move"]},
};
std::vector<Move> scan_surroundings = {
{robot_prefix, "joint", "", joint_look_sx, "", move_configs["max_move"]},
{robot_prefix, "joint", "", joint_look_dx, "", move_configs["max_move"]},
};
// Sequences for Pick/Drop/Homing
std::vector<Move> pick_sequence = {
{robot_prefix, "pose", "approach_pick_target", {}, "", move_configs["mid_move"]},
{robot_prefix, "cartesian", "pick_target", {}, "", move_configs["cartesian_slow_move"]},
};
std::vector<Move> drop_sequence = {
{robot_prefix, "cartesian", "approach_pick_target", {}, "", move_configs["cartesian_mid_move"]},
{robot_prefix, "pose", "approach_drop_target", {}, "", move_configs["max_move"]},
{robot_prefix, "cartesian", "drop_target", {}, "", move_configs["cartesian_slow_move"]},
};
std::vector<Move> home_position = {
{robot_prefix, "cartesian", "approach_drop_target", {}, "", move_configs["cartesian_mid_move"]},
{robot_prefix, "named", "", {}, named_home, move_configs["max_move"]},
};
As you can notice, it resembles how moves are defined in languages like KRL or RAPID. Yep, it still miss many features available there, give me some time! But also, I feel that with ROS and the AI wave we may have to explore new approaches on move management, so keeping it as minimal as possible could be better right now.
All these moves are defined in the previous part of the file. Joint moves are defined through a vector of double values, and once they are defined they are fixed. Pose/Cartesian moves are associated to a blackboard key, and these can be modified at runtime by modifying the key value.
This was designed to allow me to obtain the pose of an object dynamically through an AI vision system, but it can also be useful if two or more robots need to interact, or if I need to grab a component in a moving transport system knowing its position at a certain time and its speed.
One thing I don’t like is the number of lines of code I need to define a pose. I will try to reduce it or create an helper function in the future. Is it something you feel is needed or am I overthinking it?