Im simulating a swing door with generator using Simscape/Simulink. I imagine there is only one input for system which is the force at the knob needed to open the door, so all revolute joints have their torque actuation set to automatically computed. However, im getting an error saying:
"In the dynamically coupled component containing Revolute Joint 'SDL/SwingMotion', there are more joint primitive degrees of freedom with automatically computed force or torque (4) than with motion from inputs (0). In general, the equations of motion do not have a unique solution. Solve this problem by increasing the number of joint primitives with motion from inputs or reducing the number of joint primitives with automatically computed force or torque. Resolve this issue in order to simulate the model."
The animation works fine if i set the torque actuation of all 4 revolute joints to none, but the torque produced by the force wont be transfered this way and the generator shaft wont have any torque. However, I am able to measure the output RPM (angular velocity of generator shaft). I dont quite understand the error. Why do the revolute block treats the degree of motion of other revolute blocks as its own? How do i resolve this?
Block Diagram can be seen here.
The Assembly looks like this:
Any help is much appreciated!
For a revolute joint there are three options:
Let the revolute joint just act as a hinge, no torque can be exerted from base to follower and vice versa
Provide torque and calculate motion from the torque. This is called forward dynamics, motion is determined from torque.
Provide motion and calculate torque from the motion. This is called inverse dynamics, torque is determined from motion.
So you have to select either one of the option. If you select torque automatically computed, then you need to provide the motion which it has to follow. If you don't need to follow a provided motion, than no torque is needed.
If you set torque computed to 'none', then there is no torque that can be exerted from the base to the follower and vice versa, that is the idea of a Degree of Freedom.
It seems as if you want the Base and the Follower to be somewhat rigidly connected and follow the same motion. Than you can consider using the Rigid Transform block, which is just a rigid link in which you can define a translation or rotation offset.
EDIT
What you were effectively doing was combining forward and inverse dynamics. You put a force on the doorknob, let Simulink calculate the motion (up till now forward dynamics) then you desire the torque on the GenShaft from the motion it is doing, which is inverse dynamics. That does not work.
A better way to check the torque on the GenShaft is to, for instance, desire a certain door hinge angular velocity, put a proportional controller on it, and check the required torque. Notice that with no friction modeled in the hinge the required torque will go to zero.
So if you set all torque computed to 'none' except for the GenShaft, set this to provided by input. Then put a proportional controller on the angular velocity of the door hinge. You can then check the torque needed.
Updated model
Related
I‘m trying to create real physics simulation of the universal joint in unity. In my case universal joint is in vertical position. The whole mechanism consists of four objects: white ceiling, green shaft, blue universal joint and red shaft. All parts have Rigidbody component, with specific mass (ceiling – 1kg, green shaft – 0,05 kg, blue universal joint - 0,01 kg, red shaft – 0,05 kg). The mass of center of the parts are represented in the pictures. All objects dimensions are NOT scaled and represent the real dimensions of an object in cm. The Box Colliders or Mesh Colliders were not added to the objects.
Green shaft center of mass point, Blue universal joint center of mass point, Red shaft center of mass point
The parameters for all objects are represented in the pictures: Green shaft parameters, Blue universal joint parameters and Red shaft parameters. To the ceiling object only Rigidbody component was added with an “Is Kinematic” option, without the “Use Gravity” option. One Fixed Joint and two Hinge Joints are used for objects. My aim is to create realistic physics behavior of this universal joint in simulation. For example, while playing the scene I want to be able to move the red shaft end, let go it and see how because of gravity and friction red shaft swings back to initial position. I want to do this with object components and project settings, not with a script if possible. If I succeed with universal joint physics I will later plan to add a point on the red shaft object end, which would have Constant Force component and would pull the red shaft end on demand with force to the certain direction. But the force which would pull the red shaft end would be based on real measurements.
The problem that I’m currently facing right now is with the object swinging back to initial position. If I leave Rigidbody and Hinge Joint parameters as it is represented in pictures and try to move red shaft end in scene play mode, the red shaft and blue joint swings back to initial position very very slowly. Like it would have no mass or would have very high friction. But if I turn on red shaft and blue Use Spring parameter in the Hinge Joint and set Spring value for example to 0.2 the shaft as expected goes back to initial position much faster. I also noticed that if I increase object Scale parameters (increase object size) for example from 1 to 100 it swings faster without the spring parameter turned on.
My first question which component or project parameters have the most impact on pulling object down in gravity direction?
Is where more friction friction parameters about which I should know while creating this universal joint model? Because so far I have changed only Drag, Angular Drag to 0, I have created a PhysicMaterial with almost no friction and added it to Default Material field in Project Settings->Physics. I have increased Default Solver Iterations and Default Solver Velocity Iterations almost to the maximum.
My third question would be, is it even possible to create a realistic universal joint shaft swinging without Spring option turned on in the Hinge Joint? Or should I better write the script that would define the red shaft swinging with gravity behavior?
First, Unity physics are not real physics, they are real-looking physics.
Second, Unity units are typically assumed to be in meters. When you set a position to <1, 0, 0> you should assume your object is at 1 meter in x.
Third, Unity physics uses colliders to determine volumes, for the purposes of moments of inertia.
So, when you say that
The mass of center of the parts are represented in the pictures. All objects dimensions are NOT scaled and represent the real dimensions of an object in cm. The Box Colliders or Mesh Colliders were not added to the objects.
It makes me think that (1) you are using the wrong scaling, like 1 = 1 centimeter instead of the assumed 1 = 1 meter, and (2) you're preventing Unity from being able to really run the physics calculations correctly because you're not providing volumetric information to the physics engine (which again is done via the collider volumes).
Also, your masses seem very, very, very small. You've got the universal joint at 10 grams, which is really not much at all.
You're seeing better results when you add a spring because the spring is adding a force, where your weights are small and your missing colliders are failing to do much with physics.
I would suggest adding mesh colliders and increasing the weights to get the behavior you want to see.
I have a big spherical Gameobject which moves forward in 3D with constant velocity. I have other spherical objects that other big object needs to attract to itself. I am using Newton's law of universal gravitation formula to attract other objects, but as expected, other objects are doing a slingshot movement much like the space shuttles doing when needed with other planets' orbits to accelerate.
I actually want a magnetic effect that without taking the masses into account, all other objects will be catched by the big object. How can I do that? Do I need a different formula? Or do I need to change the movement behavior of the objects altogether?
If I got it right you expect to have something like this: https://www.youtube.com/watch?v=33EpYi3uTnQ
You can do a spherical raycast or have an sphere collider as trigger to detected the objects that are inside of your magnetic field.
Once you know those objects you can calculate the distance from each of them to the magnetic ball.
You can make an inverse interpolation to know how much strength/"magnetism" is getting into that object.
Then you can apply some force on the attracted object towards the magnetic ball's center.
Something like this algorithm:
var objectsInsideField = ListOfObjects;
foreach (o in objectsInsideField) {
var distance = (o.position - center.position).magnitude;
var strength = distance / fieldRadius; // fieldRadius == spherical radius
o.AddForce(dir: o.position - center.position, strength: strength)
}
Of course, you need to do some adjustments and probably add some multipliers to make the force to be meaning.
The final result should be: for each sequential frame, if the object is inside the magnetic field it moves towards the center a bit. The next frame it should be even close to the center so the strength is even bigger.. and so and so.
First of all, since the big objects is moving with constant velocity, a coordinate frame with axes parallel to the axes of the original coordinate system will be moving uniformly with constant velocity, so this new moving coordinate system is also inertial and you can write all your equations of motion in it, calculate everything with respect to it, and at the end you add the uniform movement to the results. The benefit is that the big object is stationary in this coordinate system, so simpler physics applies.
The slingshot effect occurs most likely because your objects are treated as mass-points, rather than bigger 3D entities (like spheres), for which the centers of mass never get too close enough. Hence maybe some sort of collision detection may eliminate this problem, especially if you decrease significantly or kill completely the elastic collision resolution.
All of what I am saying is a bit speculative as I have no access to details.
How does SpriteKit's physics engine (Box2d) move bodies and apply gravity to them?
is it just the standard:
velocity = velocity + gravity
position = position + velocity * deltaTime
or is there a more complex equation.
I ask this because I am trying to calculate the trajectory of the body and plot it.
Simplified, this is correct. However there can be other forces acting on a body (collisions, joints) and thresholds (ie stop moving if velocity below threshold, etc) and floating point rounding errors can add up.
So if you're looking for a forward calculation it depends on how precise it needs to be.
The most precise option would be to actually run the simulation to advance it to see where bodies will be - however since SK doesn't give you the Box2D sources this can't be done, ie you can't copy the world state and advance it manually in a copy of the current world.
I am writing Cocos2D box2d game for iPhone.
I've 2 dynamic bodies, and I hope they are applied force from outside, but they don't apply force each other and detect their collision.
How can I achieve this?
And also I hope they move together at the same position after collision.
How can I do this?
they don't apply force each other and detect their collision
Sounds like you might want to look at collision filtering. This answer has a bit of code that changes the collision filtering index of a body dynamically https://stackoverflow.com/a/11283206/735204
they move together at the same position after collision
Probably some kind of joint (eg weldjoint?)
From the manual: http://www.box2d.org/manual.html
Joints are used to constrain bodies to the world or to each other. Typical examples in games include ragdolls, teeters, and pulleys. Joints can be combined in many different ways to create interesting motions.
Some joints provide limits so you can control the range of motion. Some joint provide motors which can be used to drive the joint at a prescribed speed until a prescribed force/torque is exceeded.
Joint motors can be used in many ways. You can use motors to control position by specifying a joint velocity that is proportional to the difference between the actual and desired position. You can also use motors to simulate joint friction: set the joint velocity to zero and provide a small, but significant maximum motor force/torque. Then the motor will attempt to keep the joint from moving until the load becomes too strong.
Sorry about last answer, just checking that I can write it.
What about this?
bodyDef.isSensor = true;
and use ContactListener to detect collision. Box2d for collision detection
Also you can use box2d filters. For example:
REMEMBER: if groupIndex < 0, same bodies never collide with each other. That is what you need.
b2Filter bodyFilter;
bodyFilter.groupIndex = -1;
bodyFilter.categoryBits = 0x0002;
fixtureDef.filter = bodyFilter;
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.