I previously had a case of poor velocity control xArm7 poor velocity control mode which was resolved through email where Minna instructed me to reduce joint jerk to 1146 deg/sec^3. That resolved the issue.
But now I have another similar issue where a joint velocity profile is not tracked acceptably, especially joint 5.
This velocity profile is more of an “impulse” shape.
Hi,
Last time we suggested lowering the jerk because your target speeds were small and changed quickly — high jerk caused overshoot. This time, J6 has a higher target speed, but the current jerk may be too low to track it well.
We suggest adjusting the jerk again to match the new speed profile. Try increasing it slightly for J6 and see if tracking improves.
Okay thanks I’m going to give it a try when I get access to the robot tomorrow. In the meantime, can you explain
What the joint jerk value means? Does it relate to PID value at all?
Is there a way to set the joint jerk differently for every joint? I think the joints closer to the base can have lower joint jerk since they will move less rapidly in general.
Thanks Daniel. I’m asking more about how this jerk value is used by the controller. If I supply a series of commands that would cause joint angles to exceed the jerk limit, how can I calculate what will be the velocity actually commanded to the motor?
I want to know about the control architecture from commanded velocity → final motor torque.
Hi Mark,
In velocity mode, if current velocity deviates from target, an acceleration value is calculated from this jerk value in real-time, then acceleration integrates to next velocity value to catch up with target velocity. Of course both acceleration and velocity will have a limit imposed, if user command exceeds those limits, the actual calculation will saturate and the joint following will have a larger delay in this case.
We have optimized the calculation when the actual and target velocity get close, the oscillation caused by larger jerk is suppressed. You may try this beta firmware and adjust the jerk value for acceptable response. Additionally, you may also filter your command signal to have a smoother command and response trajectory. Please see the attached plot with this beta firmware, when jerk is set at 6500 degrees/s^3, and input qdot is slightly filtered.
Beta firmware download: V2.6.106 - Google ドライブ
Thanks for the explanation. Your plots look great I can’t wait to try the new firmware!
The qdot commands come from an admittance control experiment I was doing, and the qdots are affected by noise in the force torque sensor measurement. Filtering introduces some time lag so I was hesitant to put too much filtering.
