Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(hard) linear constraint classes #30

Closed
wants to merge 9 commits into from

Conversation

ibergonzani
Copy link
Contributor

@ibergonzani ibergonzani commented Jun 30, 2022

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:

  • joints limits (velocity, position)
  • contacts (xero vel)

acceleration(tsid):

  • joint limits (acceleration, velocity, position, effort)
  • contacts (zero acc)
  • rigidbody dynamics

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?

@ibergonzani
Copy link
Contributor Author

related to #4

@dmronga
Copy link
Contributor

dmronga commented Jun 30, 2022

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.

@ibergonzani
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants