Simpler Python Wrapper Interest?

[tcappellari-bdai]

Hi friends!

We have developed some Python wrappers using synchros2 to simplify action creation and calling and are deciding whether to open source these. These wrappers are meant to abstract most of the ROS away to make service/action calls simpler. Here's a quick example to demonstrate:

To command Spot to walk forward using spot_drtiver (taken from spot_examples/walk_forward.py):

world_t_robot = self._tf_listener.lookup_a_tform_b(self._vision_frame_name, self._body_frame_name)
world_t_robot_se2 = SE3Pose(
      world_t_robot.transform.translation.x,
      world_t_robot.transform.translation.y,
      world_t_robot.transform.translation.z,
      Quat(
          world_t_robot.transform.rotation.w,
          world_t_robot.transform.rotation.x,
          world_t_robot.transform.rotation.y,
          world_t_robot.transform.rotation.z,
)).get_closest_se2_transform()
world_t_goal = world_t_robot_se2 * ROBOT_T_GOAL
proto_goal = RobotCommandBuilder.synchro_se2_trajectory_point_command(
      goal_x=world_t_goal.x,
      goal_y=world_t_goal.y,
      goal_heading=world_t_goal.angle,
      frame_name=VISION_FRAME_NAME,  # use Boston Dynamics' frame conventions
)
action_goal = RobotCommand.Goal()
convert(proto_goal, action_goal.command)
self._robot_command_client.send_goal_and_wait("walk_forward", action_goal)

To send the same command via our new wrappers:

with self._robot.leash():
        world_t_robot = self._robot.lookup_a_tform_b(
            self._robot.vision_frame_name, self._robot.body_frame_name).yaw_SE2()

        robot_t_goal = SE2(1.0, 0.0, 0.0)
        world_t_goal = world_t_robot * robot_t_goal
        self._robot.walk.synchronously(world_t_goal) # or asynchronously and get a future object to unwrap

Would this be of interest to the community?

Thanks!
RAI Institute Spot SW Team

[heuristicus]

Is the intent of this wrapper to live above spot_ros2 and make it easier to call things, or does it replace some part of what we currently have?

[tcappellari-bdai]

It's intent is to live above the current spot_driver so users would have access to both options. We are using these wrappers internally at the moment and looking to see if there is enough interest to justify open sourcing them.

[zmk5]

Great idea. I've done something similar in my spot behavior tree package I made, but it is very rudimentary. It would be great if we have something formalized by our team instead. Let me know if you need any help.

[volkerkrueger]

This would be a great idea.
I have a number of student projects starting up this week, and we could start testing immediately, if that is of any help.