A mechanism in this part is checked twice: once by hand, with virtual work or the equations of motion, and once in a motion solver that builds the model from bodies, joints, springs and motors as SolidWorks Motion does. This chapter sets up the solver. How a motion solver works explains the method; here we use a production code.

Exudyn [1] is the main tool. It is a C++ multibody code with a Python interface, installed with uv pip install exudyn, and like Adams, the solver inside SolidWorks Motion, it describes bodies by redundant coordinates, joints by constraint equations and returns the Lagrange multipliers as joint forces and motor torques; closed loops need no special treatment. MuJoCo, a physics engine from robotics, uses minimal coordinates with soft constraints and is strong on contact, but a closed loop needs an equality constraint. For comparison we keep pymunk, a two-dimensional game physics engine that runs interactively, sympy.physics.mechanics (and PyDy) for the symbolic equations of motion, and pylinkage for kinematic synthesis. PyChrono, the closest open counterpart of Adams, is installed through conda and is used only if the others fall short.

Planned content: the workflow (geometry and mass properties from SolidWorks, bodies and markers, joints, springs and dampers, motors as prescribed coordinates, sensors), the toggle clamp of Over-centre mechanisms, Example 4 as the first model, reaction forces compared with the multipliers of the hand-written solver, an energy check on every free motion, offscreen rendering of an animation, contact (a cam follower, a ratchet pawl), and STL geometry exported from SolidWorks. The test so far: the compound pendulum in Exudyn 1.11 and MuJoCo 3.15 against SciPy, largest errors \(2.4\cdot10^{-5}\) rad and \(8.5\cdot10^{-10}\) rad (Kinetics/_motion_solver_explore.ipynb).