I'm trying to create a simple model of a body which will then be later controlled. However, I am running into trouble when I'm connecting both legs to the body.
What I have done is that I have built the model starting with the left foot, attached to the world frame, and then up to the torso. I ended up duplicating one of the legs and attached it again the the world frame and the torso, effectively closing the "loop". However, I get the following error message when trying to run the simulation.
'untitled/Right Leg/Hip/Revolute Joint' has a degenerate mass distribution on its follower side.
I have a feeling this has to do with the fact that both legs are attached to the torso and to the world frame.
If I let the legs dangle from the torso by attaching the torso to the world frame directly, then it works. But I need the legs to be attached to a "ground/floor"
What would be the correct way to model this so that I can later actuate the joints?
I believe you need three connections between your robot and the floor:
A contact force between the left foot and the floor
A contact force between the right foot and the floor
A virtual connection that lets you specify the initial height of the torso above the floor.
The virtual connection to specify the initial height above the floor is usually done with a 6-DOF Joint. It doesn't constrain anything, but lets you specify initial position, orientations, and velocity of the torso.
The contact force can be done with a hard stop, but I would recommend you look at this library on the MATLAB Central File Exchange:
https://www.mathworks.com/matlabcentral/fileexchange/47417-simscape-multibody-contact-forces-library
This will allow you to model contact between the feet and the floor, as well as friction which will enable the robot to walk. The force you need is the Face to Plane contact force.
Give it a try and see what you think.
--Steve
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 am working on an AI mode for a SpriteKit game I am making in Xcode. I have dynamic physics bodies which can be launched towards the AI. I want to make it so that when one of these bodies is within a certain radius of the AI, the AI tries to dodge it. I have started working through different routes and got decent results.
1st method (pseudocode): Check AI.position.x and AI.position.y and compare to incomingSprite.position.x and incomingSprite.position.y. Break this comparison into quadrants if both x and y are within radius. (i.e. incomingSprite is bottom left relative to AI, bottom right, etc). Based on this info move the AI's position to move away from it.
cons:
-lots of code and calculations in update function to account for multiple incoming sprites
-depending on dx and dy of incoming sprite, the AI often make illogical decision
2nd method (pseudocode): Calculate distance from AI to incomingSprite. Then check dx and dy of incomingSprite and set dx and dy to go in reverse direction of incomingSprite. This seems logical. I am a little rusty on reversing vectors to do this. I feel like this might be possibly a good idea though.
Is there a better method to accomplish this? Perhaps a force field on the magnet I could use to repel the AI at a certain strength so that if the incomingSprite is fast enough it will override and still collide anyway? Im concerned about memory as most of the AI logic is in the update function, which can cause big problems if I'm not careful.
Edit: I decided to use the electric field and gave the incoming sprites a positive charge so that they are repelled by the AI. This makes things accurate/lightweight and more interesting. If the incoming sprites are fast enough, they will break through the electric field and still collide with AI. This also gives room as an additional difficulty parameter in my game (the stronger the field, the harder it is to get the incoming sprites to collide with the AI).
xcode 5 iOS7 sprite kit.
My wish is to make a sprite that has its own gravity.
Like a planet. If another sprite comes within a certain range of it, it will slowly pull the other sprite closer.
I have two sprites. One moving and one stationary. When the moving sprite gets in a given distance of the stationary sprite the stationary sprite gravity should slowly pull the other sprite towards it. This way the moving sprite would change its path in a soft curve.
My idea would be to calculate the distance from the stationary object to any other object and if close enough start pulling and if the moving object gets out of range ageing, then stop pulling.
Would probably need to research some vector calculation.
Thats my immediate thoughts.
Is this possible and how? Does it already exist?
A friend of mine did this for his physics dissertation. multibody gravity simulation. So yeah you can but you need to be willing to learn some maths. Apparently there is a clever optimisation to make it run decently nlog(n) rather than n^2). you probably want to ask this on the physics version of stack overflow to get a good answer. I have the code at home ... will post it later but you will want an explanation - i used it in an xna app. Its badass once you get it working - although if you want naturally orbiting objects then you will want to code them using parametric equations for easy and cool orbits. Simply because its hard to solve and with time even using double will result in some errors (the good implementations also work out the error and adjust - again will post later). But the real problem is solving for stable orbits. You then use the algorithm for free moving bodies such and player objects / npcs. Although solving accurate movement for npc in a changing field is v hard.
you want to look at this question: Jon Purdys answer is the one you want
multi body physics - gravity
and this one (which is linked from above) ...
https://gamedev.stackexchange.com/a/19404
There is not a dead-simple way of doing that in any platform as far as I know maybe except for some game engines/platforms that export for different platforms (cocos2d, construct 2 etc).
What you need is a physics engine whether you write one (which is a complicated but fun thing to do) or use an available one.
Luckily I've found a link describing the usage of the famous 2D physics engine "Box2D" on iOS.
This one explains how you can include Box2D in an openGL application (but you can apply this to other environments (sprite kit) I think altough I'm not an iOS guy);
http://www.iforce2d.net/b2dtut/setup-ios
Anyways, you now know what to look for...
For iOS 8.0+ : you have SKFieldNode : radialGravityField()
For iOS 8.0- : one solution could be : 3 to 9
add your sprite ( planet ) with its physics
add an invisible SKNode ( the gravity zone ) with its own physics, as a child of your sprite, but with a radius much more than your sprite's one
you have a little explanation about invisible node here : https://developer.apple.com/documentation/spritekit/skphysicsworld
both, your sprite and the invisible node are centered in a zero gravity world
we look for contact and not collision ( set correctly your bit masks )
when any object get in contact with the invisible node ( gravity zone ), first you remove any moving action or impulse from it and then we add to this object an SKAction to move it toward the center of your sprite ( planet )
at second contact between this object and your sprite ( planet ), you remove all actions again from the object with a velocity = zero
I'm trying to re-create a 'falling sand' simulation, similar to those various web toys that are out there doing the same thing - and I'm failing pretty hard. I'm not really sure where to begin. I'm trying to use cellular automata to model the behavior of the sand particles, but I'm having trouble figuring out how to make the direction in which I update the 'world' not matter...
For example, one of the particle types I'd like to have is Plant. When Plant comes in contact with Water, Plant turns that Water particle into another Plant particle. The problem here though is that if I'm updating the game world from top to bottom and left to right, then a Plant particle placed in the middle of a sea of Water particles will immediately cause all of the Water particles to the right and below that new Plant particle to turn into Plants. This is not the behavior I am expecting. =(
One straightforward solution is to not do each iteration in-place. Instead, every time you update the world, create a copy of it... then look at the original, but update the copy. That way the order of updating does not matter any more, because you are completely disregarding your updates while you're looking for particles.
Don't program it in a sequential way (looping over all particles) but use real simulation programming techniques in which every particle is treated as an individual object/agent that obeys the laws of physics and that can act (run) asynchronously and respond to "events" (interactions with other particles).
If making every sand particle a separate object is too fine-grained, then divide the world into small blocks of let's say 1000 particles and simlute the behavior of these blocks instead.
I think it would be fun to model a top view of a train following a track, traversing switches and so on, using a physics library like Box2D. What joints and motors would I need to make this work?
I'm curious about how to implement the forces needed to make the car follow a spline track so it can bump into other train cars, pedestrians, DeLoreans etc. Just saying "the car is now at spline(t)" for each time step would create excessive forces in the physics engine. If I understand correctly, you have to stick the car onto the track with one force, constrain its angle to tend towards parallel with the track with another (or stick the front and back of the car to the track with two forces), and create another force to propel the train forward. I'm looking for some details on how to accomplish these things.
I believe it would be easier without "real" physics, like the ball movement of games such as Luxor or Tumble Bugs. Meaning: let the train follow a spline which is defined by the tracks.
Using phyiscs is probably overkill to make a train follow a track and could lead to all kinds of undesired side-effects, including jerky motion, train derailing, train getting stuck on junctions, etc.
You could still join the individual wagons together using physic joints, however. Just make sure that only the locomotive gets acceleration forces, the rest of the train just follows or is pushed but stays on the spline.
Why are you worried about keeping it "on the tracks"? Where is it going to go? Gravity should keep it down, object intersection should keep it up, and so the only directions you need to worry about are forward and backwards. That's where a motor comes in, and you're done. The rest is decorations.
In response to edit of problem:
Siderails. And have the train long enough / rigid enough compared to its width that you can navigate crossings (make them closer to right angles to minimize the crossing problems.
A top-down view (i.e. seeing the train from the sky) doesn't really require a 2d physics engine - if I understand you correctly. In fact, it seems like it wouldn't really help with the problem (if you want a train simulation), but then maybe you just wanna try it out for fun. :)
However, what about putting something like a slider joint on the train and the cars, and a motor on the locomotive. The slider joint might need some special implementation; you probably want to run the train along a spline and not a segment of straight lines, right?
Some sort of ball joint would connect the cars together.
The implementation is not so toughand I was able to prototype something in a few hours that does the basic job. It will require a lot of work to make it run smoothly, but it's essentially just "siderails."
Being top-down you obviously first must turn off gravity in Box2D. Second, build a train. Treat train wheels like car wheels and it'll suddenly get a lot more simple. For tracks you have a few choices:
Create your own game object (not in the box2D world) that is a simple line the train will then "follow" (you can use motors on train wheels to "steer" towards the line). Then just overlay the line with some nice wide "rail" graphics and you have a nicely faked system. Tell the wheels to turn off if it strays too far from the line and presto, you have a derailment.
Create actual physical rails - outside rails (like siderails) that the trains "wheels" will bump into. They will have to have gentle curves in this instance, which could be very difficult given the limited resources you have (simulating a nice slow curve out of boxes in Box2D is rough on the processor)
Then just let your train go!