force control of 2D model

Typically: "How do I... ", "How can I... " questions
Post Reply
silma
Posts: 5
Joined: 29 Nov 2017, 16:01

force control of 2D model

Post by silma » 04 Dec 2017, 18:40

Hi,

I'm trying to simulate a periodic walking gait for a simple 2D biped model using V-REP through a python remote API.
Unfortunately, I'm facing some difficulties I hope you can help me to tackle.

I have created a simple model of my robot using primitive shapes. It consists of 5 links, connected together through 4 actuated joints. In order to get rid of the 3rd dimension and operate in a 2D framework, I connected the trunk to the floor through two non-actuated prismatic joints:
- the first prismatic joint (direction y) connects the floor to a dynamic "helper" shape, which is non-respondable, has very small mass but very high moments of inertia (so as to avoid unwanted flips)
- the second prismatic joint (direction z) connects this "helper" shape to the trunk
As a result, the trunk can only translate in the plane yz.

I would like to impose the state of the robot at t=0 and then check what happens when I apply a pre-computed time sequence of torques for the actuated joints.
The simulation now manages to start, but the results I get are very strange, so I believe I'm doing something stupid somewhere.

Here's a brief summary of what I'm doing:

1) I set the initial position of each joint through
vrep.simxSetJointPosition(clientID, joint_handle, VALUE, vrep.simx_opmode_oneshot)
- and this works fine

2) Since my initial state is non-static, I set the initial velocity of each shape as follows:

# linear velocity along y
vrep.simxSetObjectFloatParameter(clientID, shape_handle, 3001, VALUE, vrep.simx_opmode_oneshot)
# linear velocity along z
vrep.simxSetObjectFloatParameter(clientID, shape_handle, 3002, VALUE, vrep.simx_opmode_oneshot)
# angular velocity about x
vrep.simxSetObjectFloatParameter(clientID ,shape_handle, 3020, VALUE, vrep.simx_opmode_oneshot)

- Here I have a doubt: the linear velocity of each body is the velocity of its center of mass with respect to an inertial frame of reference, right? Is it supposed to be expressed in components of the spatial or the body-fixed reference frame?

3) Since my pre-computed torques change faster than the default dt, I set dt = 0.017, such that I can keep the actuated joint torques constant over each time interval

4) In order to control my model directly with forces, I set the target velocities of the motors to very high values (positive or negative depending on the sign of the corresponding torque) through
vrep.simxSetJointTargetVelocity(clientID, joint_handle, (+1 or -1)*100000., vrep.simx_opmode_blocking)
and then modulate the joint torque as follows
vrep.simxSetJointForce(clientID, joint_handle, abs(VALUE), vrep.simx_opmode_blocking)

Can anybody tell me what I'm doing wrong?
Any help you could provide would be much appreciated.

Best regards,
Silvia

silma
Posts: 5
Joined: 29 Nov 2017, 16:01

Re: force control of 2D model

Post by silma » 05 Dec 2017, 16:39

Hi,

it's me again :)
I managed to understand what was wrong with the initial velocity: I was simply imposing it before starting the simulation. I postponed the statement after
vrep.simxStartSimulation(clientID, vrep.simx_opmode_blocking)
and now it works fine.
Meanwhile, I also realized that the angular velocity (parameter ID 3020) has to be provided in deg/s, rather than in rad/s (right?)

Now the initial velocity seems to be fine, but still the dynamic simulation does not behave as I am expecting, and that's strange, as the control trajectories I am providing have already been tested in another simulator and there they seemed to work fine (or to make at least some physical sense).

I guess there must be something wrong with my force control, but I could not figure out what exactly, so far. I've already checked the sign of the joint torques and they seem to be consistent with those of the sequence of torques I am providing. So I'm currently out of ideas on what to check further..

Here's the link to my project:
https://drive.google.com/drive/folders/ ... tUJ8wCrQhb

I hope somebody can help me figuring what's wrong with it!
Thanks in advance.

Cheers

coppelia
Site Admin
Posts: 6266
Joined: 14 Dec 2012, 00:25

Re: force control of 2D model

Post by coppelia » 05 Dec 2017, 22:44

Hello,

you have too many questions at once, it is difficult to respond and focus. Try to break the problem into smaller pieces, and takle one problem at a time. For instance, try first to manage having the robot do what you want, without using the remote API client (i.e. by doing everything inside of a child script). The remote API client introduces some additional difficulty, which is to have the simulation run synchronously with the client application.

Also, your robot seems to be jumping at simulation start (didn't test it with the remote API client, just looked at the simulation scene). This is probably because one of the leg/foot of the robot is initially colliding with the floor.

Also, when using very large mass ratios (or inertia ratios), the physics engines might behave strangely. Make sure to carefully read this page, mainly the design considerations 6-8.

Finally, you can also use another mechanism to have your robot walk in a plane: have your robot walk in circle (with a larger radius you have almost a plane): this is will also allow your robot to continuously walk in a loop. You can do this with a spherical joint.

Cheers

silma
Posts: 5
Joined: 29 Nov 2017, 16:01

Re: force control of 2D model

Post by silma » 06 Dec 2017, 12:08

Hello,

thank you for your reply.
From my understanding, the fact that the robot jumps when one starts the simulation is simply due to the high target velocity of the motors: by setting all such velocities to 0, the robots just stands still.
I've checked the measures and the foot should be in contact with the ground. I've also tried to check this with a collision detection module between the legs (i.e. tibia_right and tibia_left bodies, respectively) and the floor, but I get the following message "One or more selected objects have their 'collidable' property disabled", even though in the Rigid Body Dynamic Properties dialog those appear as respondable.

As regards the large mass ratios, I guess the problems in my example might be caused by the "cuboid_helper" shape, i.e. the virtual body between the two initial prismatic joints: I had to set its mass to a very low value, since this value influences the dynamics of the trunk only in the y direction (but not in the z direction). Nonetheless, I see the inconvenience, and I'll try to reformulate my model accordingly. I might consider your advice about having my robot walk in circle with a very big radius instead of in a plane, thanks.

I'll probably be back with more detailed questions, as soon as they arise.

Cheers

silma
Posts: 5
Joined: 29 Nov 2017, 16:01

Re: force control of 2D model

Post by silma » 12 Dec 2017, 17:32

Hi,

following your advice, I've reformulated my model, which solved several issues: my robot finally moves in an almost reasonable way
https://drive.google.com/drive/folders/ ... tUJ8wCrQhb

However, I still have one issue. Namely, my prismatic joints do not seem to work correctly: as the simulation proceeds, the two bodies they connect get more and more misaligned, i.e. the kinematic constraint that should be enforced by a prismatic joint seems to be violated.
Could you please provide some insight into this phenomenon?

Many thanks.

coppelia
Site Admin
Posts: 6266
Joined: 14 Dec 2012, 00:25

Re: force control of 2D model

Post by coppelia » 17 Dec 2017, 17:51

Does that problem also happen with the Vortex engine? If not, then this is a good indication that you are not respecting design considerations 6, 7 or 8 here.

Interesting how you constrain the robot to stay in a plane. That should work, but you might get better results with a cuboid instead of the cylinder, depending on the physics engine used (cylinders sometimes cause problems).

Cheers

silma
Posts: 5
Joined: 29 Nov 2017, 16:01

Re: force control of 2D model

Post by silma » 19 Dec 2017, 12:26

This might be the reason: the problem does not occur with the Vortex engine indeed.
I'll try to figure out which design consideration I am violating, then.

Thank you very much for your help!

Cheers

Post Reply