C/C++ Simulating a Pendulum in C++: Seeking Assistance

AI Thread Summary
The discussion centers on simulating a pendulum in C++ using x,y coordinates instead of angular coordinates. The user reports that while the pendulum oscillates correctly, it gradually "sinks," indicating a problem with the simulation. Two methods for calculating forces are presented: one that incorporates both tension and weight, and another that uses only the gravitational component. Both methods yield similar oscillation results but fail to maintain the pendulum's height.Participants suggest that the issue may stem from precision errors, particularly if the user is converting between double and float types. They recommend using Euler integration for better accuracy and suggest considering polar coordinates to maintain a fixed distance from the pivot point. The conversation highlights the importance of accurately calculating forces and updating velocities, emphasizing that using the average of old and new velocities can improve the simulation's fidelity. Overall, the discussion focuses on refining the simulation approach to prevent the pendulum from sinking while maintaining its oscillatory motion.
iox
Messages
4
Reaction score
0
Hi all,

I'm having some problems trying to simulate a pendulum in C++. I am using x,y coordinates (and not angular coordinates, velocity...) to use the same method than all other dynamics in my program which are:
- Compute sum of all forces
- a = sum(F)
- v += a
- position += v

For the pendulum I'm getting quiet the good movement oscillating from right to left and reverse but the bob is "sinking" little by little.

First Method: Force = Tension + Gravity
Code:
// Weight Force
fWeight->set (0, mg);  // x,y of force vector

// Tension Force: T=-mg.cos(alpha) in tangential/radial coordinates
//       so back in my original coordinates
double Fx = mg*sin(alpha)*cos(alpha);
double Fy = -mg*cos(alpha)*cos(alpha);
fTension->set (Fx, Fy);

// Result Net Force
fResult->set (fWeight->xV() + fTension->xV(), fWeight->yV() + fTension->yV());

Second Method: Force = mg.sin (alpha)
Code:
fResult->set (mg*sin(alpha), AngleRad (alpha));

As I said the 2 methods give the same result: oscillating but falling...
Can you tell me if the way I am computing the total forces is correct ? If you notice something wrong tell me !

Thanks
 
Last edited:
Technology news on Phys.org
by falling do you mean the penduum swing is getting smaller and smaller if so then maybe you have a rounding error creeping in.

Are you using the Euler integration method?

Are you doing anything where you convert double to float and back again?
 
No I mean my pendulum is composed of 2 programming objects, a stick and a circle, and I am doing the calculation on the circle (on which I apply the forces and compute the new coordinates), and the circle is falling on my screen (y coordinate increases too fast). The swing movement seems to stay constant.
And yes maybe I have a problem of precision, I have to check that but I don't know how to do it ^^
But what I want to know first is if the way I compute the total force is correct.
 
Last edited:
That is a problem of your (simple) calculation method - try to use more advanced methods, like Euler integration. Alternatively, use polar coordinates - this avoids any movement of the pendulum by construction. You could do this in an implicit way if you "fix" the distance to the center in each step with some correction factor.
 
What are the limitation of my simple method ? Why is it not working in this case ? or In what cases it is not working ?
Because I have another example of a particle subjected to a centripetal force with an initial velocity. The trajectory is theoretically a circle and I have a spiral.
I will try to fix the distance as you said.
Thanks.
 
Consider a particle at some fixed point, with a known velocity. For the next step, you change the velocity, based on the acceleration, and move the point with the new velocity. But this is wrong - the new velocity will be reached after the time step only, in between you have something between the old and the new velocity. A better method would be to displace the point by the average of the new and the old velocity, for example.
"Euler integration" as keyword should lead to many different options to minimize those errors.
 
Thanks, I will try to play a little around that.
 

Similar threads

Replies
20
Views
2K
Replies
2
Views
784
Replies
12
Views
2K
Replies
17
Views
2K
Replies
9
Views
2K
Replies
3
Views
2K
Replies
2
Views
1K
Back
Top