Closed ibergonzani closed 2 years ago
related to #4
Thanks for the PR. Sounds reasonable, and yes that is related to Issue #4. I think I will start by renaming the constraints to tasks and move them into a separate folder like you did with the constraints. Maybe it would be good to have a common method for updating tasks and constraints, so I could also use the RobotModelPtr here. The changes you did are kind of massive, so that requires a lot of testing, and also adaptation of the Rock interface. Merging will be quite painful, ... but it is the correct way to move forward in any case.
derived Constarints classes have been renamed to *Task and moved to the tasks subfolder. the base class is still named Constraint. Internally to this library it is already referred to Task through an alias.
The update of each taskmatrix is now performed inside the corresponding task class through the void update(RobotModelPtr robot_model) method.
MOVED TO #40
Add specific classes for linear constraint:
the base class is called HardConstraint, to avoid confusion with Constraint classes (which are tasks). the plan should be to rename them Constraint and Task respectively.
Currently added linear constraint:
velocity:
contacts (xero vel)
acceleration(tsid):
a scene has now a vector of vector of hard constraints Inside the scene update, they are updated automatically using a RobotModelPtr (update implementation inside constraint class, not scene)
since the joint limits constraints need the control loop time dt. this is passed to the scene through the costructor (default parameter to avoid break existing code). these linear constraint are hardcoded inside the VelocityQuadfraticScene and the AccelerationTSID scene.
In future they might be pass through the configure method?