I’m working with the speedL command in the RTDE interface and am a bit unclear on the behavior of the rotational aspect of the function. The function takes in a “[rx, ry, rz]” parameter–are those the rates of change for the rx, ry, rz in the angle-axis representation that UR uses (Universal Robots - Explanation on robot orientation), or do those represent rates of change in a different rotation representation (or is there something else, e.g. a normalization step, that I’m missing)? I ran a test with speedL parameter […, …, …, 0, 0, pi/2], and I would have expected the resultant pose to only have changed in rz, but all three (rx, ry, rz) differed from the original orientation, hence my confusion.
For context, my goal is to go from a known pose 1 to a known pose 2 (both of which I have the rotation vector for) with speed control at a ~constant linear speed, and my naive solution of speedL((pose2 - pose1) / runtime) works linearly, but not rotationally.
The rotational components [rx, ry, rz] provided to the speedl() function represent a rotation vector (in axis-angle representation). Universal Robots primarily operates using rotation vectors in their orientation representation.
The rotation vector is defined with respect to the robot’s base frame, not the tool frame. So, the rotational velocity aligns with the base coordinate system.
Insights from Tests:
When you input a rotation vector into speedl([0, 0, 0, 0.5, 0.5, 0.5], 0.2), the vector [0.5, 0.5, 0.5] was treated as an angular velocity vector (in axis-angle space).
The thread verified through simulation (using the UR Log Viewer) that this input corresponded to a resultant angular speed, where the rotation happened along the axis specified by the normalized rotation vector, with a speed proportional to its magnitude.
Note:
The outcome from speedl() might not intuitively produce changes isolated to a single rotational axis unless the provided vector strictly corresponds to that direction. For example:
A value such as [0, 0, π/2] might create coupling effects since the axis-angle representation is sensitive to its normalization and frame reference.
This explanation clarifies the inconsistency you observed when all three orientation components (rx, ry, and rz) were affected in your test. It is highly probable that your rotation vector parameter inherently included some implicit coupling due to its base frame reference.
Would you like guidance on formulating your linear and angular speeds for the precise trajectory between Pose 1 and Pose 2?
Could you clarify what is meant by “angular velocity vector (in axis-angle space)”? I’d assumed it was just the time derivative of the rotation vector–are you saying that it’s actually just the default angular velocity vector (unsure what “in axis-angle space” is referring to)?
The term angular velocity vector (in axis-angle space) refers to how rotational motion is represented in the Universal Robots system and the inputs used in speedl():
1. Angular Velocity Vector Explained
Angular velocity vector: This is a 3D vector that defines the axis of rotation (its direction) and the rate of rotation around that axis (its magnitude). For example, a vector [0, 0, π/2] represents a rotation of π/2 radians per second around the Z-axis.
In axis-angle space: Universal Robots uses axis-angle representation to describe its orientation and angular velocity. In this context:
The direction of the vector [rx, ry, rz] specifies the rotational axis (not necessarily one of the Cartesian axes unless aligned with them).
The magnitude of the vector is the rotational speed in radians per second.
2. Is it the Time Derivative of the Rotation Vector?
Yes, practically speaking, the rotational velocity [rx, ry, rz] you provide to speedl() can be considered as the time derivative of the rotation vector (axis-angle). However, it’s important to note:
Since the orientation is expressed in axis-angle format, the time derivative may not directly match your intuition from other representations like Euler angles or quaternions.
It’s better to think of it as directly specifying the desired “instantaneous angular velocity vector,” aligned with your robot’s base frame.
3. How to Move from One Pose to Another Using speedL
To move between two poses using speedl(), adopting a constant speed approach, you can follow these steps:
Steps:
Calculate the Pose Difference:
Let pose1 = [x1, y1, z1, rx1, ry1, rz1] be the starting pose.
Let pose2 = [x2, y2, z2, rx2, ry2, rz2] be the target pose.
Determine the Desired Runtime for Movement (runtime):
Choose how long you want the motion to take.
Ensure runtime is long enough so the robot does not exceed its maximum velocity or acceleration limits.
Compute the Velocity Vector for speedl():
Velocity is the pose difference divided by the runtime:
velocity = dp / runtime
This gives you a [vx, vy, vz, rx_velocity, ry_velocity, rz_velocity] vector to use in speedl().
Send the speedl() Command:
Use the velocity vector for the robot’s command:
speedl([vx, vy, vz, rx_velocity, ry_velocity, rz_velocity], a, t)
a: Desired acceleration (tune this as needed).
t: Time to command the velocity continuously (recommend matching runtime).
Stop the Robot at the Target Pose:
Monitor the current TCP position and stop with stopl() once the difference between the current pose and pose2 is negligible.
Example Python Code Using RTDE
# Example parameters
pose1 = [0.3, 0.2, 0.5, 0, 0, 0] # Starting pose
pose2 = [0.5, 0.4, 0.6, 0.1, 0.1, 0.1] # Target pose
runtime = 5.0 # Desired time to complete motion (seconds)
# Step 1: Calculate pose difference
dp = [pose2[i] - pose1[i] for i in range(6)]
# Step 2: Calculate velocity
velocity = [dp[i] / runtime for i in range(6)]
# Step 3: Command speedl
robot.speedl(velocity, a=1.0, t=runtime) # Send to robot
Notes for Nonlinear Rotations
Rotations involve nonlinear transformations, so while the linear motion will behave intuitively, the rotation achieved using axis-angle velocities may not align perfectly with the naive difference [rx2 - rx1, ry2 - ry1, rz2 - rz1].
Instead:
Convert the poses to rotation matrices or quaternions to interpolate the motion precisely.
Use tools like SLERP (Spherical Linear Interpolation) if precision rotation paths are necessary.
Would you like help with quaternion-based or other advanced motion blending methods?
I’m not sure the bot answer above is any different from mine–like I said in the original, I also used (pose2 - pose1) / runtime as my speedL input, but the final rotational output doesn’t seem to match the one I’d expect (though the translational output is correct). Could you elaborate a little on exactly what is being passed to speedL from a rotational standpoint? Thank you!