Core Concepts#
This page briefly outlines general core concepts that are frequently referenced when working on musculoskeletal simulation projects, irrespective of the simulator (e.g. OpenSim, OPynSim, MuJoCo). The OpenSim Concepts and OPynSim Concepts explain specific concepts about those simulators.
Common Mathematical Datastructures#
At its foundation, musculoskeletal modeling relies on linear algebra to describe spatial locations, orientations, and movements:
Vectors/Arrays: Data structures that can be used to represent positions, velocities, accelerations, or force vectors in 3D space. This differs from mathematical literature, where a point defines a fixed location in space relative to an origin and a vector represents a direction and magnitude independent of location. Both are typically represented interchangeably by a vector/array (in Python, usually by a NumPy array).
Reference Frames (Transforms): A frame defines an origin point and a set of orthogonal \(X, Y, Z\) axes. Moving vectors or points between frames requires a Transform. The distinction between a point and a vector is that points translate and rotate, whereas vectors only rotate (i.e. the transform’s translation is ignored for vectors). In the literature, and most software APIs, frames are often synonymously called Transforms, Rigid Transforms, Pose, or Coordinate Systems.
Pragmatic Programming Takeaway
Modelling involves a wide variety of mathematical algorithms, but only a few datastructures. Getting familiar with the general concepts and usage of vectors, matrices, and transforms is relevant to a wide variety of research libraries. Learning how to take a vector out of one library (e.g. a simulator) and pump it into another (e.g. a plotter, a machine learning library) is valuable skill to master when developing research codes.
Coordinate Systems#
Musculoskeletal models contain multiple coexisting coordinate systems to make local definitions intuitive. Here are some commonly used coordinate system types:
Ground (World Frame): The top-level inertial reference frame that serves as the immovable “universe” or origin \((0,0,0)\) of the simulation. Ground acts as the root node for the entire kinematic tree.
Body-Centered (Local) Frames: Rigid bodies (e.g., Femur, Tibia) define their inertial properties, mass center relative to a local origin fixed to that specific body.
Custom/Offset Frames: Musculoskeletal models may define frames within ground, body, or other custom frames. For example, a femur joint parent frame might be defined within the pelvis body frame.
Joint-Centered Frames: Joints may define axes of rotation and translation by referencing frames relative to the connected parent and child bodies. For example, a hip joint may reference both a frame on the parent (pelvis) and child (femur) bodies, or custom frames defined within those.
Non-Cartesian Coordinate Systems: While 3D spatial points use Cartesian coordinates \((x, y, z)\), certain parts of a model may rely on alternative representations. For example, cylindrical coordinates \((\rho, \phi, z)\) might be the best way to describe a muscle wrapping over a cylinder. Spherical coordinates may be the best representation of a ball-in-socket joint, and so on.
Pragmatic Programming Takeaway
When writing code that handles spatial vectors, always be thinking “What coordinate system is expressed in?”. A common trick is to transform everything into the unified Ground frame to simplify things (e.g. when calculating the distance between sets of point pairs in IK).
Kinematic Chains & Trees#
A Kinematic Chain refers to an assembly of rigid bodies connected by joints that constrain their relative motion. In musculoskeletal modeling:
Topology: Models form an open-loop or closed-loop joint hierarchy (tree graph) rooted at the Ground environment frame.
Degrees of Freedom (DoFs): Each joint specifies the permissible relative motion between a parent and child body (e.g., a Pin/Hinge joint allows 1 rotational DoF; a Free joint allows 6 DoFs). In OpenSim nomenclature, these DoFs are managed as individual Coordinates (\(q\)).
To construct a valid model, every body must attach to the root frame through a continuous kinematic chain. Unattached bodies cause singular system matrices during computation, or must be automagically attached to ground with a joint.
Pragmatic Programming Takeaway
When designing/using musculoskeletal models, be aware of the kinematic chain/tree. Moving a body that’s further up in the tree causes all children to move. Attaching bodies to each other incorrectly results in invalid motion. It can be useful to sketch the topology on paper when designing a model.
Physics Systems#
A Physics System combines the structural kinematic tree with physical laws, forces, and mathematical constraints to evaluate or simulate physical movement:
Constraints: Loop-closure constraints, coordinate couplings, or point-on-line constraints that further restrict motion beyond joint definitions.
Force Elements: Passive forces (gravity, contact dynamics, spring-dampers) and active forces (actuators, Hill-type muscle models).
System Solvers: Numerical engines that process state equations to solve key biomechanical problems:
Forward Dynamics: Integrates equations of motion forward in time given muscle activations to compute resulting accelerations and trajectories.
Inverse Kinematics (IK): Finds joint coordinates (\(q\)) that minimize the distance between experimental motion capture markers and model markers.
Inverse Dynamics (ID): Calculates net joint moments required to produce a given set of kinematically observed accelerations.
Model Specification#
A Model Specification is a static, declarative data structure—often serialized as a hierarchical XML, JSON, or URDF file—that defines the topology and properties of a physics system.
Regardless of the underlying software engine (OpenSim .osim, MuJoCo .xml, or OPynSim), a model specification outlines:
Rigid Bodies: Mass, center of mass location, inertia tensor, and attached geometry.
Joints: Parent/child attachments, transform offsets, and coordinate limits.
Actuators & Path Objects: Muscle origin/insertion sites, via-points, and force properties.
Crucially, the Model Specification is static parameter storage; it contains no runtime variable data (such as current velocities or time step states).
Model State#
A Model State represents the instantaneous physical condition of a dynamic system at a specific time point \(t\).
While the Model Specification defines what the system is, the State defines what the system is currently doing. A complete state vector usually contains:
Time (\(t\)): The current timestamp of the system.
Generalized Positions (\(q\)): Joint angle or translation values across all DoFs.
Generalized Velocities (\(u\)): Rate of change of coordinates (usually \(u = \dot{q}\), but sometimes \(u \neq \dot{q}\)).
Auxiliary States (\(z\)): Non-mechanical variable states, such as muscle fiber lengths and physiological muscle activation levels.