I'm currently working on a project that needs a bit of friction to run the real environment.
But, and it's why i'm here, I have problems.
I'm trying to put a stick on a pad, and I want them to be a bit sticky together, and have some friction between them before the stick falls off.
I precise that i'm new to Gazebo, and i'm open to all of your advices.
Here is the example, were the green pad surface has a friction of mu and mu2 around 10000 (for testing), same for the sphere.
I tried to change the visual and collision geometry to see if the problem came from here, without effect.
There is three frames to illustrate the slipperiness of these surface:
Straight on pad
Begin to fall
Completely out
I performed some tests to understand the differents parameters (such as mu and mu2 here).
The ramp has these parameters for the first test :
mu : 100
mu2: 50
The ramp has these parameters for the second test :
mu : 0.0
mu2: 0.0
I think that these parameters vary between 0 and 1, but when I create a world, the ground has these values.
In each case, cylinders have, in the order, these parameters :
mu : 0.0
mu2: 0.0
mu : 0.1
m2 : 0.1
mu : 0.3
mu2: 0.3
mu : 0.5
mu2: 0.5
mu : 0.8
mu2: 0.8
mu : 1.0
mu2: 1.0
Here, the picture of the first test, when cylinders roll on the ramp :
Test1
Here, the 2 pictures of the second test, the first one shows the cylinders rolling down the ramp, and the second one shows what happens after, on the ground :
Test2_1
Test2_2
In the idea, the result will show that the first cylinder will roll slower than the second one, the second one slower than the third and so one and so one.
However, this is not happened.
These examples show that the lower mu is taken between two object, but why, for the first test, there is no difference for the cylinders between 3 and 6 ?
Plus, how to simulate the friction for my real application ?
I thank you in advance !
Have a nice day !
Related
I am trying to use a PID controller to stop a quadcopter at a specific location while travelling horizontally, however currently it overshoots/undershoots depending on the max velocity. I have tried manually tuning the P,I and D gains with limited success. Essentially the velocity needs to go from maxSpeed to 0 at the very end of the flight path.
I run a loop that executes every 0.1 of a second.
The pitch input to the quadcopter is in m/s and I recalculate the distance to the target on each iteration.
some pseudo code
kP = 0.25
kI = 0.50
kD = 90
timeStep = 0.1
maxSpeed = 10
currentError = initialDistanceToLocation - currentDistanceToLocation
derivativeError = (currentError - previousError) / timeStep
previousError = currentError
output = kP * currentError + kI * integralError + kD * derivativeError
integralError = integralError + currentError * timeStep
if >= maxSpeed {
output = maxSpeed
} else if output <= 0 {
output = 0
}
return output
Is there a way to reliably tune this PID controller to this system that will work for different max velocities, and/or are there other factors I need to consider?
A few ideas:
check in your code if you calculate the integralError after you calculate the output, too. This can, of course, lead to undefined behavior since in the output calculation, integralError could be anything depending on the programming language.
From my experience, you should get rid of the D part entirely, since in a digital environment and due to measurement noise, it could have destabilizing effects
I highly recommend looking at this tutorial which guides you through important aspects (even though it concentrates on fixed-point PI controllers)
Summary
To stop on a point, one easy way is to switch from a velocity PID controller to a position PID controller whenever you want to stop on a point, and turn up D (which dampens velocity in a position controller) to prevent position overshoot of your target point. See below for details.
Reminder: D in a velocity controller = useless. D in a position controller = essential. See my comment here, and notes below.
Details
I've done this before. I didn't spend a ton of time optimizing it, but what I found to work well was to switch from a velocity controller which tries to overfly waypoints, to a position controller which tries to stop on them, once you are near the desired stopping point.
Note that your position controller can also be forced into a velocity controller by scaling your gains to produce desired velocities, or even by scaling your position error to arbitrarily produce a desired velocity, and by moving the desired position point continually to keep the vehicle following a path. The video below demos that last part too.
The position controller was a PID controller on position: the vehicle's pitch angle was directly proportional to the distance from the target in the y-axis, and the vehicle's roll angle was directly proportional to the distance from the target in the x-axis. That's it. The integral would take out steady-state error to ultimately stop perfectly on the desired position, despite disturbances, wind, imperfections, etc., and the derivative was a dampening term which would reduce the pitch and roll angles as velocity increased, so as to not overshoot the target. In other words: P and D fight against each other, and this is good and intended! Increasing P tries harder to make the vehicle tilt when the vehicle has no velocity, and increasing D causes the vehicle to tilt less and therefore overshoot less the more velocity (derivative of position) that it has! P gets it moving quickly (increases acceleration), and D stops it from moving at too high of a velocity (decreases velocity).
For any controller where neutralizing the driving force (pitch and roll in this case) instantly stops a change in the derivative of the error, D is NOT needed. Ex: for velocity controllers, the second you remove throttle on a car for instance, velocity stops changing, assuming small drag. So, D is NOT needed. BUT, for position controllers, the second you remove throttle on a car (or tilt on a quadcopter), position keeps changing rapidly due to inertia and existing velocity! So, D very much is needed. That's it! That's the rule! For position-based controllers, D very much is needed, since it dampens velocity and acts as the dampening term to prevent overshoot of the target.
Watch this video here, from 0:49 to 1:10 to see the vehicle quickly take off autonomously in this PID position control mode, and auto-position itself at the center of the room. This is exactly what I'm talking about.
At approximately 3:00 in the video I say, "[the target waypoint] is leading the vehicle by two-and-one-half meters down the waypoint path." You should know that that 2.5 meters is the forced distance error (position error) that I am enforcing in the position PID controller in order to keep the vehicle moving at the shown fixed velocity at that point in the video. So...I'm basically using my position controller as a crude sort of velocity controller with a natural filter on the commanded path shape due to my "pure pursuit" or "vector flow-field" waypoint-following algorithm.
Anyway, I explain a lot of the above concepts, and much more, in my more-thorough answer here, so study this too: Physics-based controls, and control systems: the many layers of control.
function jackInTheBox(time)
y = amplitude * math.cos(frequency * time * 2 * math.pi) / math.exp(decay * time)
return y end
Above function is to simulate how jack in the box (When you open a jack-in-the-box, the spring-loaded “Jack” springs out with full force, and then bobs more slowly over time, until it stops. We can simulate a jack-in-the-box with the help of a little bit of trigonometry. )
But for what reason we are using cosine wave to calculate that? I always am confused about the fact if sine is to be used or cosine. Is the only reason after it that jack swings right and left with certain speed along the x-axis? Or anything more than that?
A sine is identical to a cosine translated by pi/2 radians. In other words, they only differ by a phase of pi/2. So it doesnt matter which function you use, except that the phase is determined by the initial condition: at t=0, the spring is at y=y0 (normally the speed is zero but this is not required). From this you determine the phase, although if the speed is 0 you know the spring must be at a crest. If you pick sine, sine a*t at t=0 is 0 so you need a phase of pi/2. If you pick a cosine, the t=0 already is at crest of function so phase is zero.
There is no relationship between function used and the sideways motion which is caused by combination of initial non-zero angle of spring to vertical, gravity which exerts torque on spring CofM, and possibly uneven vertical compression across the cross section of spring which causes some bending and thus couples the compression with horizontal CofM motion.
To summarize, you could have used either one but using cosine leads to a simpler equation given the initial conditions. Other initial conditions could have resulted in sine leafing to simpler equation and yet others to either function being similar complexity.
anybody who know how to calculate the speed of hand gesture from hand tracking ?
(i'm using processing 1.5.1 with simpleopenNI 0.27)
Thanks for your attention
Speed is distance per unit time. Therefore, speed is:
distance_between_hand_in_consecutive_frames/(seconds_per_frame)
To find distance in 3d, use Euclidean distance with the position of the hand in consecutive frames.
EDIT: A psuedocode example.
f1 = get_current_frame_hand_coordinates()
f0 = get_previous_frame_hand_coordinates()
Then you need a function to calculate distance. Your input should be two tuples, here a and b, of size three, i.e. (x,y,z)
e_distance(a,b):
d = square_root( (a[0]-b[0])^2 + (a[1]-b[1])^2 + (a[2]-b[2])^2 )
return d
dist = e_distance(f0,f1)
Basically, here you just plug the tuple values into the equation. I'm not sure how your code is laid out, this is designed for a single set of tuples.
Now that you have the distance, then we just need to calculate the speed.
speed = distance/seconds_per_frame
Wikipedia says that the framerate of a Kinect is between 9 and 30 Hz. This means that your seconds_per_frame is between 1/9 and 1/30 of a second.
This will only give you the speed. Your question asks about speed (which only has magnitude), but you can also get velocity (which has both magnitude and direction) fairly easily with a little trig.
The AppleDeveloper guide seem to imply that UIAccelerationValue can range between a double value of -1.0 and +1.0.
I have logged the values from a real device whilst "shaking" with crazy gestures my iPod touch and got x values above 2.0 (e.g. +2.1, -2.1) and NO y value above 2.0f.
Could anyone explain this?
Has anyone identified the MAX and MIN values for UIAccelerationValue?
My take on this is that Apple has implemented some algorithm that approximates the force of gravity and takes as 1.0 values that are above a standard speed approximation (e.g. have values 9.8 m/s of speed).
Any other guesses?
You may be misunderstanding a part of the documentation. Nowhere does it say that the value ranges between -1.0. and 1.0, as far as I can see. It says that:
The device accelerometer reports values for each axis in units of
g-force, where a value of 1.0 represents acceleration of about +1 g
along a given axis. When a device is laying still with its back on a
horizontal surface, each acceleration event has approximately the
following values:
"g" is used in a particular technical sense here; 1 g is one standard gravity; a phone accelerating faster than this will register readings higher than 1. Violent shaking in the hand is easily enough to cause acceleration and deceleration values higher than 9.8m/s2.
I have a rotating sphere that the user rotates by applying a virtual force, like a virtual accelerator. I want to be able to simulate a nice momentum effect so that when they lift off the accelerator the ball winds down in speed in a natural and realistic way, as if due to friction and/or gravity. I don't want to get into any deep physics equations. I'd like to do this quick so if I could find a code sample that shows how to do this, or even a page of formulas clear enough that I could encode, that would be great.
I'd like a formula that has one or two adjustable coefficients that I could tune to make the ball decelerate faster or slower depending on my needs. I don't want to get into anything heavy like an open source physics library or the like. Just something simple.
I'm using Delphi 6 Pro but I also know C/C++, Basic, Java, and Javascript.
Velocity is change in displacement. Acceleration is change in velocity.
Gravity or friction just causes an acceleration (possibly negative).
So all you need to do is apply a negative acceleration when they do not activate the accelerator.
So lets assume you have an angle that is changing. Applying the accelerator increases the amount the angle changes by each iteration or time step. If your angle is t and your change in angle is called dt (angular velocity) then when the accelerator is applied you'll have:
t = t + dt
dt = dt + a
where a depends on how much force you're applying, or how much they've 'pressed' the accelerator (i.e. this is the acceleration).
You'll probably want to limit dt (i.e. speed of rotation) - if you only want to spin in one direction you'll have an upper positive limit and a lower limit of 0. If you want both directions, you can have a lower negative limit and an upper positive limit.
All you need to do is make a some negative number when the accelerator is not applied (if dt is positive - make a positive if dt is negative), and ensure you don't 'wrap' (i.e. make dt 0 when it gets near 0).
It has been some time ago, but according to my dynamics study books the Mass Moment of Inertia for a sphere is defined as I=(2/5)m*r^2. m is the mass, r is the radius of the sphere (all in SI untis). On this page you'll find some examples to use the mass moment of inertia to calculate deceleration of the sphere as a result of the applied negative torque. This toqrue is a result of the friction. Since you are not defining the material of the surface of the sphere and the surroudings you cannot calculate the friction and will have to choose a good force yourself.
As long as you are not solving stellar problems, I don't see how gravity has much to do with decelerating the rotation.
Friction is almost proportional to the current rotation speed (actually the speed on the surface of the sphere).
So a formula for the current rotation speed over time w(t) may be something like this:
w(t) = w0*exp(-c*(t - t0))
with t0 being the time the friction starts, wt being the rotation speed at that time.
The coefficient c > 0 determines how fast the speed will decrease - the higher c, the faster the speed will go down. This formula is valid for all t >= t0.
Note that for t = t0 the exp function returns 1 and you get the initial speed, while for t -> ∞ the exp function (and so the resulting speed) returns -> 0 (the minus in front of the c guarantees this).
You've already accepted an answer, but I'll put in my piece.
I'll assume you already know how to make the sphere spin at a constant rate, and how to make it accelerate under the applied torque. Making it decellerate is just a matter of applying another torque, one that must be calculated.
When an object slides on a solid surface, the rate of deceleration is constant. The force is in the direction opposite to motion, and its magnitude depends on a couple of things but not speed. When the object comes to a full stop, the force vanishes. The same applies to a globe turning on a solid pivot.
When an object passes through a fluid, the force of decelleration increases with speed, so the faster the object the greater the drag. As the object slows down, decelleration grows weaker, and the object keeps slowing down but never stops. This describes a globe spinning in air or water. At reasonably high speeds, drag is proporional to v2, and at very low speeds it is proportional to v (I don't know about the transition between these domains).
So I suggest t = -a wb, where w is angular velocity. The parameter a is the strength of the friction, and b describes the kind of decelleration; b=0 is like friction on a solid pivot, b=2 is like spinning in air, and b=1 is like rotating in syrup. Other values of b may or may not look realistic or be realistic.