Reporting two bugs

[zhalehmehrabi]

Dear Organizers,

I hope you are doing well. I am writing to bring to your attention two issues that require your confirmation as to whether they are small bugs or intentional parts of the competition.

1. Firstly, I would like to draw your attention to the success criterion for the Defend and Prepare tasks. As per the criterion, the puck must be within hitting range and have a longitudinal speed below a certain threshold. However, I have noticed that the criterion considers only the positive velocity, which is when the puck is moving to the right. This unintended interpretation is compounded by the fact that the condition in lines 101 and 105 of the air_hockey_challenge_wrapper.py file only consider velocity in the x-axis when the puck is moving to the right. When the puck is moving to the left, the velocity is negative, and the second condition is always true. This leads to incorrect results when the puck is moving to the left, regardless of its actual speed, and causes incorrect success flags. I request you to look into this matter and take the necessary action to rectify the issue.

2. Furthermore, I have observed strange behavior in the 7dof system when commanding the robot not to move. Initially, we experimented with not moving the robot for its initial joint positions, using the following code:

new_joint_pos = self.get_joint_pos(obs)
joint_velocities = np.zeros_like(new_joint_pos)
action = np.vstack([new_joint_pos, joint_velocities])

However, we noticed that the end-effector moved slowly towards the robot and below the table. As a result, we conducted another experiment based on the end-effector position. We use inverse kinematics to calculate joint positions and joint velocities. Firstly, we randomly generated a point (called X) in the allowed part of the table on the x-axis. Then, we created an array of 20 different points (array called Y) that slice the y-axis equally and commanded the robot to move to (X, Y[i]) for i ranging from 0 to 19 ( each for an episode). To ensure that the constraints were not broken, we generated 100 points between the destination and the initial end-effector position using np.linspace. When the end-effector reached the destination point, we commanded 10 more destination points to confirm that the end-effector was actually on the destination point. Finally, we commanded the robot not to move using the following code:

new_joint_pos = self.get_joint_pos(obs)
joint_velocities = np.zeros_like(new_joint_pos)
action = np.vstack([new_joint_pos, joint_velocities])

We then calculated the deviation from our command using the following code:

deviation = np.sum(np.abs(self.get_joint_vel(obs)))

As the velocity commanded was zero, the above line calculates a variable that shows the robot's joint velocity deviations from zero. Consequently, we drew a heat map of these deviations.

https://drive.google.com/file/d/1JyHnPG12NmittBvVyA_0-W8cPYg39LAy/view?usp=sharing

Lastly, I would like to draw your attention to the white points on the border of the heat map. These points indicate the cases in which the puck entered the goal before the experiment finished.

I appreciate your attention to these matters and look forward to hearing your feedback.

Best regards,
RL3_polimi Team

[PuzeLiu]

Hi,
Thanks for your feedback. We are sorry for your misunderstanding since some are not well documented.

1. The X-direction of the robot is aligned with the table's long side. And Y direction is pointing to the robot's left along the short side. This is a typical ROS convention and is pictured in the documentation:
   https://air-hockey-challenges-docs.readthedocs.io/en/latest/environments.html
   We are following the X-Red, Y-Green, and Z-Blue conventions. We are sorry for the confusion since the convention is not explicitly written.
   In the termination criterion, we consider the velocity along the x-direction to be smaller than a small positive threshold, indicating the puck is not leaving too fast to the other side of the table, i.e., out of control. But, if the puck is moving along the negative x direction, it is still under control. You can take other actions, such as hitting or defending.
2. Regarding the second problem. I assume you update the target point to the current joint position at each time step. This will cause the drifting phenomenon due to the tracking error. For example, if the gravity compensation is imperfect, there will be some small errors, and the robot will be lower than it should be. If you use the new position as the target, this drift accumulates. If you only set the target point initially and don't update. This drift effect will not happen.
   Unfortunately, we don't have access to the file that you provide. Can you give us access, such that we can help you out？

[PuzeLiu]

The GitHub didn't forward properly to the page. I was finally able to open the picture. However, I don't understand the problem.
One thing that may help is instead of new_joint_pos = self.get_joint_pos(obs), you can set the new_joint_pos as the last point of the trajectory to avoid drifting.