# joint trajectory controller: issues with arm_controller/state/desired/velocities

Hello,

I am working on a co-simulation between gazebo and simulink. Therfore I am using the Matlab ROS Toolbox to publish and subscribe to topics and the Robotics System Toolbox to synchronize gazebo with simulink. I am simulating the Franka Emika Panda using the ROS joint trajectory controller with the topic interface. So every timestep, which is 0.01s, a new trajectory message is published on the /arm_controller/command topic from simulink. Each message contains only one waypoint with joint positions and velocities specified and a time_from_start value of 0.01s.

I am confused by the behaviour of the joint trajectory controller dealing with the specified joint velocities. I will provide details and diagrams in the following.

Here you can see the joint position messages of the /arm_controller/command topic. Here you can see the joint velocity messages of the /arm_controller/command topic. So this is the desired trajectory I am calculating in Simulink and publishing to the command topic. The velocities are limited by 2 rad/s, which is less than the limits specified in ROS.

Now, the joint trajectory controller provides information about the state of a joint with the /arm_controller/state topic. You can analyse the desired and actual state of a joint. Here you can see the desired joint positions within the joint trajectory controller. The profile is the same as the one from the /arm_controller/command topic, which should be the case, right? However, the desired joint velocities are not the same as the ones from the command topic, as you can see here. There are 2 issues. Firstly, the profiles don't align and secondly, there are high jumps. Shouldn't it be the exact same profiles as the ones from the command topic?

Finally, I show you the actual states of the joints by subscribing to the /joint_states topic. Here, you can see the joint position profiles, which look really good. And here, you can see the joint velocity profiles with some high jumps. That's why I assume, that the desired velocities of the trajectory controller are the problem. I am really confused why the positon profiles look very good, but the velocity ones don't.

Has anybody an idea what the issue could be? I would be very happy for any kind of help.

My yaml-file looks like the following:

panda
joint_state_controller:
type: joint_state_controller/JointStateController
publish_rate: 100

arm_controller:
type: effort_controllers/JointTrajectoryController
joints:
-joint1
-joint2
-joint3
-joint4
-joint5
-joint6
-joint7
gains:
joint1: {p:12000, d:50, i:0, i_clamp:10000}
joint2: {p:30000, d:100, i:0.02, i_clamp:10000}
joint3: {p:18000, d:50, i:0.01, i_clamp:1}
joint4: {p:18000, d:70, i:0.01, i_clamp:10000}
joint5: {p:12000, d:70, i:0.01, i_clamp:1}
joint6: {p:7000, d:50, i:0.01, i_clamp:1}
joint1: {p:2000, d:20, i:0, i_clamp:1}
state_publish_rate: 100


And here is an example of a joint configuration in my urdf-file:

<joint name="joint1" type="revolute">
<safety_controller k_position="100 ...
edit retag close merge delete

am simulating the Franka Emika Panda using the ROS joint trajectory controller with the topic interface

what's the specific reason you're using the JointTrajectoryController, and not say, a JointGroupVelocityController or JointGroupPositionController?

( 2021-05-05 00:18:39 -0500 )edit

The spefiic reason was being able to specify positions as well as velocities for the waypoints of the trajectory. We tried using an effort_controllers/JointVelocityController before but couldn't manage to stabalize the robot. What exactly does a JointGroupController do?

( 2021-05-05 02:30:20 -0500 )edit

What exactly does a JointGroupController do?

it takes setpoints for a group of joints and applies them all at the same time. Compare that to running individual JointPosition controllers (fi), which will not synchronise anything between them at all.

We tried using an effort_controllers/JointVelocityController before but couldn't manage to stabalize the robot

That doesn't necessarily make things any easier: effort_controllers will use PID to convert velocities to efforts. This would mean you'd have (an) additional controller(s) between you and the robot, with their own gains. Tweaking gains is not trivial and now you have several layers of controllers, all influencing each other.

( 2021-05-05 02:50:30 -0500 )edit

The spefiic reason was being able to specify positions as well as velocities for the waypoints of the trajectory.

I haven't used it for this myself, could be possible. But the JTC uses trajectory replacement when you send new trajectories on the command topic. It's not a simple passthrough controller, as you seem to want to use it I believe.

This is speculation, but as you can read on that wiki page, the JTC uses interpolation to switch from the current trajectory to the replacement. That takes time (ie: a nr of control periods). Have you tried running the JTC at higher rates than you're sending it new trajectories? That could give it a sufficient nr of cycles to perform its function.

Gazebo runs typically at 1kHz internally, you could see whether running the JTC at the same rate, while still supplying it with new trajectories at ...(more)

( 2021-05-05 02:56:35 -0500 )edit

Also: isn't this a duplicate of #q376838?

( 2021-05-05 02:57:27 -0500 )edit

Thank you for your response. I will try your idea. Yes, this earlier question was from me as well, but I deleted it as I gained new information. Is it still visible for you?

( 2021-05-05 03:10:15 -0500 )edit

Yes, this earlier question was from me as well, but I deleted it as I gained new information.

it would probably have been better to edit your previous question instead of posting a new one.

Is it still visible for you?

moderators can see deleted questions, yes.

( 2021-05-05 03:12:07 -0500 )edit

Also:

Unfortunately, I am not able to post pictures right here, so I am adding some links.

you now have sufficient karma, so please attach images to your post directly.

( 2021-05-05 03:14:33 -0500 )edit