camUrban/PteraSoftware

Problem Statement _transformations.py provides homogeneous 4x4 transform helpers (generate_rot_T, invert_T_pas, invert_T_act, and apply_T_to_vectors) but no equivalents for bare 3x3 rotation matrices, so the MuJoCo boundary code does rotation math inline with raw NumPy. The bare operations that need covering are: inverting a passive rotation (currently a .T; the TODO comment in MuJoCoModel.get_state already proposes naming this invert_R_pas), inverting an active rotation (the np.linalg.inv followed by .T in the MuJoCoModel constructor), extracting the 3x3 rotation block from a 4x4 transform (currently T[:3, :3]), and applying a rotation matrix to vectors (currently xmat @ qvel and R @ omega, the 3x3 analog of apply_T_to_vectors). This is correctness-neutral consistency work: the inline math is right, it is just unnamed, unvalidated, and repeated. Location(s): pterasoftware/_transformations.py, pterasoftware/_mujoco_model.py, docs/MUJOCO_CONVENTIONS.md, tests/unit/test_mujoco_model.py,

Problem Statement Airplane.weight defaults to 0.0 and OperatingPoint.g_E defaults to (0.0, 0.0, 0.0), so an all-defaults free-flight problem passes the weight == mass * |g_E| consistency check and silently simulates a weightless body in a gravity-free world. Every partial misconfiguration (a nonzero weight without gravity, or gravity without a matching weight) is caught with a loud, well-worded error; the fully-defaulted case is the one silent path through the check, and it is rarely what a free-flight user intends. Location(s): pterasoftware/problems.py (FreeFlightUnsteadyProblem.__init__), pterasoftware/operating_point.py (the g_E default). Proposed Solution Keep the zero defaults (they are deliberate: gravity and rotation rate always physically exist, zero is a valid value of each, and a genuinely weightless body should stay expressible), but log a warning from FreeFlightUnsteadyProblem.__init__ when the norm of g_E is zero, stating that the run will model a weightless body in a gra