[Unitree GO2 EDU]Problem with OpenManipulator

Hi,
I am using Unitree GO2 EDU with steam deck and open manipulator.
To use the open manipulator I first start the driver with ros2 launch go2_manipulation openmanipulator.launch.py and then I start moving the joints as in the manual.

    ROS_DOMAIN_ID=10 ros2 action send_goal \
    /go2_unit_41097/open_manipulator/joint_trajectory_controller/follow_joint_trajectory \
    control_msgs/action/FollowJointTrajectory -f '{
    "trajectory": {
        "joint_names": ["joint1","joint2","joint3","joint4"],
        "points": [
        {"positions":[ 0.10, 0.10, 0.10, 0.10], "time_from_start":{"sec":2}},
        {"positions":[-0.10,-0.10,-0.10,-0.10], "time_from_start":{"sec":4}},
        {"positions":[ 0.00, 0.00, 0.00, 0.00], "time_from_start":{"sec":6}}
        ]
    }
    }'

This movement is sometimes failed with part of the arm falling in front of the robot head. I purpose this is related to battery voltage and not enough voltage is given to the motors.
Another main problem is the gripper. When I use

ROS_DOMAIN_ID=10 ros2 action send_goal \
/go2_unit_41097/open_manipulator/\
gripper_controller/follow_joint_trajectory \
control_msgs/action/FollowJointTrajectory -f '{
"trajectory": {
"joint_names": ["gripper"],
"points": 
{"positions":[-1.0], "time_from_start":{"sec":2}},
]
}
}'

to open the gripper.
It worked and should work. But this week, there is no respond on the gripper although in terminal it shows the movement goal was successful. What is much more weird, the gripper should be loose and can be adjusted by hand when the driver is not started. But for now, even when I stop the power supply, there is great brake feeling on the gripper motor. Maybe the motor is changed into a brake mode? The gripper only moves a little bit when I apply much more power on it. But I do not apply too much to avoid damage. Was there similar situation and do you know what is the cause and how to solve? Many thanks in advance!

Hi,

@Azib could you please check.

Dear @markus_xue

Based on the information provided, it appears that there may be a power shortage affecting the arm during operation.

I recommend checking whether the U2D2 is connected to the 12V output of the top docking station rather than the 5V output.

If it is already connected to 12V, please open the small cover on the right side of the arm. Inside, you will find a buck converter. Kindly verify that the output voltage of the buck converter is within the range of 11.8V to 12V.

Hi Azib, thanks for your answer. Do you mean the problem with arm part? We have discovered that this might be cause by the problem, when the motor is asked to drive however the arm is somehow blocked for example touches the outer skin of Nvidia Jetson. Then there might be bias with the motor itself or protection function in it. Once we restart the total robot, the problem seems to be solved.

Do you also know the solution to solve the gripper part problem. The gripper keeps the state like being braked.

Dear @markus_xue,

It seems that the issue might be related to self-collision . I would suggest running the MoveIt package after enabling the OM driver in a separate terminal.

To activate our MoveIt driver, please run:

ros2 launch go2_manipulation moveit2.launch.py

This should allow you to check whether any collisions are being detected.

Using the same interface, you can also test the gripper function by opening and closing it from there.

Dear @Azib ,
thanks for your answer. I have done similar steps. How can I see whether there are collisions? I have tried to use motion planning moveit2 tool in RViz2 and use the open/close gripper motion plan. But there is also no move.
And after I stop the OM driver and the total power supply of the dog, the motor of gripper remains the strong brake feeling.

Dear @Azib,
continued the work of @markus_xue yesterday, we checked the power supply of the arm, it is correctly connected to the 12V output.
Furthermore checked the OM movement in Moveit package, joints 1-4 of the arm can be planned and executed/moved correctly, however the gripper does not react at all, there don’t seem to be collisions with the gripper or arm links, but there is a constant: “Goal state colliding links: computer_dock_link - steamdeck_bracket_link” but that shouldnt that affect the gripper?

Is there another way to check gripper servo for functionality, or is it at this point likely that the servo is broken?

Thanks and kind regards,
Philip