-
Notifications
You must be signed in to change notification settings - Fork 6
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
OCP Croco Class #112
base: topic/humble-devel/refactor
Are you sure you want to change the base?
OCP Croco Class #112
Conversation
for more information, see https://pre-commit.ci
WeightedTrajectoryPoints: List[ | ||
WeightedTrajectoryPoint | ||
] | None = None # List of weighted trajectory points | ||
armature: npt.NDArray[np.float64] | None = None # Armature of the robot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should go with a RobotModel
object that goes into the robot_model class.
We should use the srdf of the robot for this maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
srdf would be a hassle, but we could discuss it in a separate PR. For now, i simply put the armature as a property.
|
||
def test_horizon_size(self): | ||
"""Test the horizon_size property of the OCPCrocoBase class.""" | ||
ocp = OCPCrocoBase(self.rmodel, self.cmodel, self.OCPParams) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you expect a type error to be flag in the test above why this would work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, you should avoid introduction of new public function to the abstract class. It was meant to be somewhat fixed so that no one is confused, and we do not end up with compatibility issues like those between for example, default Crocoddyl objects and MiM Solvers.
Additionally your implementation of OCPCrocoBase
is not generic at all. It is very specific and you should introduce another class like OCPCrocoReaching
where you can impose use of CSQP
and your costs. OCPCrocoBase
should only implement basic interaction with Crocoddyl and expose maybe new private abstract functions that allow user to choose which solver they want to use and how they want to set up shooting problem object.
Additionally please add docstrigns to OCPBase
as you are the first person to extend it, so we will not have to document it later on.
self, | ||
rmodel: pin.Model, | ||
cmodel: pin.GeometryModel, | ||
OCPParams: OCPParamsCrocoBase, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO OCPParamsCrocoBase
should be simply arguments of the __init__
function. In C++ it's required due to registers and stuff, but python doesn't care
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i believe that having a data class is better for readability / organisation purpose, and so that you don't have gazillion of stuff in the init of the class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But most of them can be passed as defaults. And this is a common pattern in python libraries. Just look at how many parameters matplotlib function have
<<<<<<< Updated upstream | ||
from agimus_controller.agimus_controller.ocp_param_base import OCPParamsCrocoBase | ||
from agimus_controller.agimus_controller.trajectory import ( | ||
WeightedTrajectoryPoint, | ||
TrajectoryPoint, | ||
TrajectoryPointWeights, | ||
) | ||
|
||
======= | ||
from agimus_controller.ocp_param_base import OCPParamsCrocoBase | ||
from agimus_controller.trajectory import WeightedTrajectoryPoint, TrajectoryPoint, TrajectoryPointWeights | ||
>>>>>>> Stashed changes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ArthurH91... Why did you commit merge conflict? Can you do pre-commit install
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well you know sometimes it happens
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not accept in this case answer that you are just a chill guy
dt = np.float64(0.01) | ||
T = 100 | ||
solver_iters = 50 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't have to cast those and you can pass them in the OCPParamsCrocoBase
directly
Co-authored-by: Krzysztof Wojciechowski <[email protected]>
Co-authored-by: Krzysztof Wojciechowski <[email protected]>
def x_init(self) -> np.ndarray: | ||
"""Initial guess of the states.""" | ||
x_init = [] | ||
for TrajectoryPoint in self._OCPParams.WeightedTrajectoryPoints: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
snake_case: "TrajectoryPoint" -> "trajectory_point" or "traj_point" or "t_point" etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
little preference for "trajectory_point"
terminalCostModel.addCost( | ||
"stateReg", | ||
xRegCost, | ||
np.concatenate( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that the CostModelSum::addCost
API take a vector of weights as its third input:
https://github.com/loco-3d/crocoddyl/blob/da92f67394c07c987458a8cb24bc0e33edd64227/include/crocoddyl/core/costs/cost-sum.hxx#L29
For weights regularization, you can define a CostModelResidual
with an ActivationModelWeightedQuad
, see here or here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you! I was doing it blindly here tbh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern is the function solve: maybe creating croco objects everytime would be too costly.
### Creation of the state and actuation models | ||
|
||
# Stat and actuation model | ||
self._state = crocoddyl.StateMultibody(self._rmodel) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I wonder if this is reasonable (in terms of time) to create croco objects (running/terminal costs, Action models etc.) from scratch every time we solve? It's simpler than going through through the croco ocp structure to only but might be a bit slow.
I just checked on a personal codebase a similar function and got:
T = 20 -> 0.7 ms
T = 40 -> 1.5 ms
T = 60 -> 2.7 ms
T = 80 -> 3.8 ms
T = 100 -> 4.5 ms
So it seems that the _state/_actuation creation is negligeable (I'd still put it in __init__
or a setup
function) compared to the running cost creation.
i totally agree with this, thank you all for the reviews, i'm gonna start working on it tmrw ! |
…to x_warmstart for clarity's sake
for more information, see https://pre-commit.ci
Co-authored-by: Krzysztof Wojciechowski <[email protected]>
for more information, see https://pre-commit.ci
Co-authored-by: Krzysztof Wojciechowski <[email protected]>
for more information, see https://pre-commit.ci
Co-authored-by: Naveau <[email protected]>
Co-authored-by: Krzysztof Wojciechowski <[email protected]>
Co-authored-by: Krzysztof Wojciechowski <[email protected]>
for more information, see https://pre-commit.ci
…ature/create-ocp-param-class
Hello,
Intro
Here's a draft PR on the OCP base class.
After a discussion with @MaximilienNaveau , we agreed that having only crocoddyl might restrict some users. So we decided to have the OCPBase class staying as it is right now, and having a daughter class OCPCrocoBase, which is a simple task to reach a target with the end effector, as a baseline.
In this draft, I'd like to discuss this with y'all. Do you agree with this reasoning?
What's in the PR
What I'd like to discuss