Our solar system was created in three hours… well, at least that was how long it took for me to create a model of it in MapleSim. This process started out as an inquiry from a MapleSim user asking if MapleSim can be used to model planetary motions, through the use of Newton’s law of gravity. I view this kind of inquiry as both a challenge (any time someone asks “can MapleSim do such and such” it is an automatic invitation for us Applications Engineers to try it out J ), and an opportunity to learn new things.

While I am somewhat fascinated by astronomy (who isn’t dazzled by all of those pretty photos of various celestial bodies in the universe?!), I have never developed a keen interest in it.  That can be partially attributed to the fact that I grew up in a city that never sleeps, which means serious light pollution (I didn’t realize how beautiful the night sky was and how bright the stars can be until my teenage years on a family camping trip…  but that’s another story). The aspect of astronomy that I understand tells me that the law of gravity applies, to a certain extent, and that the magnitude of the numeric values that we are dealing with (for planetary motion simulation) is astronomical! So for me, these are the two key issues that will need to be addressed when creating a MapleSim model.

Although MapleSim has a built-in gravity feature that automatically models uniform (constant) gravitational field along any of the three Cartesian (x, y, z) axes, gravitational pull between two rigid bodies requires something a little different. From Newton’s law of gravity, the attraction force  between two rigid bodies (with masses  and ) at a distance  apart is given by:

 denotes the gravitational constant.  The gravitational force vector acts along the straight line connecting the position of the two rigid bodies.  As the rigid bodies move in three-dimensional (3D) space, both the direction and magnitude of the gravitational vector will vary, and as such both will need to be computed over time.  While it is quite straight forward to compute the magnitude of gravity using the above equation, the geometric computation for the direction of the gravitational vector can be quite complex, as it involves projecting the magnitude along a time varying spatial vector.  Fortunately, there is a simpler way to implement such time varying force vector: it is through the use of the Translational Spring and Damper Actuator (TSDA).  

Figure 1: MapleSim’s TSDA Component

As the name suggests, the TSDA component implements a spatial spring and damper, with an optional force actuation input. Embedded within the TSDA component model is the direction calculations. Therefore, to implement the gravitational vector with the TSDA, it is as simple as computing the force magnitude and feeding that into the TSDA component as the actuator input (with the spring and damping coefficient set to zero)!

Having sorted out the mechanics of implementing gravitational force, the next problem to tackle is the sheer size of the numeric values involved in the computation. For example, in SI unit, the average distance between the Sun and the Earth is close to 150 million kilometres! And yet, the average orbit distance for Jupiter is even larger (about 5.2 times bigger). A common solution for handling such astronomical numbers in planetary motion calculations is to perform the computation with normalized or scaled quantities. With this in mind, using the Earth’s orbit around the Sun as the base reference, we can have the average distance between the Sun and the Earth as the base unit of distance, i.e. 1 Astronomical Unit (). Similarly, we can use the Sun as the base reference for mass unit ( ) and the Earth’s orbit period as the time unit (). Scaling all of the quantities within our solar model with these base factors, normalized parameter values for our Solar System model can be obtained. Table 1 shows some of these normalized parameter values used in our model.

Table 1: Normalized Parameters

 Although SI units are used for computation within MapleSim by default, configuring the computation to be performed with the normalized unit is relatively straight forward: just specify all of the parameters in the model consistently using the normalized values. That way, the computed results can then be interpreted in the corresponding normalized units (see Table 2).

Table 2: Simulation Quantity Conversion/Interpretation

 The screenshot in Figure 2 shows the result from my Solar System model ran for 250 Earth Years (250 seconds simulation duration). The orbit lines are generated as trace curve of the trajectories of the planet (rigid bodies). To obtain this particular set of simulation result, an initial reference point needs to be specified. In terms of the planetary motion, the initial conditions are specified through orbital state vector for each of the celestial bodies (I would have preferred calling them “planets”, but I have included Pluto in my model…). The state vector are essentially the position (x, y and z location) and velocity of the bodies expressed with respect to the inertial frame of reference (in this case centered around the Sun) at the start of the simulation. The reference data I used was for epoch J2000.

Because only the gravitational effect between the Sun and each of the orbiting bodies are modelled, the resulting shape of the orbit is determined by the initial conditions. This means the model can be modified quickly (by changing the appropriate initial conditions or state vectors) to model other orbiting systems (such as satellite or moon orbits around the Earth). Of course, additional effects, such as gravitational perturbations or coupling forces between orbiting bodies can also be added easily. This makes the Solar System model not only fun to make (I get to learn about epoch, state vectors, orbital elements and some other fun facts that I didn’t know before), but potentially quite useful in other application areas as well (e.g. space vehicle simulation).

Figure 2: Planetary Motion of our Solar System