I'm trying to understand how belt pulley from Mathworks work. I have this simple sample:
In this case. I'm giving the velocity of a. And there is when appear my first question:
why the magnitude of velocity of b, is the same of a?
According to the theory of belt drive, the ratio between both velocities is this:
Va/Vb = 1 - (Ta - Tb)/EA
But the "Belt Pulley" description of Mathworks (http://es.mathworks.com/help/physmod/sdl/ref/beltpulley.html#zmw57dd0e1842), said that both will have the same magnitude but different direction.
Anyway, I could assume that they are not consider the elastic of the band, but I don't have any clue of how they get the angular velocity of the pulley to get then the relative velocity. At some point they need to know the elastic of the material for get the relative movement between the belt and the pulley.
Can anyone help me?
I think the answer to the first part of your question lies in the block assumptions:
Assumptions and Limitations
The model does not account for compliance along the length of the belt.
Both belt ends maintain adequate tension throughout the simulation.
To get the angular velocity of the pulley, use an Ideal Rotational Motion Sensor block. Connect the R port to the rotational free end of the pulley and the C port to a a Mechanical Rotational Reference block.
The motion between the belt and pulley is described by those equations (from the documentation page you mentioned in the question, where all the parameters are detailed):
Related
I am working on a simulation, which contains:
a bolt, welded uprightly to the world
a nut, connected to the bolt via ScrewJoint. The mass of a nut set to 0.02 kg, the inertia is a diagonal 1.1e-9 *I. This is configured via a .sdf file.
an iiwa manipulator, which is beside a point for now.
The problem is that the nut is very hard to manipulate and I cannot find a parameter to adjust, which could've made it more lifelike. To be more specific:
I measure the ability of force, applied tangentially in a horizontal plane to the nut, to cause the screwing motion of a joint, that joins the nut with a bolt
I'd like to have greater amount of motion at lower forces, and so far I am failing to achieve that
My interest in doing this is not idle; I am interested in more complicated simulations, which are also failing when iiwa is coming in a contact with this same joint; I've asked about those here and here. (Both answered partially). To sum up those here: when manipulator grips the nut, the nut fights the screwing in such a manner, that the schunk gripper is forced to unclasp and iiwa is thrown off-track, but the nut remains stationary.
I attach below two simpler experiments to better illustrate the issue:
1. Applying tangentially in a horizontal plane 200N force using ExternallyAppliedSpatialForce.
Graph notation: (here as well as below)
The left graph contains linear quantities (m, m/s, etc) along world's Z axis, the right graph contains angular quantities (in degrees, deg, deg/s, etc) around world's Z axis. The legend entries with a trailing apostrophe use the secondary Y-axis scale; other legend entries use the primary Y-axis scale.
Experiment summary:
This works as expected, 200 N is enough to make the nut spin on a bolt, resulting in the nut traveling vertically along the bolt for just under 1 centimeter, and spinning for over 90 degrees. Note: the externally applied force does not show up on my graph.
2. Applying tangentially in a horizontal plane force using iiwa and a simple position controller.
Experiment summary:
The force here is approximately the same as before: 70N along tz, but higher (170N) in tx and ty, though it is applied now only for a brief moment. The nut travels just a few degrees or hundredth fractions of centimeter.
The video of this unsuccessful interaction is below, the contact forces are visualized using ContactVisualizer.
Please advise me on how to make this screw_joint more compliant?
I've tried varying mass and inertia of the nut (different up to the orders of magnitude) in these experiments, this
seems to scale the contact forces, but does not affect acceleration or velocity of the nut after contact.
I like your experiment using ExternallyAppliedSpatialForce to get an idea of scales, though TBH I didn't quite get the details of this setup.
Things that caught my eye though are about scales, which you can estimate with pen and paper:
Your inertia is 1e-9 kg⋅m²?! Judging from your interaction with the iiwa I estimated a radius of 1cm and with that you'd get 2e-6 kg⋅m², three orders of magnitude larger.
A force of 200 N on a 20 grams nut would cause an acceleration of 10000 m/s². As a reference, that's 1000 times the acceleration of Earth's gravity!
Are these numbers correct? Also, if you happen to have fast interactions (do you?), you might want to estimate a time step that makes sense for your application.
Hopefully this helps!
A good thing is that I've fixed it; a bad thing: I don't understand the fix.
Let's restate a problem that I was tacking: a manipulated object reacted quite predictably to the ExternallyAppliedSpatialForce, but couldn't be moved via the contact with the manipulator.
What was done:
I've update drake from 2f340192a9dc79110410faf8a6d54a8615ddca92 (circa 22 Aug, 2022) to 42448c0af1b39f0c46f760e7ae37d77097689ad3 (circa 3 Nov, 2022)
After the update, my experimental setup broke down with assertion Actuation input port for model instance ... must be connected. [Similar to the issue raised in this question.]. My fix was like that:
bolt_n_nut_ = internal::AddAndWeldModelFrom(sdf_path, "nut_and_bolt",
plant_->world_frame(),
"bolt", X_WC, plant_);
then later in ManipulationStation::Finalize:
auto zero_torque = builder.template AddSystem<systems::ConstantVectorSource<double>>(
Eigen::VectorXd::Zero(1));
builder.Connect(zero_torque->get_output_port(),
plant_->get_actuation_input_port(bolt_n_nut_));
With changes above, a manipuland began to interact with the manipulator:
Things to note in graphs:
the distance the manipuland has moved grew from fractions of millimeter up to tens of centimeters. The video presents that a nut became manipulable.
This interaction violates the constraints of the ScrewJoint, i.e. the manipuland moves along it's axis without as much rotation
So I am looking for some general advice. For my final project in my Computational Physics class. I have to complete the following problem.
(4.16 from Computation Physics 2nd Edition By Giordano and Nakanishi)
-Carry out a true three-body simulation in which the motions of Earth, Jupiter, and the Sun are all calculated. Since all three bodies are now in motion, it is useful to take the center of mass of the three-body system as the origin, rather than the position of Sun. We also suggest that you give Sun and initial velocity which makes the total momentum of the system exactly zero(so that the center of mass will remain fixed). Study the motion of Earth with different initial conditions. Also, try increasing the mass of Jupiter to 10, 100, and 1000 times its true mass.
My question: Is it possible to write the code for the problem above, and then import that code(or the result) into Adobe After Effects to model the three-body simulation? My teacher has expressed that if i am able to do so, he would be inclined to give me extra credit, which i desperately need.
It is possible to do some scripting in After Effects, but the language is Javascript (or rather, ExtendScript), not Matlab. I would do everything in a javascript: first calculate your solution (3 streams of position data), and use these to keyframe the corresponding layers in After Effects. You will have to learn a bit of the After Effects object model, but in that case you wont need much: the Layer object and how to keyframe its position property. You should go to the Adobe After Effects scripting forum https://forums.adobe.com/community/aftereffects_general_discussion/ae_scripting/ for some script examples.
The apple documentation for UIAcceleration class says,
"When a device is laying still with its back on a horizontal surface, each acceleration event has approximately the following values:
x: 0
y: 0
z: -1"
Now, I am confused! How can the acceleration be non-zero, when you clearly say the "device is laying still"?
UPDATE
Judging by the responses, I think this should be called something like 'forceometer' or 'gravitometer' and not accelerometer!
You get a -1 on the Z axis because gravity is acting on the device, applying a constant acceleration of 1G. I assume you want user acceleration, which you can get from the DeviceMotion object using a device motion handler as opposed to an acceleration handler. The userAcceleration property filters out the effects of gravity on the device and only gives you how much the user is accelerating it.
I found the answer [in the CoreMotion Reference guide, thanks to bensnider:
The accelerometer measures the sum of two acceleration vectors: gravity and user acceleration. User acceleration is the acceleration that the user imparts to the device.
You'll find the best answers in datasheet of the accelerometer used (LIS302DL).
It measures the gravity. The unit is chosen so that the gravity, 9.81 m/s^2, equals 1 unit. The sign tells how the phone axis is directed. In other words, what the phone considers downwards.
The phone measures 0 as acceleration in free fall. I don't know how much you want to throw your phone up and down to test it :)
When you're sitting, gravity is pulling you down to your chair. If it weren't for the chair or ground for that matter, you'd be falling down with acceleration of about 9.8m/s^2. In order for the chair to prevent you from falling down, it has to act with a force in the opposite direction with at least the same value.
The accelometer shows the value of the pulling force and it's a three-dimensional vector. In this case it's directed straight down. And the value given is expressed in G, units of gravity acceleration multiplied by that value.
Answerers keep missing the right wording that should set it straight for you... The device is "laying still" only relatively to you. It is actually not laying still at all. The http://en.wikipedia.org/wiki/Centripetal_force of gravity gives it (and you) centripetal acceleration. It is real, it is what keeps you from flying off Earth on a tangent, and it is what the accelerometer dutifully shows. (Earth is nothing special - we rotate about the Sun also etc etc, whose centripetal accelerations are way smaller, but they would be all shown by an accelerometer sensitive enough.)
I don't yet have sufficient reputation to reply directly to the comment by #gigahari above, but as an addendum, folks should be aware that some apps (such as the physics apps phyphox and PhysicsToolbox Sensor Suite) do not report (a+g) -- both phyphox's "with g" option and PhysicsToolbox report the vector sum (a-g), which is sometimes referred to as the "Operational Definition of Weight." A brief discussion of this version of the operational definition of weight is on WikiPedia, at https://en.wikipedia.org/wiki/Weight#Operational_definition
I want to ask about jelly physics ( http://www.youtube.com/watch?v=I74rJFB_W1k ), where I can find some good place to start making things like that ? I want to make simulation of cars crash and I want use this jelly physics, but I can't find a lot about them. I don't want use existing physics engine, I want write my own :)
Something like what you see in the video you linked to could be accomplished with a mass-spring system. However, as you vary the number of masses and springs, keeping your spring constants the same, you will get wildly varying results. In short, mass-spring systems are not good approximations of a continuum of matter.
Typically, these sorts of animations are created using what is called the Finite Element Method (FEM). The FEM does converge to a continuum, which is nice. And although it does require a bit more know-how than a mass-spring system, it really isn't too bad. The basic idea, derived from the study of continuum mechanics, can be put this way:
Break the volume of your object up into many small pieces (elements), usually tetrahedra. Let's call the entire collection of these elements the mesh. You'll actually want to make two copies of this mesh. Label one the "rest" mesh, and the other the "world" mesh. I'll tell you why next.
For each tetrahedron in your world mesh, measure how deformed it is relative to its corresponding rest tetrahedron. The measure of how deformed it is is called "strain". This is typically accomplished by first measuring what is known as the deformation gradient (often denoted F). There are several good papers that describe how to do this. Once you have F, one very typical way to define the strain (e) is:
e = 1/2(F^T * F) - I. This is known as Green's strain. It is invariant to rotations, which makes it very convenient.
Using the properties of the material you are trying to simulate (gelatin, rubber, steel, etc.), and using the strain you measured in the step above, derive the "stress" of each tetrahdron.
For each tetrahedron, visit each node (vertex, corner, point (these all mean the same thing)) and average the area-weighted normal vectors (in the rest shape) of the three triangular faces that share that node. Multiply the tetrahedron's stress by that averaged vector, and there's the elastic force acting on that node due to the stress of that tetrahedron. Of course, each node could potentially belong to multiple tetrahedra, so you'll want to be able to sum up these forces.
Integrate! There are easy ways to do this, and hard ways. Either way, you'll want to loop over every node in your world mesh and divide its forces by its mass to determine its acceleration. The easy way to proceed from here is to:
Multiply its acceleration by some small time value dt. This gives you a change in velocity, dv.
Add dv to the node's current velocity to get a new total velocity.
Multiply that velocity by dt to get a change in position, dx.
Add dx to the node's current position to get a new position.
This approach is known as explicit forward Euler integration. You will have to use very small values of dt to get it to work without blowing up, but it is so easy to implement that it works well as a starting point.
Repeat steps 2 through 5 for as long as you want.
I've left out a lot of details and fancy extras, but hopefully you can infer a lot of what I've left out. Here is a link to some instructions I used the first time I did this. The webpage contains some useful pseudocode, as well as links to some relevant material.
http://sealab.cs.utah.edu/Courses/CS6967-F08/Project-2/
The following link is also very useful:
http://sealab.cs.utah.edu/Courses/CS6967-F08/FE-notes.pdf
This is a really fun topic, and I wish you the best of luck! If you get stuck, just drop me a comment.
That rolling jelly cube video was made with Blender, which uses the Bullet physics engine for soft body simulation. The bullet documentation in general is very sparse and for soft body dynamics almost nonexistent. You're best bet would be to read the source code.
Then write your own version ;)
Here is a page with some pretty good tutorials on it. The one you are looking for is probably in the (inverse) Kinematics and Mass & Spring Models sections.
Hint: A jelly can be seen as a 3 dimensional cloth ;-)
Also, try having a look at the search results for spring pressure soft body model - they might get you going in the right direction :-)
See this guy's page Maciej Matyka, topic of soft body
Unfortunately 2d only but might be something to start with is JellyPhysics and JellyCar
I'd like to build a game to learn cocos2d. Lunar lander is the first exercise coming in my mind. Any pointer/source code/tutorial of the physics calculations required will be appreciated. Thanks!
You'll need stuff like this:
Newton's laws of motion in 2D.
Ability to change effect of gravity. 9.8 m/s^2 is the right acceleration on earth, but you should be able to change this to the appropriate value for Mars, moon, Jupiter, etc.
Ability to turn thrusters off and on to counteract the effect of gravity. Not a very interesting game if you don't, because every one ends in a crash.
Way to relate duration of thruster fire with fuel consumption. If you don't manage fuel well you crash.
Initial conditions (e.g., height above surface, initial velocity, initial fuel, etc.)
You'll start with initial conditions and loop over a number of time steps. At the end of each step you'll check the position and velocity. If the y-position above the surface is zero or negative you'll have landed. If the velocity is greater than a critical y-value you'll have a crash; less than the critical value means a safe, soft landing.
You'll solve Newton's equations of motion numerically. In your case it's four coupled, first order ordinary differential equations: rate of change of velocity in x- and y-directions and rate of change of position in x- and y-directions. If you have the thrusters in place you'll add another equation for conservation of mass for the fuel.
You can eliminate two equations if you assume that there are no x-components: the lunar lander moves perpendicular to the surface, the thruster force only has a non-zero component in the vertical direction. If that's true, you're down to three equations.
You'll do time stepping, so it'll be good to read up integration techniques like explicit Euler or implicit 5th order Runge-Kutta.
A challenging problem - not trivial. Good luck.
The math you need for a lunar lander game is pretty straightforward. Newton's Laws of Motion are all you really need - just pick up a basic physics textbook. You should be set after the first chapter. There are only two force inputs in the system - gravity and thrust from the engines. Just calculate the vertical & horizontal components of the motion, and animate your spaceship accordingly.
The physics are very simple: http://csep10.phys.utk.edu/astr161/lect/history/newtongrav.html
I assume you won't be worrying about drag or wind, so depending on your angles of inclination (user input), you'll be implementing:
Sourced from: http://en.wikipedia.org/wiki/Trajectory. You can even probably get away with simplifying it. If you don't want to be super-accurate, you can just do something like F=ma where is is whatever you decide the gravitational acceleration to be (9.8 m/s² on Earth).
If your game is in 2D, You don't need much math, you need physics, Specifically basic Newtonian motion. Probably intro college or late high school. The math is some grade school algebra with early high school calculus.
If you look at up-down motion, then your ship is essentially an object that is exposed to a force of gravity (the constant depends on your "moon") negated by the force emitted by its engines. You can use that to determine acceleration and from there velocity. Using the velocity, you can do your collision-outcome. The left-and-right motion is easier, since if your moon has no atmosphere, you are merely applying a constant force.
If you want something more realistic, you can modify the gravity constant based on distance from the surface, and can add an atmospheric friction force (though it wouldn't really be our moon).
If your game is in 3D, and your ship has side thrusters in addition to bottom thrusters, then you would not only have motion in location but also rotation. That has to do with rigid body physics. AFAIK that involves college level calculus.
This may be overkill, but I recommend looking at Numerical Recipes -- read the chapter on ordinary differential equations. You don't even need to study the entire chapter; just the first couple of sections.
In two dimensions, on every time tick you want to add the ship's rotational thrust to its rotational velocity, add its rotational velocity to its current heading, compute a thrust vector by multiplying the sine and cosine of its heading by its main thruster output, add that vector and a gravity vector (a straight downward vector of some magnitude) to its current velocity, and add its current velocity to its position. If the timer ticks are small enough, that's pretty much all you have to do, other than check to see if the craft is in contact with the ground. Experiment with the magnitude of your thrust and gravity values until you have a playable game.