Revision history [back]

When I am running the node, my robotic arm is performing only first trajectory .

(note: I'll assume that trajectory here should actually read trajectory point)

This is a guess, but I believe the following may explain what you observe:

1. you are publishing messages to the command topic. This is a fire-and-forget interface to the JointTrajectoryController, meaning you get no feedback and are responsible yourself to make sure "the current trajectory" has finished executing before sending a new one
2. if you don't check for completion of a trajectory, and send a new one while the controller is executing the last trajectory you sent, the controller will try to replace the current trajectory with the new one
3. you are not sending "three trajectories", but only a single one -- with three trajectory points
4. the while-loop in your main(..) causes the same trajectory to be published again and again at a frequency of 10 Hz

Taking all of this together, it's possible that what you see is completely according to how the JointTrajectoryController is specced to work:

• the same trajectory is sent as input to the controller at 10 Hz, which causes the controller to attempt execution of that trajectory
• while executing, it receives a new trajectory and will start to calculate how to join the two (ie: current and next trajectory)
• the replacement trajectory is the same trajectory, and has the first time_from_start always set to 1.0
• as 1.0 / 10 == 0.1 < 1.0, the first point of the trajectory will always be the destination point

In essence, you're giving the JointTrajectoryController a single destination (the first point in the trajectory) and always 1 second to reach it and tell it to go again to that point at a frequency of 10 Hz.

The other two trajectories are performed when I am pressing ctrl+c command

(again: I'll assume that trajectory here should actually read trajectory point)

This can be explained by the fact that once you stop your script, the JointTrajectoryController finally gets a chance to completely execute the trajectory (ie: without any replacement trajectories coming in), so it will (should) reach points 2 and 3 in 2 and 3 seconds respectively.

Finally: as I wrote in my initial comment: it's ok to use the command interface/topic, but you'll have to make sure the controller has executed the trajectory before sending a new one (or actually make use of the replacement capabilities of course).

If you're not interested in replacement, I would suggest you instead use the action interface which lets you wait on completion of a goal, notifying you when it's ok to send a new trajectory.

When I am running the node, my robotic arm is performing only first trajectory .

(note: I'll assume that trajectory here should actually read trajectory point)

This is a guess, but I believe the following may explain what you observe:

1. you are publishing messages to the command topic. This is a fire-and-forget interface to the JointTrajectoryController, meaning you get no feedback and are responsible yourself to make sure "the current trajectory" has finished executing before sending a new one
2. if you don't check for completion of a trajectory, and send a new one while the controller is executing the last trajectory you sent, the controller will try to replace the current trajectory with the new one
3. you are not sending "three trajectories", but only a single one -- with three trajectory points
4. the while-loop in your main(..) causes the same trajectory to be published again and again at a frequency of 10 Hz

Taking all of this together, it's possible that what you see is completely according to how the JointTrajectoryController is specced to work:

• the same trajectory is sent as input to the controller at 10 Hz, which causes the controller to attempt execution of that trajectory
• while executing, it receives a new trajectory and will start to calculate how to join the two (ie: current and next trajectory)
• the replacement trajectory is the same trajectory, and has the first time_from_start always set to 1.0
• as 1.0 / 10 == 0.1 < 1.0, the first point of the trajectory will always be the destination point

In essence, you're giving the JointTrajectoryController a single destination (the first point in the trajectory) and always 1 second to reach it and tell it to go again to that point at a frequency of 10 Hz.

The other two trajectories are performed when I am pressing ctrl+c command

(again: I'll assume that trajectory here should actually read trajectory point)

This can be explained by the fact that once you stop your script, the JointTrajectoryController finally gets a chance to completely execute the trajectory (ie: without any replacement trajectories coming in), so it will (should) reach points 2 and 3 in 2 and 3 seconds respectively.

Finally: as I wrote in my initial comment: it's ok to use the command interface/topic, but you'll have to make sure the controller has executed the trajectory before sending a new one (or actually make use of the replacement capabilities of course).

If you're not interested in replacement, I would suggest you instead use the action interface which lets you wait on completion of a goal, notifying you when it's ok to send a new trajectory.