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
Transmissions, motors and even sensors may have some dynamic state that should be aggregated. Typically, the current-voltage regulation loop of DC motors, or the generic n-to-m transmissions. As such, it should provide an integrate method for position,velocity and our custom liegroup algebra implementation should rely on it instead of calling pinocchio::integrate, which is an easy refactor.
Note that the robot still do not have to manage its own global state, but it should provide computeForwardKinematics in place of the engine as it is current the case, but this should also be an easy refactor. The engine will still ilmplement its own computeAllTerms handling coupling forces and external. Yet, the computation of internal forces should be moved to computeForwardKinematics. Finally, Robot should provide its own neutral method (along with nq, nv corresponding to the full state) and robot.modelConfigSelector(q),`robot.modelVelocitySelector(v) to extract the position,velocity corresponding to the pinocchio model currently in used (flexible or not).
The joint bounds should no longer be registered and handled by the engine but rather delegated to the transmission. Each transmission should take care of enabling/disabling the related constraint if any and necessary. All the constraints extrinsic to a robot (i.e. with the environment or another robot) would still be managed by the robot but enable/disabled by the engine since it is the only one having access to the necessary information.
Concurrently, transmissions should be able to register constraints to the robot.
The text was updated successfully, but these errors were encountered:
Transmissions, motors and even sensors may have some dynamic state that should be aggregated. Typically, the current-voltage regulation loop of DC motors, or the generic n-to-m transmissions. As such, it should provide an
integrate
method for position,velocity and our custom liegroup algebra implementation should rely on it instead of callingpinocchio::integrate
, which is an easy refactor.Note that the robot still do not have to manage its own global state, but it should provide
computeForwardKinematics
in place of the engine as it is current the case, but this should also be an easy refactor. The engine will still ilmplement its owncomputeAllTerms
handling coupling forces and external. Yet, the computation of internal forces should be moved tocomputeForwardKinematics
. Finally,Robot
should provide its ownneutral
method (along withnq
,nv
corresponding to the full state) androbot.modelConfigSelector(q)
,`robot.modelVelocitySelector(v) to extract the position,velocity corresponding to the pinocchio model currently in used (flexible or not).The joint bounds should no longer be registered and handled by the engine but rather delegated to the transmission. Each transmission should take care of enabling/disabling the related constraint if any and necessary. All the constraints extrinsic to a robot (i.e. with the environment or another robot) would still be managed by the robot but enable/disabled by the engine since it is the only one having access to the necessary information.
Concurrently, transmissions should be able to register constraints to the robot.
The text was updated successfully, but these errors were encountered: