Comments (17)
andreadelprete
commented on July 20, 2024
1
A student I am working with, @gfadini, has done something similar. I'll put him in contact with so he can explain you how he did it.
from control_and_simulation.
andreadelprete
commented on July 20, 2024
1
Increasing the state weight won't help. On the contrary, it will make the robot stay still.
It's weird you have some nan in the viewer. This makes me think Crocoddyl is diverging. Maybe you can check that by looking at the stuff that Crocoddyl prints when trying to solve a problem.
from control_and_simulation.
gfadini
commented on July 20, 2024
Hi @VasilyRakche, with COM I assume you are talking about the base vertical coordinate, right?
In that case it seems to me that you're loading the urdf without overriding the first joint type, as from the animation you're still having x y translations and rotations.
By default pinocchio creates the model with the freeFlyer joint. You can easily check that this is the case by inspecting your state vector size.
The right joint type to use for this application is a prismatic one pinocchio.JointModelPZ().
To change it you can, for example, load the robot via the RobotWrapper class as follows:
robot = pinocchio.RobotWrapper.BuildFromURDF('your.urdf', package_dirs = path_to_urdf, root_joint=pinocchio.JointModelPZ(), verbose=False, meshLoader=True)
This on the OCP side has various benefits: this way you will automatically satisfy the constraints on the motion and decrease the state and control size, which is desirable.
Once you have loaded the model like this, the first joint won't be actuated in crocoddyl ONLY IF as actuation you use crocoddyl.ActuationModelFloatingBase(state) (where state = crocoddyl.StateMultibody(robot.model)).
Then be careful on the penalties you create in crocoddyl to handle the contact
I hope this helps.
from control_and_simulation.
VasilyRakche
commented on July 20, 2024
Thanks a lot @gfadini for clarifications! Yes, you got it right regarding the COM. I used your suggestion regarding the pinocchio.JointModelPZ() usage in BuildFromUrdf, it was just not clear to me how to define it in the urdf and srdf, so I ended up defining a robot with free flyer root_joint in SRDF and constraining it with pinnochio to be primsatic along z direction. I tried some other approaches aswell, but this is most logical to me.
Crocoddyle is able to recognize model properly I think (at least it shows joint configuration right) also when running some random configurations it also behaves as expected.
I decided to keep the ActuationModelFloatingBase - I think it should work. If I understood definition right, it just doesnt try to control the root_joint as can be seen in this line of the code. But when I run the solver the robot is not moving for some reason ( I was trying to set up some big weights, also increasing number of knots, to make it at least move a bit, but looks like something else is a problem- like the gravity for some reason is not acting properly on it - initial configuration places it a bit above the ground). You can see the output in the following video:
Robot_FORE_jump-2021-08-11_18.44.19.mp4
Would really appreciate if you have some suggestions how to debug it
Thanks a lot for the previous input.
from control_and_simulation.
VasilyRakche
commented on July 20, 2024
Thanks @andreadelprete, but whats strange, I tried now with smaller values, but nothing. Also using verbose doesnt print anything in the terminal in this case (when I used verbose previously I had the variables printed out)
from control_and_simulation.
VasilyRakche
commented on July 20, 2024
Hey, small update, I have built the crocoddyl from source with Debug flag and I am also running normal python script, not notebook. I am getting zero values and RuntimeWarning, maybe it will help:
iter cost stop grad xreg ureg step feas dV-exp dV
0 0.00000e+00 0.00000e+00 -0.00000e+00 1.00000e+01 1.00000e+01 0.0020 1 0.00000e+00 0.00000e+00
1 0.00000e+00 0.00000e+00 -0.00000e+00 1.00000e+02 1.00000e+02 0.0020 1 0.00000e+00 0.00000e+00
2 0.00000e+00 0.00000e+00 -0.00000e+00 1.00000e+03 1.00000e+03 0.0020 1 0.00000e+00 0.00000e+00
3 0.00000e+00 0.00000e+00 -0.00000e+00 1.00000e+04 1.00000e+04 0.0020 1 0.00000e+00 0.00000e+00
/opt/openrobots/lib/python3/dist-packages/crocoddyl/__init__.py:13: RuntimeWarning: invalid value encountered in true_divide
b_copy = b / np.linalg.norm(b)
4 0.00000e+00 0.00000e+00 -0.00000e+00 1.00000e+05 1.00000e+05 0.0020 1 0.00000e+00 0.00000e+00
5 0.00000e+00 0.00000e+00 -0.00000e+00 1.00000e+06 1.00000e+06 0.0020 1 0.00000e+00 0.00000e+00
6 0.00000e+00 0.00000e+00 -0.00000e+00 1.00000e+07 1.00000e+07 0.0020 1 0.00000e+00 0.00000e+00
7 0.00000e+00 0.00000e+00 -0.00000e+00 1.00000e+08 1.00000e+08 0.0020 1 0.00000e+00 0.00000e+00
I am using stateWeights:
stateWeights = np.array([0.1] * 1 + [0.1] * (rmodel.nv - 1) + [0.1] * 1 + [0.1] *
(rmodel.nv - 1))
from control_and_simulation.
andreadelprete
commented on July 20, 2024
The fact that everything is at zero at the first iteration is very strange. If I were you I would try to go back to the original script and incrementally modify it to get the current script, checking at which step that the Crocoddyl output starts being this. This should allow you to figure out what is causing the problem.
from control_and_simulation.
gfadini
commented on July 20, 2024
@VasilyRakche do you have any update on this issue?
I've seen that there are two closed issues on crocoddyl related to your problem this and this.
I agree that you need to change the contact dynamics to handle a 2D contact, otherwise you will encounter singularities (maybe those can explain your RuntimeWarning?).
Including the 2D contact can easily be done without any modification on crocoddyl side, on the other hand friction cones constraints require some additional changes.
I suggest you to start from modifying your problem to work with the right contact jacobian and solve it, and only then add the friction cones to it.
from control_and_simulation.
VasilyRakche
commented on July 20, 2024
Hey @gfadini , the issue is not resolved yet. I am checking some suggested literature and trying to understand implemented math. I tried using 2D contacts, but as far as I could tell it only provides the contact Jacobian and contact acceleration, but I need a friction cones in order to add them to costmodel so they will be taken into account. I modified like this:
# Modifications from:
# def createSwingFootModel(self, timeStep, supportFootIds, comTask=None, swingFootTask=None):
# Creating a 2D multi-contact model instead of the 3D
nu = self.actuation.nu
contactModel = crocoddyl.ContactModelMultiple(self.state, nu)
for i in supportFootIds:
# supportContactModel = crocoddyl.ContactModel3D(self.state, i, np.array([0., 0., 0.]), nu,
# np.array([0., 50.]))
supportContactModel = crocoddyl.ContactModel2D(self.state, i, np.array([0., 0.]), nu,
np.array([0., 50.]))
# Removing friction cone from the cost model since it doesnt support the 2D Contact Model
# for i in supportFootIds:
# cone = crocoddyl.FrictionCone(self.Rsurf, self.mu, 2, False)
# coneResidual = crocoddyl.ResidualModelContactFrictionCone(self.state, i, cone, nu)
# coneActivation = crocoddyl.ActivationModelQuadraticBarrier(crocoddyl.ActivationBounds(cone.lb, cone.ub))
# frictionCone = crocoddyl.CostModelResidual(self.state, coneActivation, coneResidual)
# costModel.addCost(self.rmodel.frames[i].name + "_frictionCone", frictionCone, 1e6)So this is what I get:
Robot_FORE_jump5-2021-08-24_21.57.51.mp4
How would you suggest taking into account the contact Jacobian and acceleration?
from control_and_simulation.
gfadini
commented on July 20, 2024
Just to be sure: you have 4 dof for the model ad you use a 2D contact. Are all the joints rotating around the Y axis?
Note that if you have an additional joint (such that it actuates the abduction movement) then in that case you don't actually need the 2D contacts because locally at the contact point you can perform motions in all directions.
Since you case is simple, I don't think you require the SimpleQuadrupedalGaitProblem from crocoddyl for which you probably need to pass also the friction cone.
You can have a more minimal contact model, which doesn't account for friction, as follows in this short example which follows the names usually found across the examples:
# CONTACT MODEL
contactModel = crocoddyl.ContactModelMultiple(state, actuation.nu)
contact_location = crocoddyl.FrameTranslation(footFrameID, initial_foot_placement.translation)
supportContactModel = crocoddyl.ContactModel2D(state, contact_location, actuation.nu, np.array([0., 50]))
contactModel.addContact("foot_contact", supportContactModel)
# COSTS
contactCostModel = crocoddyl.CostModelSum(state, actuation.nu)
contactCostModel.addCost('cost', cost, weight)
# DIFFERENTIAL ACTION MODEL
contactDifferentialModel = crocoddyl.DifferentialActionModelContactFwdDynamics(state,
actuation,
contactModel,
contactCostModel,
0, # inv_damping
True) # bool enable force
# INTEGRATED ACTION MODEL
contactPhase = crocoddyl.IntegratedActionModelEuler(contactDifferentialModel, dt)EDIT: misspelled SimpleQuadrupedalGaitProblem
from control_and_simulation.
VasilyRakche
commented on July 20, 2024
Hey @gfadini, yes the whole model is 4DOF (3 rotational; and one prismatic - it takes into account the connection to the test-stand and constraint that the leg can only go up and down) . Yes, the 3 joints are rotating around the y axis, but the prismatic is along z axis.
Thanks for the idea, but I couldnt make it work. I have modified the code a bit to depict what I understood can be a solution, but I am getting similar result to the previous case. I have created new branch with the modifications, which you can check here.
from control_and_simulation.
gfadini
commented on July 20, 2024
Hi @VasilyRakche
what I meant was to replace the use of the SimpleQuadrupedalGaitProblem because I fear is over-complicating things for your case and is far more difficult to debug.
Take inspiration from how the problem is created there by generating and stacking the various phases of the problem and write your ocp problem.
In your specific case you can start with a contact phase and a flying phase since you want to perform a jump.
For the contact you need to use the contact dynamics DifferentialActionModelContactFwdDynamics as you can see written in the createSwingFootModel(), while for the flying phase you can simply use the DifferentialActionModelFreeFwdDynamics instead.
In your code by using createSwingFootModel() with various arguments in all the phases you're actually always using DifferentialActionModelContactFwdDynamics, I suspect that this may be the reason why the solver fails
from control_and_simulation.
VasilyRakche
commented on July 20, 2024
Hi @gfadini I have made some changes in the crocoddyl source code in contact-friction-cone in order to work with 2d contacts (I have my own build, this is not a good solution for general case (2d in xy plane, or yz plane) so thats why I didnt send a feature request to them, but I will try to communicate it somehow in the following days). Now I am able to run the model and perform a jump - not ideal one, but might be good for initial testing with robot. It can be improved if I will be able to debug the costs a bit better. I have idea of lowering the costs and then increasing them slowly and so on but maybe there is some better approach - I mean I tried something like that and it didnt give much intuitive results. Maybe there is some problem of holding to a COM and thats why the cost is so large (you can see that it moves along x direction, even though it is desired to go only along z):
| COM | Optimization parameters |
|---|---|
 |
 |
Also, for some reason the stopping criteria (theta) value is increasing even though the cost is decreasing, so thats quite unintuitive, I thought you might provide some insights.
This is how robot performs now:
Robot_FORE_jump6-2021-09-15_18.11.24.mp4
from control_and_simulation.
gfadini
commented on July 20, 2024
Hi @VasilyRakche,
I saw the motion you got, the kinematics of the leg looks fine, to me it seems more that you have a problem in the formulation of the task.
I'd like to know more on what are the cost you're putting in the problem. Note also that a CostModelCOMPosition has not to be confused with a task on the z-height of the base (that you can rather implement with a CostModelState now in the latest API aka ResidualModelState): if the legs are not massless and the links move in the x-direction, then the COM necessarily will change.
It is more surprising to me that the solver is not converging and reaching a solver stopping condition.
You can try to provide a warmstart vector for the control and states in the ddp.solve() method and this would be pretty useful for debugging.
from control_and_simulation.
akhilsathuluri
commented on July 20, 2024
@gfadini: I am trying to reproduce a similar testbench jump from your paper, "Computational design of energy-efficient legged robots: Optimizing for size and actuators". I set up the problem like you suggested above with contact and flight phases. Sample shown below,
def createActionModelinContact(target):
# create a state model
state = crocoddyl.StateMultibody(model)
# Create the actuation model
actuation = crocoddyl.ActuationModelFloatingBase(state)
# declare contact model
contacts = crocoddyl.ContactModelMultiple(state, actuation.nu)
# TODO: Add from @gfadini;s suggestion: https://github.com/Legged-robot/control_and_simulation/issues/1
foot_contact = crocoddyl.ContactModel2D(state, foot_id, np.array([0.0,0.0]), actuation.nu)
contacts.addContact("foot_contact", foot_contact)
costs = crocoddyl.CostModelSum(state, actuation.nu)
ii = model.getFrameId("base_link")
groundPenetrationResidual = crocoddyl.ResidualModelFrameTranslation(state, ii, np.array([0]*3), actuation.nu)
groundPenetrationActivation = crocoddyl.ActivationModelQuadraticBarrier(crocoddyl.ActivationBounds(pen_lb, pen_ub, beta))
groundPenetration = crocoddyl.CostModelResidual(state, groundPenetrationActivation, groundPenetrationResidual)
costs.addCost("groundPenetration"+str(ii), groundPenetration, ground_pen_cp_weight)
# penalisation for control bounds
controlBoundsResidual = crocoddyl.ResidualModelControl(state, actuation.nu)
controlBoundsActivation = crocoddyl.ActivationModelQuadraticBarrier(crocoddyl.ActivationBounds(u_lb, u_ub))
controlBounds = crocoddyl.CostModelResidual(state, controlBoundsActivation, controlBoundsResidual)
costs.addCost("uBounds", controlBounds, u_bound_weight)
# Adding state and control regularization terms
x_reg_cost = crocoddyl.CostModelResidual(state,
crocoddyl.ResidualModelState(state, x0, actuation.nu))
costs.addCost("xReg", x_reg_cost, x_reg_weight)
u_reg_cost = crocoddyl.CostModelResidual(state,
crocoddyl.ResidualModelControl(state, actuation.nu))
costs.addCost("uReg", u_reg_cost, u_reg_weight)
# generate the diff model
dmodel = crocoddyl.DifferentialActionModelContactFwdDynamics(state, actuation, contacts, costs, 0, True)
return dmodel
However, I observe that the solver either does not converge or identifies unnatural (unrealistic) motions like the one shown below,
iter cost stop grad xreg ureg step ||ffeas|| ||gfeas|| ||hfeas||
0 4.98760e+03 5.07005e-02 -1.74532e+09 1.00000e-08 1.00000e-08 0.0020 3.40000e-01 0.00000e+00 0.00000e+00
1 4.98760e+03 5.53233e+03 -1.42336e+12 1.00000e-07 1.00000e-07 0.0020 3.40000e-01 0.00000e+00 0.00000e+00
2 4.98760e+03 1.22563e+04 1.36694e+10 1.00000e-06 1.00000e-06 0.0020 3.40000e-01 0.00000e+00 0.00000e+00
3 4.98760e+03 2.55459e+04 4.27319e+13 1.00000e-05 1.00000e-05 0.0020 3.40000e-01 0.00000e+00 0.00000e+00
4 4.98760e+03 3.33147e+04 3.39157e+13 1.00000e-04 1.00000e-04 0.0020 3.40000e-01 0.00000e+00 0.00000e+00
5 5.60767e+03 3.76326e+04 -5.93967e+04 1.00000e-05 1.00000e-05 1.0000 3.40000e-01 0.00000e+00 0.00000e+00
6 3.15467e+03 5.58974e+03 1.11795e+04 1.00000e-05 1.00000e-05 0.2500 0.00000e+00 0.00000e+00 0.00000e+00
7 1.74306e+03 3.14436e+03 6.28872e+03 1.00000e-05 1.00000e-05 0.2500 0.00000e+00 0.00000e+00 0.00000e+00
8 1.38976e+03 1.73703e+03 3.47406e+03 1.00000e-05 1.00000e-05 0.1250 0.00000e+00 0.00000e+00 0.00000e+00
9 1.25769e+03 1.38395e+03 2.76790e+03 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
iter cost stop grad xreg ureg step ||ffeas|| ||gfeas|| ||hfeas||
10 1.10140e+03 1.25255e+03 2.50510e+03 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
11 8.43248e+02 1.09688e+03 2.19376e+03 1.00000e-05 1.00000e-05 0.1250 0.00000e+00 0.00000e+00 0.00000e+00
12 7.49458e+02 7.86408e+02 1.57282e+03 1.00000e-05 1.00000e-05 0.1250 0.00000e+00 0.00000e+00 0.00000e+00
13 5.82905e+02 6.87470e+02 1.37494e+03 1.00000e-05 1.00000e-05 0.1250 0.00000e+00 0.00000e+00 0.00000e+00
14 5.50916e+02 5.17320e+02 1.03464e+03 1.00000e-05 1.00000e-05 0.0312 0.00000e+00 0.00000e+00 0.00000e+00
15 5.18985e+02 4.87250e+02 9.74499e+02 1.00000e-05 1.00000e-05 0.0312 0.00000e+00 0.00000e+00 0.00000e+00
16 4.81664e+02 4.63675e+02 9.27350e+02 1.00000e-05 1.00000e-05 0.0312 0.00000e+00 0.00000e+00 0.00000e+00
17 4.64376e+02 4.60525e+02 9.21050e+02 1.00000e-05 1.00000e-05 0.0312 0.00000e+00 0.00000e+00 0.00000e+00
18 4.51933e+02 4.44619e+02 8.89239e+02 1.00000e-05 1.00000e-05 0.0156 0.00000e+00 0.00000e+00 0.00000e+00
19 4.33349e+02 4.34904e+02 8.69808e+02 1.00000e-05 1.00000e-05 0.0156 0.00000e+00 0.00000e+00 0.00000e+00
iter cost stop grad xreg ureg step ||ffeas|| ||gfeas|| ||hfeas||
20 3.79849e+02 4.22134e+02 8.44267e+02 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
21 3.69371e+02 3.71244e+02 7.42488e+02 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
22 3.26845e+02 3.66279e+02 7.32558e+02 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
23 2.87468e+02 3.23895e+02 6.47844e+02 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
24 2.52392e+02 2.84772e+02 5.69545e+02 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
25 2.21953e+02 2.49883e+02 4.99766e+02 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
26 1.95406e+02 2.19537e+02 4.39073e+02 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
27 1.71988e+02 1.93071e+02 3.86141e+02 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
28 1.51354e+02 1.69757e+02 3.39514e+02 1.00000e-05 1.00000e-05 0.0625 0.00000e+00 0.00000e+00 0.00000e+00
29 1.17343e+02 1.49243e+02 2.98486e+02 1.00000e-05 1.00000e-05 0.1250 0.00000e+00 0.00000e+00 0.00000e+00
iter cost stop grad xreg ureg step ||ffeas|| ||gfeas|| ||hfeas||
30 6.69394e+01 1.15450e+02 2.30901e+02 1.00000e-05 1.00000e-05 0.2500 0.00000e+00 0.00000e+00 0.00000e+00
31 3.79836e+01 6.58330e+01 1.31666e+02 1.00000e-05 1.00000e-05 0.2500 0.00000e+00 0.00000e+00 0.00000e+00
32 1.19238e+01 3.73144e+01 7.46288e+01 1.00000e-05 1.00000e-05 0.5000 0.00000e+00 0.00000e+00 0.00000e+00
33 1.04522e+00 1.17258e+01 2.34515e+01 1.00000e-06 1.00000e-06 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
34 4.78827e-01 1.04332e+00 2.08664e+00 1.00000e-07 1.00000e-07 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
35 8.87132e-02 4.78759e-01 9.57518e-01 1.00000e-08 1.00000e-08 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
36 2.84949e-02 8.87113e-02 1.77423e-01 1.00000e-08 1.00000e-08 0.5000 0.00000e+00 0.00000e+00 0.00000e+00
37 3.78984e-04 2.84934e-02 5.69867e-02 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
38 1.59195e-11 3.78984e-04 7.57969e-04 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
Problem solved: True
Number of iterations: 39
Total cost: 2.8813898409031794e-13
Gradient norm: 1.590526911742784e-11
39 2.88139e-13 1.59053e-11 3.18105e-11 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
The following is the bahaviour of the solution:
Screencast.from.15.05.2023.23.21.58.webm
EDIT: Also how to account for the transition between the contact and the non-contact phases? I am currently creating two lists of each of the model and append them into one big list.
from control_and_simulation.
gfadini
commented on July 20, 2024
Hi @akhilsathuluri, it is difficult to spot the issue from what you posted.
I would say that the ActionModel seems to be correct. My hunch is that the issue comes more from the cost function weights, phase timings and model (torque) limits. If you play with those parameters you should be able to obtain a feasible motion.
from control_and_simulation.
akhilsathuluri
commented on July 20, 2024
Hello @gfadini thanks for the super quick reply.
I did manage to tune the weights to get a decent looking response,
Optimisation output:
iter cost stop grad xreg ureg step ||ffeas|| ||gfeas|| ||hfeas||
0 4.66238e+04 1.15076e+04 1.60118e+04 1.00000e-09 1.00000e-09 1.0000 3.40000e-01 0.00000e+00 0.00000e+00
1 2.01584e+04 4.59878e+04 9.19755e+04 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
2 1.02603e+04 1.98074e+04 3.96147e+04 1.00000e-09 1.00000e-09 0.5000 0.00000e+00 0.00000e+00 0.00000e+00
3 2.28329e+03 9.90830e+03 1.98166e+04 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
4 7.33142e+02 1.92566e+03 3.85132e+03 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
5 6.83404e+02 3.77205e+02 7.54411e+02 1.00000e-09 1.00000e-09 0.1250 0.00000e+00 0.00000e+00 0.00000e+00
6 5.65500e+02 3.26476e+02 6.52953e+02 1.00000e-09 1.00000e-09 0.5000 0.00000e+00 0.00000e+00 0.00000e+00
7 3.57010e+02 2.08488e+02 4.16976e+02 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
8 3.57009e+02 3.27426e-04 6.54853e-04 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
Problem solved: True
Number of iterations: 10
Total cost: 357.0092414778333
Gradient norm: 1.6748714494268339e-12
9 3.57009e+02 1.05494e-08 2.10987e-08 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
iter cost stop grad xreg ureg step ||ffeas|| ||gfeas|| ||hfeas||
10 3.57009e+02 1.67487e-12 3.34974e-12 1.00000e-09 1.00000e-09 1.0000 0.00000e+00 0.00000e+00 0.00000e+00
State and velocity:
Behavior:
Screencast.from.16.05.2023.15.03.20.webm
Problem:
I still dont think this is correct, one can observe that right after the contact phase the leg loses contact and the behavior is not physical. It does not seem to "thrust" itself up for some reason. My guess is that there is no "connection" between the contact and flight phases. I currently enforce dynamics as,
seqs = [[crocoddyl.IntegratedActionModelEuler(dmodelContact, DT)]*Nc+[crocoddyl.IntegratedActionModelEuler(dmodelFlight, DT)]*Nnc+[crocoddyl.IntegratedActionModelEuler(tdmodelFlight, 0.)]]
Im not sure what Im missing at the moment.
from control_and_simulation.
Related Issues (1)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from control_and_simulation.