You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I would like to simulate robots moving via a motorized carriage on a curved rail, e.g. the Hebco 7th axis system shown below.
Describe the solution you'd like
To us, the most natural description of the motion of these mechanisms is as a single-DoF Joint<T> parameterized by the curve (following this paper), with state capturing distance traveled and tangential velocity along the curve. This allows for existing Joint-based infrastructure like Implicit PD feedback; damping; and reflected inertia to be utilized to simulate the behavior.
All other Joint<T> ’s are implemented to have SI-unit states; following this pattern requires a path-distance-parameterized curve. Generalized forces would then be equivalent to a force pair applied at the rail, tangent to the curve. Our prototype implementation of this joint and suggested strategy for drake is:
To implement a Trajectory<T> which models the curve. We find that piecewise circular arcs / line segments within a plane to be one case where path length parameterization can be analytically calculated efficiently (shown below). This parameterization is also quite general, in that many curves can be approximated with several circular/linear segments.
To implement a corresponding Joint<T> and Mobilizer<T> which are thin wrappers of the trajectory.
To support URDF/SDF parsing of the joint via the radii $r_i$ (equivalently, curvature $\kappa_i = \frac{1}{r_i}$) /lengths $l_i$ of the segments.
Piecewise linear/circular rail birds-eye view:
Isometric view:
We intend to submit 3 PR’s mapping to these 3 components for our prototype, unless Drake developers feel strongly that a different implementation is required.
Describe alternatives you've considered
Another alternative would be to mount the robot to a floating base, and use feedback control to mimic the behavior of the real joint. We expect this to require a very stiff controller, and it adds 12 DoF to the state rather than the 2 required for the direct implementation of the joint. As such it is unlikely to be performant.
Additional context
Reiterating that we intend to send in the PR’s ourselves if Drake developers are happy to receive an implementation of this strategy.
The text was updated successfully, but these errors were encountered:
Adding a trajectory type modeling concatenation of linear segments
and circular arcs within a plane, to be used in curvilinear joints
(RobotLocomotion#22196).
Is your feature request related to a problem? Please describe.
I would like to simulate robots moving via a motorized carriage on a curved rail, e.g. the Hebco 7th axis system shown below.
Describe the solution you'd like
To us, the most natural description of the motion of these mechanisms is as a single-DoF
Joint<T>
parameterized by the curve (following this paper), with state capturing distance traveled and tangential velocity along the curve. This allows for existing Joint-based infrastructure like Implicit PD feedback; damping; and reflected inertia to be utilized to simulate the behavior.All other
Joint<T>
’s are implemented to have SI-unit states; following this pattern requires a path-distance-parameterized curve. Generalized forces would then be equivalent to a force pair applied at the rail, tangent to the curve. Our prototype implementation of this joint and suggested strategy for drake is:Trajectory<T>
which models the curve. We find that piecewise circular arcs / line segments within a plane to be one case where path length parameterization can be analytically calculated efficiently (shown below). This parameterization is also quite general, in that many curves can be approximated with several circular/linear segments.Joint<T>
andMobilizer<T>
which are thin wrappers of the trajectory.Piecewise linear/circular rail birds-eye view:
Isometric view:
We intend to submit 3 PR’s mapping to these 3 components for our prototype, unless Drake developers feel strongly that a different implementation is required.
Describe alternatives you've considered
Another alternative would be to mount the robot to a floating base, and use feedback control to mimic the behavior of the real joint. We expect this to require a very stiff controller, and it adds 12 DoF to the state rather than the 2 required for the direct implementation of the joint. As such it is unlikely to be performant.
Additional context
Reiterating that we intend to send in the PR’s ourselves if Drake developers are happy to receive an implementation of this strategy.
The text was updated successfully, but these errors were encountered: