eDO-community / eDO_control

ROS control stack for real e.DO v2 robots (bought before 2019, Oct)
GNU General Public License v3.0
1 stars 3 forks source link

Error in executing trajectory #6

Open lucamarchionna opened 3 years ago

lucamarchionna commented 3 years ago

Hi eDO-community, I have tried to test this package on a real e.DO robot. However, the following error comes up:

[ERROR] [1620209216.682840]: Exception in your execute callback: Invalid number of arguments, args should be ['position', 'velocity', 'current', 'ff_velocity', 'ff_current', 'R_rasp'] args are(60, 0, 0, 0, 0)

Probably, I'm invoking the wrong services. As a consequence, MoveIT fails to connect with eDO. Thus, the topic /joint_states and /bridge_move remain remains empty and the real robot doesn't move.

I am using ROS Noetic and Python 3. How can I fix the problem? Thanks in advance.

ymollard commented 3 years ago

It looks like you are using an eDO v3 while this package only works with eDO v2. Please try eDO_control_v3 instead, I think that this commit in particular fixes your issue.

lucamarchionna commented 3 years ago

I confirm that, since the e.DO has the updated version, I am using the package eDO_control_v3. I fix the past issue by cloning and building it again. I am facing a further problem now. It is related with the joint trajectory_action_server.py file since, when I try to launch it, the robot stops working. This is confirmed also by the topic /machine_state that assumes the following values: -When the control.launch is triggered, the current_state in /machine_state moves from 2 to 255 (machine busy). -When I try to move one joint, the current_state switches from 2 to 4 (i.e jog) ,but without moving the real robot. Afterthat, it returns to 2. In addition, I got the following warn: [WARN] [1620316797.544283]: Robot's algorithm manager has been disabled

Conversely, the other file included in control.launch -joint_state_publisher.py- works fine. It seems that e.DO assumes a wrong configuration. How can I solve this issue? Thanks to everyone.

ymollard commented 3 years ago

The JTAS commands the robot with the /algo_jnt_ctrl topic: do you see data being published during a JTAS motion when you rostopic echo /algo_jnt_ctrl? (check this while being ssh-ed to the robot). The warning that you get is alright: the ROS controller disables the sort of custom program loader created by Comau so that the Android app works with it.

lucamarchionna commented 3 years ago

Great @ymollard, this could be the problem. I have noticed that /algo_jnt_ctrl topic publishes data until I run joint_trajectory_action_server.py file. Once it is launched, the topic no longer publishes data.

Also, there are differencies when trying to move the robot through joint values. The images below refere to the situation before and after the joint_trajectory_action_server. Schermata del 2021-05-07 11-28-10 dopo

Afterwards, the following error appears when rostopic pub /open_gripper std_msgs/Bool "data: true" is executed. error

ymollard commented 3 years ago

have noticed that /algo_jnt_ctrl topic publishes data until I run joint_trajectory_action_server.py file

This is nominal, because the custom algorithm manager from Comau is stopped when the JTAS starts (this is the warning you mentioned 2 messages ago). Afterwards it is no longer published all the time but it should be published again only when a motion is being executed e.g. with MoveIt. Is it the case?

For the gripper, can you add a zero line 138 here, e.g. self.gripper_position, 0, 0, 0, 0 becomes self.gripper_position, 0, 0, 0, 0, 0, it looks like a bug.

lucamarchionna commented 3 years ago

Okay, I got it. Unfortunately, this is not the case because the /algo_jnt_ctrl topic remains empy once the control.launch is executed. Thanks for your advice @ymollard , it fixes the problem. Now, I am able to use /open_gripper. Only when the gripper is activated, the /algo_jnt_ctrl publishes data. This should be right.

However, the gripper moves while the robot itself doesn't. This makes this issue really weird. Also, the /machine_state returns current_state: 3 that makes any other move unfeasible.

ymollard commented 3 years ago

Actually the same bug appears at line 306, you can add an extra zero as well.

lucamarchionna commented 3 years ago

I've edited it, but it didn't fix the problem. Moreover, I also tried to move the robot with MoveIT but e.DO doesn't move altough the simulation works without errors.

ymollard commented 3 years ago

any idea @Bracewind?

lucamarchionna commented 3 years ago

@Bracewind some advice?

ymollard commented 3 years ago

I wonder if your additional 0 has actually taken into account, have you re-catkin-maked your workspace and sourced setup.bash? Can you check that the line mentioned by error Invalid number of arguments has actually 6 passed values and not 5?