servo interface

[hdumcke]

Hardware interface uses the convention that we receive 12 servo angles in radians. We measure the servo angle, relative to the vertical (z) axis As we use a special Quadruped (hip and knee servos are mounted to the body, knee uses a parallelogram) we can not set hip and knee independently. This is corrected as part of the hardware interface We also order the legs in RF, LF, RB, LB order

The implementation of servo_interface uses a different order and manipulates the knee angle

Are there any well defined rules how a JointTrajectoryPoint message is constructed.

If we are free to interpret the positions what are the implications to use the the convention we use with the Stanford controller?

[Tiryoh]

This ordering constraint is not due to JointTrajectoryPoint, but to URDF and CHAMP. I have forgotten many parts of the story, so I will show partial information to avoid telling an inaccurate story.

JointTrajectoryPoint

JointTrajectoryPoint is just a type to specify velocity, position, etc. https://docs.ros2.org/galactic/api/trajectory_msgs/msg/JointTrajectoryPoint.html

quadruped_controller_node

quadruped_controller_node in champ ROS package publishes the JointTrajectoryPoint typed topic

publisher is defined here https://github.com/chvmp/champ/blob/049b33ccaf77847bbea168cbb0a11c260ce119cd/champ_base/src/quadruped_controller.cpp#L145

kinematics is calculated here https://github.com/chvmp/libchamp/blob/8c50f649b3fd28a123beaf6f9618ddfaa1589559/kinematics/kinematics.h

joint angles order

The joint angles were specified in this order before the mini_pupper_bsp package was created. https://github.com/mangdangroboticsclub/mini_pupper_ros/pull/22/files

URDF

CHAMP is intended to be a URDF as follows

[hdumcke]

Let's work on the full integration and then come back to this issue.There are some options on how to get this fixed but we should focus on functionality first