Basilisk Known Issues

On this page

Version 2.13.0b0

• GitHub issue 1621: tleHandling.frame_bias() applied the GCRS to mean J2000 frame bias rotations in the reverse order and with the wrong sign of \(\xi_0\). The TEME to J2000/ICRF conversion used by tleHandling and ommHandling therefore shifted TLE and OMM initial states by about 1.3 m in LEO.

• The error message of atmosphericDrag() in orbitalMotion, printed for a position with a non-positive altitude, showed the position components with an index shifted by one and read past the end of the position vector.

• GitHub issue 1619: The C++ Module: imuSensor module computed DVFramePlatform by rotating the whole TotalAccumDV_BN_B of C++ Module: spacecraft with the attitudes of the current and the previous IMU call. C++ Module: spacecraft builds this field by adding the delta v of each integration step in the body frame of that step, so every attitude change between two IMU calls turned the delta v accumulated since the start of the simulation into a spurious delta v.

• C++ Module: imuSensor did not discard the state of the previous IMU call in Reset().

• MJSite left the fields of stateOutMsg other than the position, velocity, attitude and angular rate of the site uninitialized.

• C++ Module: spacecraft did not initialize nonConservativeAccelpntB_B and omegaDot_BN_B of scStateOutMsg. They held uninitialized values in the message written before the first integration step and, with pointMassTranslationalOnly, during the whole simulation. They are now zero until computed.

• GitHub issue 1615: The C++ Module: eclipse module returned the occulted fraction \((b/a)^2\) of the solar disk instead of the visible fraction \(1 - (b/a)^2\) when the disk of the occulting body lies entirely inside the solar disk, where \(a\) and \(b\) are the apparent radii of the Sun and the body. The same formula in PlanetRadiationBase, used by C++ Module: albedo and C++ Module: earthRadiationModel, was also corrected, even though that case is not reached for patches on the planet surface.

• GitHub issue 1612: The C++ Module: spiceInterface module computed the GPS time of spiceTimeOutMsg as the elapsed TDB time since the GPS epoch instead of atomic time. GPSSeconds was in error by a periodic term of a few milliseconds, and GPSWeek and GPSRollovers could be one week early at a week boundary. JulianDateCurrent was read from a SPICE Julian date string, which has at most seven decimals, and was therefore quantized to 1e-7 day. GPSSeconds overflowed a 32-bit integer after GPS week 3550, and a simulation start before the GPS epoch produced invalid GPS outputs. The corrected UTC Julian date preserves the SPICE convention of holding at the following midnight during an inserted leap second, avoiding backward jumps.

• GitHub issues 1610 and 1611: Rigid-body kinematics conversions and composition now preserve identity, small rotations, half-turns, and Euler singularities; PRV rate maps use analytic limits at zero and angle wrapping handles multiple revolutions. Python and Numba retain sequence inputs and non-contiguous PRV arrays. Numba uses wrappers and overloads to avoid deprecated list reflection; see RigidBodyKinematicsNumba for compiled-call requirements and the public callable interface. Representation singularities and extreme floating-point magnitudes remain outside the numerical guarantees; see Numerical scope and representation limits.

• GitHub issue 1609: keplerianOrbit returned incorrect eccentric and mean anomalies, lost the sign of the flight-path angle, and returned zero rates after construction or stale rates after set_a(). These outputs are now consistent with the current elliptic orbit. set_mu() now refreshes the derived state immediately, and oe().rmag reports the current radius instead of zero. Anomalies follow the orbitalMotion.f2E() and E2M() conventions without additional normalization to the interval from zero to two pi radians.

• Optional wheel packaging could fail when independent runners supplied different Rust and Cargo versions. Nightly, release, and optional-wheel test workflows now resolve stable Rust once per run and use that exact toolchain for all core and opNav wheel builds, including builds inside Linux containers.

• The C++ Module: stripLocation module held its target at the endpoint after completion but continued reporting motion at the acquisition speed. The target velocity relative to the planet-fixed frame is now zero at and after completion, keeping the strip state and access rate outputs consistent with the fixed endpoint.

• The C++ Module: stripLocation module omitted rotation of the local SEZ frame as the target moved along a strip. Its v_BL_L, az_dot and el_dot outputs therefore disagreed with the derivatives of the published geometry for a moving target. These outputs now include the local-frame rotation; the range rate is unchanged.

• The C++ Module: stripLocation module did not copy the computed SEZ relative velocity into the v_BL_L field of its access messages, which therefore always reported zero. The C++ Module: groundMapping module never assigned its planet-fixed to SEZ rotation matrix, so its r_BL_L, v_BL_L, azimuth and rate outputs were computed from an uninitialized matrix. C++ Module: groundMapping also crossed the planet angular velocity in planet-fixed components with inertial vectors, and did not subtract the planet velocity of planetInMsg, as described in the two entries below. The C++ Module: groundMapping module also did not populate the rHat_LP_N field of its ground state messages.

• The C++ Module: groundLocation and C++ Module: groundMapping modules did not guard the division by the horizontal distance to the spacecraft in the azimuth, az_dot and el_dot access message fields, so these fields were undefined for a spacecraft exactly overhead of the location. The overhead test first used a fixed threshold of 1e-12 m on the horizontal distance, which is below the floating-point round-off of the SEZ position, so it could miss an exactly overhead spacecraft and leave azimuth dependent on round-off and az_dot and el_dot very large. The guard now accounts separately for distant-origin position quantization and local frame-transformation round-off, preserving resolvable near-overhead offsets in all three ground access modules.

• GitHub issue 1606: The C++ Module: groundLocation and C++ Module: groundMapping modules did not subtract the planet velocity of planetInMsg from the spacecraft velocity, so the v_BL_L, range_dot, az_dot and el_dot access message fields were in error by the planet velocity.

• GitHub issue 1605: The C++ Module: groundLocation, C++ Module: stripLocation and C++ Module: groundMapping modules crossed the planet angular velocity, which they computed in planet-fixed components, with inertial vectors when removing the planet rotation from the spacecraft velocity. The v_BL_L, range_dot, az_dot and el_dot access message fields were in error when the planet spin axis was not aligned with the inertial 3-axis.

• The gravity effector advanced the planet orientation of a SPICE-driven planet with a first-order update of the matrix elements, which is not orthonormal and distorted even a point-mass field by a relative error of order \((\omega\,\Delta t)^2\). The orientation is now advanced as a rotation about the planet angular velocity.

• The atmosphere, wind, magnetic field, eclipse, and solar flux modules evaluated the spacecraft state of the previous step, which made the solar radiation pressure shadow entries and exits a step late. The state can now be extrapolated to the middle of the step with setExtrapolateScStateToStepMidpoint(), which is disabled by default.

• The C++ Module: msisAtmosphere module computed the altitude over a sphere and used the mean solar time. The altitude above an oblate planet is now available with setPlanetPolarRadius(), and the apparent solar time with setUseApparentSolarTime(). Both are disabled by default.

• Atmosphere models that are evaluated once per integration step still show a step-size dependent drag error, which is second order in the step.

• The C++ Module: msisAtmosphere, C++ Module: windBase, C++ Module: magneticFieldBase, and C++ Module: magneticFieldWMM modules converted the UTC epoch with mktime, which uses the time zone of the computer. On a computer in a time zone with daylight saving time, the local solar time was one hour wrong for the part of a simulation on the other side of a daylight saving transition than the epoch. The epoch is now converted as UTC.

• The C++ Module: msisAtmosphere module used the daily Ap index and did not use the array of 3-hour Ap values that NRLMSISE-00 uses in its storm mode, so during a geomagnetic storm the density followed the daily mean from midnight. The 3-hour history is now available with setUseApHistory(), which is disabled by default.

• The C++ Module: facetSRPDynamicEffector module used a solar flux of 1368 W/m² at 1 AU, while C++ Module: radiationPressure uses 1361 W/m². Both now use SOLAR_FLUX_EARTH.

• GitHub issue 1598: Compilation database export requires Ninja or a Makefile generator; Xcode and Visual Studio do not support export. Clangd does not automatically discover the generated database in the default dist3 build directory. Configure clangd to use the directory containing compile_commands.json; see Configuring clangd for generator selection and the default and custom build-directory settings. Disabling export now removes an existing database from the selected build directory so clangd cannot keep reading stale compilation commands.

• Visual Studio 2026 solution-wide clean could fail because the C-message target used an absolute path as its solution folder. It now uses a valid relative folder name.

• Ninja Multi-Config builds could fail on C message interface dependencies. CMake now preserves these configured sources across native clean operations and avoids dependencies on other build configurations.

• scenarioSmallBodyNav supplied an 18-element state to the 12-state smallBodyNavEKF, causing Debug builds to abort. The example now supplies 12 elements. Invalid state and matrix dimensions raise BasiliskError in Python during reset or update.

• A buffer overflow in headingSuKF covariance updates and invalid zero-noise sampling in hingedRigidBodyMotorSensor are fixed. Both defects affected Debug and Release builds.

• horizonOpNav could use incorrect or uninitialized planet radii. A zero limb-message planet ID now preserves planetTarget; a supported nonzero ID updates it before the calculation. Unsupported IDs raise BasiliskError.

• On macOS, validating many native extensions could delay the first Basilisk import after a build. Message, core FSW, core simulation, MuJoCo, and OpenCV bindings now use fewer libraries to reduce this overhead. Python imports and recorder APIs are unchanged. Rebuilt libraries still require validation, so first imports can remain slower than subsequent runs.

• GitHub issue 1587: The vscmg case in benchmarks/dynamics/benchmark_state_effectors.py failed during initialization with two or more components because of left-handed gimbal frames. The affected axes now form right-handed frames, fixing the benchmark in the current version.

• Two-axis spinning-body default names could collide with single-axis state and property names once instance counters reached multiple digits. The two-axis names now separate the axis and instance numbers with _. Access these records through each effector’s public name fields.

• Empty reaction-wheel and thruster effectors remain usable with flat-state registration. They do not create zero-sized state records, and their device counts still become immutable after successful registration.

• Dynamics-manager references and callback-created state handles are borrowed. Keep the owning dynamics object or MuJoCo scene alive while using them. Replacing an integrator destroys the old method; reacquire the integrator property afterward. Python rejects reinstalling a previously transferred or borrowed integrator after replacement or owner destruction.

• GitHub issue 1581: The C debyeLength() utility could read beyond its lookup arrays for altitudes from 2,000 km through 30,000 km, producing undefined results such as NaN. The interval search now includes the final table endpoint and returns the intended constant value of 0.0396 m throughout this range. NaN altitudes could also trigger an out-of-bounds read; they now produce an error diagnostic and return NaN before interpolation.

• The deprecated Basilisk.simulation.spacecraftSystem module and its supporting effector APIs have been removed. Use C++ Module: spacecraft with C++ Module: constraintDynamicEffector for connected spacecraft; see scenarioConstrainedDynamics for a working example. API migration details are listed in the release notes. The supported prescribed-motion branches also no longer emit a missing-state warning when looking up an unused hub-attitude state during initialization.

• GitHub issue 1563: BSpline.approximate() could ignore the second and third components of the final-acceleration constraint by reading uninitialized constraint-vector entries. All three components now use the correct constraint row. This is fixed in the current version.

• GitHub issue 282: Passing the active integrator back to setIntegrator() could delete it and leave the dynamics object with a dangling pointer. The operation is now a no-op, and persistent integrator ownership uses std::unique_ptr. Python integrator attribute assignment now transfers ownership through the same setter. Explicitly disowning a newly constructed Python integrator before installation remains supported. Custom C++ dynamics classes should replace direct raw-pointer assignments to the owning member with setIntegrator(std::make_unique<IntegratorType>(this)) or transfer an existing unique_ptr with std::move; see Creating DynamicObject Basilisk Modules.

• GitHub issue 282: Synchronized dynamics could retain a dangling pointer after a secondary was destroyed, or leave a surviving secondary marked as synchronized after its primary was destroyed. Python connections now retain their supplied secondary objects, and native destruction removes synchronization links in either order. Repeated connections are harmless; invalid self, nested, or competing-primary connections now raise BasiliskError. Python calls through borrowed primary proxies are rejected before changing connections; use the owning primary object so retention survives temporary aliases. See Lifetime of Synchronized Objects.

• GitHub issue 282: Resetting simulation threads could clear process assignments while a worker was still using them, and shutdown requests used an unsynchronized flag. Worker ownership now guarantees stop and join before releasing thread state or changing assignments. requestStop() and the compatible killThread() now wake idle workers on the first stop request; repeated calls are harmless. Pool shutdown signals all workers before joining. See Reinitialization, ownership, and shutdown for configuration and C++ migration details.

• GitHub issue 282: Dynamically allocated output messages now use private std::unique_ptr storage, preserving the public message-vector interfaces. This fixes missing cleanup in the two-axis spinning-body effector, joint controllers, thruster on-time converter, and the nested wheel/thruster outputs of DataFileToViz. Partially constructed output collections are also cleaned up when allocation fails. The shared addOwnedMessage() helper rolls back each owner/view insertion if either append fails; earlier module configuration changes are not rolled back. See Vector of Output Messages for the ownership and reconfiguration contract.

• GitHub issue 282: Spacecraft-input configuration methods in the atmosphere, magnetic-field, wind, eclipse, location, charging, MSM, and formation-barycenter models could retain pointers to standalone Python messages after those messages were collected. These methods, along with Eclipse.addPlanetToModel() and EphemerisConverter.addSpiceInputMsg(), now retain each source through its native reader and release it on unsubscribe, replacement, or reader destruction. The same protection now covers power and data storage, transmitters, downlink handling, mapping instruments, simple-antenna and albedo planet inputs, articulated facets, thruster attached-body inputs, small-body navigation thruster inputs, and Vizard camera configuration messages. Pending and copied readers retain their sources until the last connected copy is released. Module-owned outputs still require their producing module to remain alive. See Retaining Sources in Configuration Methods.

• GitHub issue 282: SPICE scratch buffers could leak when spacecraft-name validation or allocation raised an exception. Fixed-size arrays and an automatically managed time-output buffer now guarantee cleanup. The internal SpiceInterface.spiceBuffer and charBufferSize fields are now private; custom code must remove direct access to them. Standard simulation configuration is unchanged. Time-output formats that leave insufficient buffer capacity now raise BasiliskError before calling SPICE.

• GitHub issue 282: Fuel tanks could keep dangling pointers to thruster effectors and fuel-slosh particles created in a local Python scope. addThrusterSet() and pushFuelSloshParticle() now retain their supplied Python objects until the tank is destroyed. Null connections, and dynamic-thruster connections made before setTankModel(), now raise BasiliskError. C++ callers must still keep borrowed effectors alive. See C++ Module: fuelTank.

• GitHub issue 281: The C and C++ template documentation now explains the implemented calculation, optional inputs, reset behavior, and runnable usage. General RST authoring examples previously embedded in C Module: cModuleTemplate are now in Module RST Documentation.

• GitHub issue 281: Draft module tests generated by makeDraftModule previously reported success without checking execution or outputs. Newly generated tests check scheduled call counts, output written status, and recording and write timestamps. Existing module tests must be updated manually; regenerating a draft replaces its folder.

• GitHub issue 281: makeDraftModule could generate invalid test imports for nested paths or paths without a trailing separator, change the caller’s working directory, and delete an existing module before rejecting an invalid specification. Generation now normalizes paths, preserves the working directory, validates inputs, and stages complete drafts before replacement. Failures raise Python exceptions.

• GitHub issue 281: The C and C++ module template fields dummy and dumVector are now named updateCounter and sampleConfigVector. Update Python assignments and logger field names accordingly. The C++ accessors are now setUpdateCounter(), getUpdateCounter(), setSampleConfigVector(), and getSampleConfigVector(); the old names are no longer available. Reset() still clears the counter and preserves the sample configuration vector, which is used for logging examples.

• GitHub issue 1573: Rust input MsgReader ports exposed is_linked but not whether the subscribed source had been written, when it was written, or which module wrote it. Readers now provide is_written, time_written in nanoseconds, and module_id, following the subscribed source header. A linked message that has never been published reports unwritten, time zero, and an error for the module ID. Output writers do not expose these queries.

• Incremental native builds could retain an old version in Basilisk.getBuildInfo() after docs/source/bskVersion.txt changed. CMake now tracks that file and reads the current source version instead of Conan’s cached version. Running ninja -j 12 in an existing build directory applies the fix and refreshes the metadata without a clean build.

• C++ Module: spacecraftLocation formed its Sun direction from the inertial origin and its viewing direction from the primary spacecraft center instead of the configured body-fixed location. Illumination and viewing angles for translated or offset locations are corrected in the current version (issue #864). NaN glareThreshold values are now rejected during initialization rather than silently bypassing glare rejection.

• GitHub issue 1393: The C++ Module: constraintDynamicEffector applied its constraint force and torque regardless of the device status message, which gated only the load filtering and the output message write. Commanding the effector off left its logged force at zero whereas the constraint kept acting on the dynamics. This is fixed in the current version.

Version 2.12.0 (September 21, 2026)

• Removed the deprecated Basilisk.architecture.cMsgCInterfacePy compatibility package. Replace from Basilisk.architecture import cMsgCInterfacePy with from Basilisk.architecture import messaging and change cMsgCInterfacePy. references to messaging.. C message wrappers remain available through messaging.

• GitHub issue 329: Scalar test comparators could accept NaN values or invalid tolerances. They now reject non-finite operands and non-finite or negative tolerances. The new EXPECT_NEAR_REL, EXPECT_VECTOR3_NEAR, and EXPECT_VECTOR3_NEAR_REL assertions apply these checks and provide comparison diagnostics. Relative comparisons use the first operand as the reference; a zero reference requires exact equality. The legacy v3IsEqual and v3IsEqualRel utility functions retain their existing behavior.

• GitHub issue 469: C++ Module: ExtPulsedTorque advanced its pulse on every dynamics evaluation, so intermediate integrator stages changed the pulse duration. It now evaluates the waveform from simulation time using the explicit pulseInterval in seconds. Set this interval to the desired duration of one pulse count when updating existing configurations. Resets preserve the time-zero phase.

• GitHub issue 469: C++ Module: constraintDynamicEffector kept derived gains unchanged after retuning and resetting. It now refreshes those gains from alpha and beta while preserving individual gains configured through their setters. Invalid setters and derived-gain overflow preserve the prior gains.

• GitHub issue 469: Range-only configuration checks accepted non-finite values in spinning-body, translation, hub, and stochastic effectors. The affected validators now reject non-finite scalar, vector, and matrix inputs, including in point-mass spacecraft initialization. Point-mass mode retains support for finite zero or singular inertia and checks its zero center offset component by component. Axis normalization preserves very large finite directions; translation validation runs before state registration. Stochastic setters preserve prior values on rejection, their coefficient calculations avoid intermediate overflow, and non-finite drift or diffusion raises BasiliskError before being stored.

• GitHub issue 469: Hinged-body, prescribed-motion, and slosh effectors accepted invalid masses, and hinged-body effectors accepted invalid hinge-frame rotation matrices. These configurations now raise BasiliskError before state registration and from Reset(), including for attached-only effectors. Prescribed-motion mass setters reject invalid input before replacing the prior value. Supported zero-mass configurations and depleted slosh states are preserved; dual-hinged bodies require a positive finite combined mass, and N-hinged chains require finite positive panel masses. Spherical-pendulum damping validation now also runs from Reset(). See the individual module documentation for the mass bounds.

• GitHub issue 469: C++ Module: extForceTorque could read uninitialized command buffers when an input was linked and dynamics ran before the effector’s scheduled Reset() or UpdateState(). All three command buffers now start at zero, including for effectors attached to a hub or appendage without task scheduling. Static loads remain available immediately; message commands are sampled by UpdateState().

• GitHub issue 515: Running conanfile.py from outside the repository could fail to find the Conan recipe or select a different recipe in the caller’s directory. The build subprocess now runs from the Basilisk repository root, while relative external-module paths remain relative to the caller’s directory.

• GitHub issue 469: Invalid effector dimensions could reach native array and vector accesses. Magnetic torque bar counts, thruster initial-state vectors, faceted SRP input vectors, and radiation-pressure lookup table lengths now receive validation before use. Reaction-wheel arrays and linked thruster command arrays also enforce their payload capacity. Invalid configurations raise BasiliskError from attachment, Reset(), or runtime consumption as appropriate. Thruster sets larger than the command payload remain supported when that input is unlinked. State thrusters and reaction wheels also reject device-count changes after state registration. Reaction wheels preserve each wheel’s jitter-angle state allocation. These checks protect dynamics accesses even for effectors that are not scheduled as task modules; Reset() does not resize their registered states.

• Rust-enabled macOS builds could mix the selected Xcode SDK with a newer Command Line Tools SDK, causing linker errors such as unknown architecture in system .tbd files. The Rust integration now removes Corrosion’s hard-coded Command Line Tools library directory and uses CMake’s selected SDK. Reconfiguring an existing build applies the fix without requiring a clean rebuild.

• C++ Module: vscmgStateEffector initialized derived inertias, masses, reference axes, and imbalance parameters only from its scheduled Reset(). An attached-only effector could therefore use uninitialized dynamics parameters. State registration now performs the same configuration initialization and validation. Zero-mass balanced and simple jitter devices retain support and no longer compute undefined mass fractions. Validation also rejects device arrays that exceed message capacity and non-finite motor settings or commands. Coupled dynamics now report invalid divisors through BasiliskError instead of producing non-finite derivatives. Gimbal friction smoothing now uses the gimbal ratio independently of the wheel ratio. Mixed balanced/jitter arrays now index the compact wheel-angle state correctly when publishing configuration messages.

• simHelpers.timeStringToGregorianUTCMsg() retained every returned epoch message for the lifetime of the process, causing memory growth during repeated simulation setup. The obsolete registry has been removed. Messages now remain alive while callers, subscribers, recorders, or payload views need them and can be garbage collected afterward. This resolves the remaining epoch-message retention discussed in GitHub issue 548.

• Python Message.read() and C++ message reader calls returned borrowed payloads without retaining their source. Reading a temporary message or ending a subscription could leave a payload pointing into freed memory. Each returned payload now retains its original source through a Python reference until the payload is released. Reference cycles created by caching a payload view on its source message can also be garbage collected.

• GitHub issue 571: Spinning-body lock and motor torque arrays index degrees of freedom within one module. Separate module instances require separate messages for independent commands; each OneDOF instance reads element [0]. The documentation now explains this mapping and corrects the lock-message examples. For C++ Module: spinningBodyNDOFStateEffector, chains with more than MAX_EFF_CNT bodies could read beyond a linked lock or motor torque payload. Initialization, reset, and input processing now reject these configurations with BasiliskError. Larger chains remain supported when neither array input is linked.

• GitHub issue 1542: macOS builds could emit a benign __common section alignment warning when linking C++ Module: simpleAntenna. The Python build script now builds cfitsio with -fno-common on non-Windows platforms and includes the flag in its Conan package ID so existing cached binaries are rebuilt. This is fixed in the current version.

• Incremental documentation builds now track transitive local includes, honor Sphinx Doxygen configuration overrides, and regenerate a project’s XML after an interrupted cache update. Local headers remain tracked with SEARCH_INCLUDES=NO, and environment-dependent Doxygen configuration bypasses XML cache reuse to prevent stale output. XML caches now follow the selected build directory so cleaning an alternate BUILDDIR removes its cache as well. Relative Doxygen input settings are resolved from docs/source, not the temporary cache directory, preventing missing includes, tag files, or input filters during generation. Headers found through that working directory and their transitive includes are tracked for cache invalidation, including when those headers are added or removed. Configuration option order is preserved for included settings and overrides. File-inclusion documentation commands bypass reuse, including in aliases and with preprocessing disabled. Projects using CITE_BIB_FILES also bypass reuse so bibliography edits cannot leave stale citations. Parallel Sphinx builds now retain XML dependency records from all workers, preventing stale API pages after header edits. Older saved Sphinx environments are reread once to restore those records.

• GitHub issue 1538: PyPI changed its download logging on August 24, 2026, to exclude metadata requests. The Usage Metrics collector filters identifiable non-distribution files, but older source records without filenames cannot be classified reliably. Historical download trends remain only partially comparable across this upstream change.

• GitHub issue 1538: Interrupted HTTP response reads could stop usage-metrics collection before saving data from the healthy source. The collector now retries these failures and, if retries are exhausted, saves available observations while marking the failed source’s retained data as stale.

• Configuration checks in several state and dynamic effectors ran only from Reset(), which the scheduler does not invoke unless the effector is separately added to a task. Attached-only effectors could therefore bypass validation. The affected effectors now perform the same checks from their guaranteed spacecraft initialization hooks, including the property-linking path used by branch-attached dynamic effectors. See Initialization and Configuration Validation for the initialization requirements when writing an effector.

• GitHub issue 1459: RetentionPolicy.addVariableLog() still called the removed SimBaseClass.AddVariableForLogging() and GetLogVariableData() methods, causing every Monte Carlo variable-retention request to fail with AttributeError. Variable retention now creates and reads the supported module logger directly.

• The C++ Module: nHingedRigidBodyStateEffector equations of motion are derived for a chain of identical panels, but the module accepted a per-panel mass and hinge to center of mass distance and integrated silently wrong dynamics when either varied along the chain. Initialization now rejects such a chain.

• The C++ Module: facetSRPDynamicEffector indexed its articulation angles by facet while building the list only from messages that had been written, so an incomplete read applied one facet’s angle to another. The facets now articulate only once every articulation message has been written.

• The C++ Module: facetSRPDynamicEffector walked its facet geometry lists by the count given to setNumFacets() rather than by the number of facets actually added, so a larger count read past the end of every list and a smaller one silently dropped facets. Initialization now rejects a mismatch.

• simIncludeThruster defaulted the segment argument of addToSpacecraftSubcomponent() to 0, but attachment segments are numbered from 1, so every parent effector rejected the call unless a segment was named. The default is now the segment attached to the hub.

• The C++ Module: linearTranslationNDOFStateEffector and the C++ Module: spinningBodyNDOFStateEffector allocated a state and a configuration log output message for every body added to the chain and freed neither, so each effector leaked both for the life of the process. This is fixed in the current version.

• The C++ Module: linearTranslationNDOFStateEffector built its translating body configuration log from a hub attitude cached at the previous integrator substep, so the logged body attitude lagged the hub attitude even though the body does not rotate relative to the hub. This is fixed in the current version.

• The C++ Module: linearTranslationNDOFStateEffector accepted a chain whose joint mass matrix is singular, most simply one whose outermost body was left at its default zero mass, and inverting it filled the spacecraft state with NaN. It also took an invalid rotation matrix or inertia tensor at face value and integrated silently wrong dynamics. Initialization now rejects all of these, and an empty chain.

• Every state effector acting as a parent published the inertial state of its attachment frame once per task step from its own UpdateState(). A child effector therefore evaluated its loads against kinematics a full task step old. These are now refreshed within the integration.

• State effectors wound their static effectorID counter back in the destructor, so destroying one effector made a later one reuse an identifier still held by a live effector. This is fixed in the current version, and the counter now only ever increases.

• The C++ Module: linearTranslationOneDOFStateEffector published two of its inertial properties incorrectly. The translating frame velocity omitted the hub’s inertial velocity entirely, and the translating frame angular velocity was rotated by the transpose of dcm_FB. This is fixed in the current version.

• The C++ Module: spinningBodyTwoDOFStateEffector applied an attached dynamic effector’s torque on the upper spinning body to the lower spinning body’s equation of motion with the wrong sign. This is fixed in the current version.

• The C++ Module: dualHingedRigidBodyStateEffector applied the second hinge’s motor torque to panel 2 without the equal and opposite reaction on panel 1. This is fixed in the current version.

• The C++ Module: dualHingedRigidBodyStateEffector computed panel 2’s inertial angular velocity with panel 1’s attitude and omitted the first hinge rate. This is fixed in the current version.

• The C++ Module: dualHingedRigidBodyStateEffector wrote its panel center-of-mass velocities into the panel configuration log without rotating the hub-relative terms into inertial components, so the logged panel velocities were wrong for any non-identity hub attitude. This is fixed in the current version.

• The C++ Module: hingedRigidBodyStateEffector built its published panel velocity and angular velocity from a hub angular velocity cached during Backsubstitution, so the logged values lagged the integrated state by a step. This is fixed in the current version.

• The C++ Module: hingedRigidBodyStateEffector added body-frame relative velocity terms directly onto the inertial hub velocity when forming both its logged velocities. This is fixed in the current version.

• C++ Module: vizInterface left its protobuf output stream open after the module was destroyed. On Windows, this could prevent saved Vizard data files from being removed until the Python process exited. The stream is now owned and closed automatically by the module. This is fixed in the current version.

• macOS builds with both opNav and vizInterface enabled could load separate static protobuf runtimes through OpenCV and C++ Module: vizInterface, causing an interpreter-shutdown crash after otherwise successful Python tests. On macOS, both modules now use the same shared protobuf runtime. This is fixed in the current version.

• hasBuildFeature("opNav") previously reflected only the core wheel’s build metadata, so it reported False after the separately distributed bsk-opnav wheel was installed. The query now aggregates capabilities from the core artifact and compatible installed optional Basilisk distributions. This is fixed in the current version.

• SWIG 4.4.0 caused Basilisk build failures in some Python 3.13+ source-build configurations. Basilisk now requires SWIG 4.4.1 or a newer supported 4.x release, which provides SWIG ABI 5 support for Basilisk and compatible extensions. If source builds fail with SWIG 4.4.0 or emit builtin type swigvarlink has no __module__ attribute warnings, upgrade to SWIG 4.4.1 or a newer supported 4.x release.

• Clean Conan builds now remove the configured build folder (dist3 by default) and Basilisk Numba cache artifacts, preventing generator conflicts and reuse of stale compiled Numba objects after API changes.

• BSK-1445: The documented Mars spherical-harmonics configuration in scenarioBasicOrbit requested degree 100 from a gravity file whose maximum degree/order is 80 and failed before simulation initialization. In addition, scenarioDragRendezvous loaded orientation-dependent tesseral terms when useJ2=True and useWind=False. Both examples now use zonal-only \(J_2\) gravity fields and run without requiring planet rotation. This is fixed in the current version.

• The deprecated --managePipEnvironment, --autoKey, --allOptPkg, --pyPkgCanary, and --examples source-build options have been removed. python conanfile.py now configures and builds the native project without modifying the Python environment; the updated source-install instructions install the Python requirements explicitly and create the editable Basilisk installation once per virtual environment.

• The C++ Module: sphericalPendulum fuel-slosh effector applied its viscous damping force without the pendulum moment arm, so an isotropic damping matrix D dissipated no rotational energy and an anisotropic D could add energy to the spacecraft. This is fixed in the current version.

• BSK-676: A stand-alone message that went out of scope in Python could be garbage collected while a C++ module input message or recorder still pointed into it, causing the reader to silently access freed memory. Subscribing a C++ ReadFunctor input message, calling Message.addSubscriber(), or calling Message.recorder() now keeps the source alive for the life of the reader or recorder, so messages created inside Python setup or helper functions no longer need to be manually retained. This is fixed in the current version.

• BSK-1461: The C Module: sunlineEKF, C Module: okeefeEKF, and C Module: sunlineSEKF state-update unit tests injected measurement noise using qObsVal as the standard deviation of numpy.random.normal, but qObsVal is a variance everywhere else in these filters (the measurement covariance is R = qObsVal * I). The injected noise was therefore sqrt(qObsVal) times too small, so the convergence tests ran at a fraction of the intended measurement noise. The tests now draw noise with sigma = sqrt(qObsVal) from a local seeded generator and check convergence against a noise-appropriate tolerance. This is fixed in the current version.

• BSK-1460: Setting only senNoiseStd on C++ Module: coarseSunSensor produced an unbounded random walk because the nominal error propagation matrix defaulted to identity while the negative default walkBounds disabled hard clipping. The propagation matrix now defaults to zero, so senNoiseStd produces independent white measurement noise. The Python setAMatrix() and getAMatrix() bindings now also accept and return the documented matrix representation without emitting an opaque-object memory-leak warning. This is fixed in the current version.

• BSK-1460: Setting senNoiseStd on C++ Module: magnetometer produced a random walk instead of the documented Gaussian measurement noise, and changing RNGSeed after construction did not change its random sequence. The default propagation matrix is now zero and the configured seed is applied during reset. This is fixed in the current version.

• BSK-1460: C++ Module: tempMeasurement propagated noise as a random walk and clipped it to \(\pm 10^{-15}\) degrees Celsius by default, instead of producing noise with the requested standard deviation. The default propagation matrix is now zero and hard clipping is disabled by default. This is fixed in the current version.

• BSK-1460: C++ Module: imuSensor used white noise for the accelerometer but a random walk for the gyro, and both noise models were initialized with the same random stream. Both propagation matrices now default to zero, and the accelerometer and gyro use distinct repeatable streams for every RNGSeed value, including zero. This is fixed in the current version.

• GitHub issue 1560: Normalizing GaussMarkov secondary seeds to 32 bits could make a secondary stream identical to its primary stream for some 64-bit input seeds on platforms with a 64-bit engine result type. Seed derivation now avoids both the truncated and full-width primary states while preserving existing primary seeding. This is fixed in the current version. Derived seeds and raw engine sequences now match across standard libraries. Replaying earlier simulations on builds with a 64-bit std::minstd_rand::result_type may change secondary sensor noise and fault outputs. Sensor outputs are still not guaranteed to match across standard libraries because distribution algorithms are implementation-defined.

• BSK-1460: Configuring C++ Module: starTracker PMatrix produced an unbounded attitude-error random walk by default. The propagation matrix now defaults to zero so PMatrix alone produces white Gaussian attitude errors; random-walk behavior remains explicitly configurable. This is fixed in the current version.

• A depleting C++ Module: fuelTank with attached fuel slosh particles reported the commanded total outflow as the tank component rate while the slosh effectors reported zero mass rate. The integrated component masses and aggregate outflow were correct, but the reported component derivatives did not match their integrated states. This is fixed in the current version.

• The C++ Module: fuelTank mass-depletion torque treated the tank-frame fuel COM and inertia derivative as body-frame quantities and dropped the tank offset, so a rotated (dcm_TB) or offset (r_TB_B) depleting tank applied a wrong or missing torque about the hub. This is fixed in the current version.

• The C++ Module: fuelTank emptying model computed the fuel COM and transverse inertia derivatives incorrectly except at the half-full condition, producing wrong high-fidelity depletion torques. The derivative equations and their finite-difference coverage are corrected in the current version.

• C++ Module: vizInterface leaked its protobuffer message on frames that did not reach a successful save-file write, including live-stream-only, broadcast-only, and camera-image early-return paths. It also leaked serialized buffers on broadcast-only frames, during re-serialization after removing the settings block, and while copying synchronization settings, as well as a heap allocation for every Vizard event reply. These leaks are fixed in the current version.

• C++ Module: vizInterface called google::protobuf::ShutdownProtobufLibrary() after qualifying successful save-file frames, releasing protobuf’s internal state while the module was still running. Other frames skipped the call through guards or early returns. This is fixed in the current version.

• C++ Module: spacecraft divided the center-of-mass-rate mass term by total mass twice, in both the reported centerOfMassPrimeSC property and the coupled-depletion equations of motion. The reported property also dropped the per-effector first moments \(\dot m_i\mathbf r_i\). This is fixed in the current version, though the coupled-depletion rate still omits those source moments by convention.

• C++ Module: MJSystemCoM reported mass-weighted material velocity rather than the time derivative of its center-of-mass position when individual MuJoCo body masses changed. This is fixed in the current version.

• Python Module: jointThrAllocation selected a multi-start optimization result by wrench-tracking error and could stop after the first sufficiently accurate result, rather than selecting the result with the lowest complete allocation cost. This is fixed in the current version: all successful optimizer results are evaluated and the minimum-cost result is selected.

Version 2.11.0 (July 7, 2026)

• BSK-422: Several SWIG-wrapped C++ members in simulation and FSW modules could emit swig/python detected a memory leak warnings when read from Python because their wrappers lacked visible destructors. Internal-only members are now private or hidden from Python, and public value-type members now include the required Eigen, STL, enum, and BSpline wrapper support. This is fixed in the current version.

• BSK-469: The C++ Module: hingedRigidBodyStateEffector and C++ Module: nHingedRigidBodyStateEffector constructors called Eigen’s static Identity() factory as a statement and discarded the result, so the default dcm_HB (and IPntS_S for the single hinged effector) held uninitialized memory instead of identity. Configurations that set these members explicitly (all shipped examples and tests do) were unaffected.

• BSK-469: The spacecraft hub properties were not validated, so a zero hub mass or a singular hub inertia tensor silently produced NaN states, and a negative hub mass silently reversed the translational response to applied forces. C++ Module: spacecraft and spacecraftSystem now verify on reset that mHub is strictly positive and IHubPntBc_B is symmetric positive definite. This is fixed in the current version.

• Extension-generated custom messages using bsk_generate_messages(GENERATE_C_INTERFACE) could fail to subscribe Python readers to C-interface output messages because generated bindings imported the built-in Basilisk.architecture.messaging package. Generated bindings now resolve peer message classes from their own module. This is fixed in the current version.

• BSK-1446: Several BSK modules deallocated output message objects created with C++ new by calling free(), and retained image buffers in C++ Module: camera and C++ Module: vizInterface were not released during module destruction. This could cause invalid deallocation behavior or memory leaks when these modules were destroyed. These cleanup paths now use C++ delete for the message objects and release the retained image buffers. This is fixed in the current version.

• BSK-788: Message recorders stored their recorded-message and time history in std::vector, so the recorder’s UpdateState incurred periodic reallocation-and-copy timing spikes at power-of-two record counts that grew with recording length, disrupting soft real-time and hardware-in-the-loop simulations. Recorders now store this history in std::deque. This is fixed in the current version.

• BSK-2026-001, BSK-2026-002, BSK-2026-003, and related fixed-buffer string handling and format-string logging issues are fixed in the current version.

• Additional build-helper command execution, temporary file cleanup, remote example download, and image buffer validation hardening is included in the current version.

• A Vizard noDisplay image request regression that caused OpNav scenarios to stop with a Vizard image request acknowledgement was not received error is fixed in the current version.

• The camera module now passes PNG encoding options as OpenCV key-value pairs, fixing OpNav image processing failures with OpenCV 4.13.

• The camera module filename input was only used to test filters and never published to imageOut. This is fixed so images loaded from filename now follow the same processing and publishing pipeline as images from imageInMsg.

• The MuJoCo dynamics wrapper now uses MuJoCo 3.7 element-name APIs, fixing builds after the MuJoCo 3.7 upgrade.

• Monte Carlo now applies nested dispersion paths and randomized RNGSeed modifications to the actual simulation objects.

• The C++ Module: linearTranslationNDOFStateEffector getter assertion no longer references the spinning-body-only degree-of-freedom counter, fixing source builds where that assertion is compiled. The related C++ Module: spinningBodyNDOFStateEffector getter assertion now rejects the first out-of-range index.

• SWIG 4.4.0 caused Basilisk build failures in some Python 3.13+ source-build configurations. Basilisk now requires SWIG 4.4.1 or a newer supported 4.x release, which provides SWIG ABI 5 support for Basilisk and compatible extensions. If source builds fail with SWIG 4.4.0 or emit builtin type swigvarlink has no __module__ attribute warnings, upgrade to SWIG 4.4.1 or a newer supported 4.x release.

• BSK-1387: C++ Module: linkBudget could compute excessive pointing loss for non-identity antenna attitudes because the inertial line-of-sight vector was transformed using the antenna-to-inertial DCM. This is fixed in the current version.

• BSK-1416 : Python Module: jointThrAllocation was using a static value for the vector between the hub center of mass (CoM) and system CoM. This caused the resulting thruster mapping to be incorrect for a given set of joint angles. This is fixed in the current version.

• BSK-1395: scenarioAttitudeConstrainedManeuver and scenarioAttitudeConstraintViolation pre-converted the reaction wheel maxSpeed to rad/s before passing it to rwFactory.create(), which expects Omega_max in RPM and applies the RPM-to-rad/s conversion internally. The resulting double conversion set the wheel saturation speed about an order of magnitude too low, and since the derived wheel inertia is maxMomentum / Omega_max it came out about an order of magnitude too high. This is fixed in the current version.

• BSK-968: C++ Module: spacecraft reported NaN for nonConservativeAccelpntB_B on the first integration step because the accumulated velocity change was divided by a zero time step. The value is now set to zero when the time step is zero, matching the existing omegaDot_BN_B guard. This is fixed in the current version.

• BSK-1107: A standalone message created inside a Python setup or helper function (for example a reference or vehicle-configuration message) can be garbage collected when that function returns, before the simulation runs. Consumers then read zeros or unwritten data. Retain such messages on the simulation object or another persistent scope so they survive for the life of the simulation. This affected scenarioRoboticArm and scenarioFlexiblePanel and is fixed in the current version.

• BSK-1410: user-facing utilities such as simIncludeGravBody and vizSupport imported the test-support module unitTestSupport, which imports the test-only pytest package at module load time. Scripts run against the Basilisk wheels (which do not ship pytest) therefore failed to import these utilities. The few general-purpose helpers those utilities needed have been moved into a new simHelpers module, so user-facing code no longer depends on unitTestSupport (or pytest) at all. This is fixed in the current version.

• BSK-548: simHelpers timeStringToGregorianUTCMsg leaked the SWIG-allocated doubleArray scratch buffer used to receive the str2et_c result (about 32 bytes per call). The buffer is now freed with delete_doubleArray. This is fixed in the current version.

• BSK-1353: C Module: sunlineSEKF and C Module: okeefeEKF computed the post-fit residual measMat * x using the full SKF_N_STATES width rather than each filter’s reduced state width, striding the measurement matrix across the wrong row width and over-reading the state-error vector. This corrupted the reported post-fit residuals during the convergence transient (the state and covariance estimates were unaffected). This is fixed in the current version.

• BSK-643: several simulation modules own dynamically-allocated output messages that are freed in their destructors but inherited the compiler-generated copy operations, so copying such a module shallow-copied the raw message pointers and both instances would free the same messages (double free). SysModel-derived modules are now non-copyable by default, while message recorders keep explicit copy-construction support. This is fixed in the current version.

Version 2.10.0 (April 2, 2026)

• When building from source on Python 3.13 using SWIG 4.4.0, a build failure may occur if pyLimitedAPI is set to an ABI lower than Python 3.13 (e.g., 0x03080000). SWIG 4.4.0 introduces a new C-API codepath for Python 3.13 that expects newer definition macros which are not present when targeting older abi3 compatibility. As such, when building Basilisk with Python 3.13 or above, we automatically default to using the newer cp313 ABI.

• The C++ Module: simpleAntenna module raises a warning for each of the following messages not being connected: sunInMsg, planetInMsg, sunEclipseInMsg, even for ground based antennas. These messages are not relevant for ground based antennas and the warning should therefore not be risen for an antenna on ground.

• If you install Basilisk via pip, note that the basilisk/supportData folder does not exist in your folder. Simulation script importing directly using a local file path to supportData will not work. Rather, pooch is being used to manage data which puts the data files into a cache folder on your system. See Importing External Data Sources on how to get a file data path and import it.

• The method loadGravFromFile() was hard-coded to load a 2nd order gravity field. This is fixed in current version.

• In C++ Module: reactionWheelStateEffector, mixed balanced and jitter wheel-model configurations could log theta to the wrong wheel output index. This is fixed in current version.

• In C++ Module: thrJointCompensation, the sign convention for the computed compensation torque was incorrect. This is fixed in current version.

Version 2.9.0

• The denton flux model API has changed. The module now uses the new data fetching API and thus relies on users passing in the correct support data location via configureDentonFiles. Previously, the module automatically searched for the data files in the supportData folder.

• When building from source on Python 3.13 using SWIG 4.4.0, a build failure may occur if pyLimitedAPI is set to an ABI lower than Python 3.13 (e.g., 0x03080000). SWIG 4.4.0 introduces a new C-API codepath for Python 3.13 that expects newer definition macros which are not present when targeting older abi3 compatibility. As such, when building Basilisk with Python 3.13 or above, we automatically default to using the newer cp313 ABI.

• C++ Module: gravityEffector had a typo where the total gravity potential contribution of the celestial bodies was not being computed properly. Fixed now.

• MJSite has an issue where the angular velocity that was being written into the stateOutMsg was in the inertial frame components not the body frame components. This is now fixed.

• C Module: locationPointing was calculating the value of omega_RN_B but not saving it to the attGuidOutMsg. This value is now being saved properly.

• The way body-fixed locations are added to Vizard data is changed. Now Vizard retains a copy of the list of locations and only incremental changes have to be sent using the vizSupport.changeLocation() method. If the script was directly manipulating the vizSupport list that functionality no longer works. If only addLocation() was being used and the location information was not live updated, no changes in the simulation script are required. To do live updates to location it is recommended to use vizSupport.changeLocation().

• The support file vizSupport is updated to only have enableUnityVisualization() check if C++ Module: vizInterface has been built or not. It is recommended that user scripts safe-guard their simulation usage of vizSupport function by checking that vizSupport.vizFound is true.

• In vizSupport, in the method setInstrumentGuiSetting(), corrected the spelling of showTransceiverFrustrum to be showTransceiverFrustum. The prior argument name has been deprecated and will be removed after October 11, 2026.

• For C++ Module: vizInterface.settings, changed the name of viewCameraConeHUD to viewCameraFrustrumHUD. Using the old settings name results in the setting not being applied.

• When building the Basilisk documentation with doxygen 1.15 or newer, warnings associated with unclosed quotes are treated as errors and cause the build to fail. Quotes are fixed now.

• C++ Module: spinningBodyOneDOFStateEffector and C++ Module: spinningBodyNDOFStateEffector both registered their state variables under the same names, resulting in one overwriting the other when both are added to the same simulation and producing a BSK_ERROR. State names are now made unique.

Version 2.8.0

• pip-based installation in editable mode using pip install -e . is not currently supported. Developers and users alike should continue to use python conanfile.py installation.

• The Reset() function in C Module: forceTorqueThrForceMapping was not working properly. This has been addressed in the current release.

• The reaction wheel configuration message was moved from C++ messages to the dynamics folder and renamed to RWConfigPayload. The reaction wheel factory was changed accordingly. Users that created the message on their own should now call reactionWheelStateEffector.RWConfigPayload instead of messaging.

• Simulations that previously logged to BSK_ERROR and expected to keep running successfully will now raise a BasiliskError exception and stop the simulation immediately.

• The output format when querying non-numeric types in message recorders has changed. The output used to be a numpy array of dictionaries with flattened data. Now, it’s a numpy array of the objects as if they were queried from the payload directly. Users relying on the legacy output format might experience code failures at runtime. The recommended approach is to adapt to the new format. If this is impossible at the time, Basilisk can be compiled with python conanfile.py --recorderPropertyRollback True to recover the legacy format (although a deprecation message will be raised). This build flag and the legacy output format are slated for complete removal in 2026/07.

Version 2.7.0

• pip-based installation in editable mode using pip install -e . is not currently supported. Developers and users alike should continue to use python conanfile.py installation.

• When using C++ wrapped sensor objects (CSS, thrusters, reaction wheels), Python references must be explicitly retained to prevent premature garbage collection. The recommended approach is to store these objects directly on your simulation object. For example:

  # Create and configure a CSS device
  cssDevice = coarseSunSensor.CoarseSunSensor()
  cssDevice.ModelTag = "css1"
  
  # Store it on the simulation object to keep it alive
  scSim.cssDevice = cssDevice  # Prevents garbage collection
  

  Alternatively, for multiple devices, you can use a list or registry:

  # Store multiple devices
  scSim.css_devices = []
  for i in range(4):
      cssDevice = coarseSunSensor.CoarseSunSensor()
      cssDevice.ModelTag = f"css{i}"
      scSim.css_devices.append(cssDevice)
  

  See specific documentation for:

  • C++ Module: coarseSunSensor

  • C++ Module: reactionWheelStateEffector

  • C++ Module: thrusterDynamicEffector

  For working examples, refer to these scenarios:

  • scenarioAttitudeFeedback

  • scenarioCSS

  Failure to retain references will cause segmentation faults when accessing collected objects.

Version 2.6.0

• pip-based installation in editable mode using pip install -e . is not currently supported. Developers and users alike should continue to use python conanfile.py installation.

• When using senNoiseStd() to set the sensor noise standard deviations in C++ Module: magnetometer and C++ Module: coarseSunSensor the value was being multiplied by 1.5 when creating the diagonal noise matrix. This 1.5x multiplier has now been removed. This is corrected in current release.

• SWIG wrapper does not fully support all array types in message payloads. This affects custom message payloads that use these types for array members. Workaround is to add them to swig_conly_data.i.

• A bug was fixed in the C++ Module: facetSRPDynamicEffector module. A transpose was required to be added to a dcm in order to correctly express rotated facet normals in the spacecraft body frame.

• The MtbEffector.py module was not being imported correctly in Python due to lack of swig_eigen.i include file in MtbEffector.i. This is fixed in the current release, however it remains unknown why the dynamics engine is re-swigged for every individual effector/dynamics related class.

• This release uses conan version 2.x which creates a new folder .conan2 in the home folder. Thus, the first time Basilisk is build the project dependencies will be downloaded again into .conan2

• If configuring and building Basilisk directly with conan install and build commands, the -if dist3/conan argument is no longer needed. The Basilisk install location is setup with conan 2 arguments inside conanfile.py.

• simIncludeGravBody set the moon radius in km, not meters, and was thus 1000x too small when visualized.

• In the python library RigidBodyKinematics the subMRP() routine didn’t compute the expected result if the denominator was small. This is now corrected.

• C++ Module: groundLocation was not respecting the case where maximumRange == -1.0 in the method checkInstrumentFOV.

• Sensor noise models were not being initialized correctly in sensor models such as C++ Module: magnetometer and C++ Module: simpleVoltEstimator modules. This is now fixed in the current release.

• Propagation matrices were private in the C++ Module: simpleVoltEstimator and C++ Module: starTracker modules. This is now fixed in the current release by the addition of public methods to set and get the propagation matrices.

Version 2.5.0

• pip-based installation in editable mode using pip install -e . is not currently supported. Developers and users alike should continue to use python conanfile.py installation.

• If the simIncludeRW python tool was provided a specific Js value, it was being falsely converted before being assigned. This is now corrected.

• If supportData/EphemerisData/de430.bsp is not present the current build system will download the file from JPL server. However, if the download is interrupted, then the next build will find the file and not attempt to re-download it. This is now fixed in the current version where the file is only stored in the supportData folder if the download was complete.

• C++ Module: vizInterface was not able to save to a binary data file. This is now fixed in the current release.

• C++ Module: vizInterface was not saving the Vizard settings to the binary file. Fixed now.

• Installing Basilisk 2.4.0 while packaging<22 is installed can lead to an incompatibility and raise a “TypeError: canonicalize_version() got an unexpected keyword argument strip_trailing_zero” error. Newer versions of Basilisk now upgrade packaging>=22 to solve this issue.

• simIncludeRW didn’t allow fCoulomb, fStatic and cViscous to be specified even if a prebuilt RW data set is used. This is corrected in the current release.

Version 2.4.0

• The fuel tank models have become classes and python simulation code using tank modules need to be updated. See C++ Module: fuelTank or scenarioFuelSlosh for further documentation.

• The CI test builds starting failing running the gtest unit test suite with the error CMake Error: Unknown argument: --gtest_output. The current release fixes this issue.

• There was an issue with the C++ Module: thrusterStateEffector such that its mass depletion rate was hard-coded to 100% for all firings. This is corrected in the current release.

• pip-based installation in editable mode using pip install -e . is not currently supported. Developers and users alike should continue to use python conanfile.py installation.

• The CI test builds starting failing running the gtest unit test suite with the error CMake Error: Unknown argument: --gtest_output. The current release fixes this issue.

• If the simIncludeRW python tool was provided a specific Js value, it was being falsely converted before being assigned.

Version 2.3.0

• A bug was introduced at 2.2.1 (2dc0a35) to the SimulationBaseClass AddModelToTask function when it was refactored to use the updated module variable logging. The bug manifests as no data being logged for a variable when there are more than one task, a module in each task, and the variable being logged is from a module assigned to a task added to a process after the first task has been added to a process.

• Doing a clean build on Windows appeared to complete, but when running python simulation scripts, errors came up about not finding Basilisk packages. The python version number checking on Windows had an issue that is now corrected in the current build.

• swig 4.2 was causing run-time errors with Basilisk. The latest version of Basilisk now added support for this version of swig.

• Basilisk no longer builds on Windows with the opNav flag turned on. The opencv related conan settings are updated in the current release to address this.

Version 2.2.1

• There was an issue with C++ Module: thrusterStateEffector where if there are multiple instances of the thruster state effector then the last effector will over-write all the state of the earlier thrusters. This is corrected in the current release.

• Doing a clean Basilisk build with opNav flag on fails building openCV. The conan install script is updated this is corrected in the current release.

• We found a slow memory leak if messages with arrays or vectors were accessed from python. The swig issue has now been fixed in the current release.

• The C++ Module: facetSRPDynamicEffector module was double counting a cosine term in the SRP force calculation. This is corrected in the current release.

• The C++ Module: facetDragDynamicEffector module was missing a negative sign in the drag torque calculation. This is corrected in the current release.

Version 2.2.0

• VizInterface has been updated to use 4.5.0 version of ZMQ library. Be sure to use Vizard 2.1.5 or newer.

Version 2.1.7

• The way to include effector bodies in Vizard has changed in this release.

• The streaming between vizInterface and Vizard was not reliable because of a ZMQ compatibility issue between the two code bases. BSK is reverting to using ZMQ 4.3.0 for now to avoid this issue.

• Building Basilisk with opNav mode was no longer working as a conan package dependency issue came up. This has been corrected in the new version by specifying xz_utils/5.4.0 in conanfile.py. Note that building with opNav now also appears to require conan>=1.59.0, but less than 2.0.0.

Version 2.1.6

• in C++ Module: boreAngCalc, the variable boreVecPoint is now called boreVec_Po.

Version 2.1.5

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

• C++ Module: hingedRigidBodyStateEffector and C++ Module: dualHingedRigidBodyStateEffector module inertial state outputs are relative to the central gravity body, not the inertial frame. This is now corrected.

• Adding an instrument camera to C++ Module: vizInterface has changed. See BSK Scripting Settings on how to use the new method addCamMsgToModule().

Version 2.1.4

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

• prior version had a bug in computer the latitude in PCPF2LLA() inside geodeticConversion. This is used in the specifyLocationPCPF() method inside C++ Module: groundLocation, and in C++ Module: msisAtmosphere and C++ Module: albedo.

• C++ Module: coarseSunSensor now receives in sensorList a list of CSS configuration state pointers, not a copy to the configuration structures. This allows these values to be changed on the fly from within python. However, the simulation code must ensure that the CSS configuration structures are retained in memory or a segmentation fault will ensue.

• How stand alone C-wrapped message objects are created in python has moved from cMsgCInterfacePy to messaging. Old scripts still using cMsgCInterfacePy still work as a link has been created to messaging. But, the use of cMsgCInterfacePy is no depreciated and code should be updated to using messaging instead.

• The use of custom message in the external modules folders is broke with the new build modification in this release. This is fixed in the latest release.

Version 2.1.3

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

• C++ Module: planetEphemeris was not computing the correct orientation, this is fixed in current release

• updated examples/OpNavScenarios/BSK_OpNav.py path to the Vizard binary. If you are calling Vizard 2.1+ from the python script, the Vizard binary name changed from Basilisk Vizard` to simply ``Vizard.

• using newer versions of Python, such as 3.9.13 or 3.10.5, running conanfile.py runs into errors and fails. This is now addressed in the next release. Upgrading pip to the newest version manually can resolve this issue as well.

Version 2.1.2

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

• conan version 1.44 is causing build issues because the way the source and build folders are set has changed. This is fixed in current version of Basilisk.

• building Basilisk from scratch with opNav turned on was failing because conan was not able to install opencv/4.1.1. In particular, the package jasper was now failing as a required argument is no longer supported. This is fixed in the current release by turning off this jasper requirement.

Version 2.1.1

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

• On windows when building with opNav mode on, the gettext library was not included with the conan software unless the version is 0.21, not 0.20.1. This dependency has been upgraded. This might require deleting the .conan folder in your home directory and re-installing all dependencies.

Version 2.1.0

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

• conan changed the default repos in version 1.40 onwards which broke the Basilisk installation. This is now corrected in the latest release. After pulling the latest code release, you’ll need to delete the .conan folder in your home directory to create a fresh copy. This only has to be done once.

• C Module: spacecraftReconfig has been changed to read in the spacecraft mass from an input message, not be set as a module variable

Version 2.0.7

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

• Over the summer of 2020 the conan repo wasn’t able to install opencv anymore. The current build fixes this issue and lets Basilisk be compiled with the opNav flag again.

Version 2.0.6

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 2.0.5

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 2.0.4

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 2.0.3

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 2.0.2

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

• On Windows, using Python 3.8 or higher resulted in Basilisk paths not being recognized due to a chance with how Python resolves paths on Windows. This is fixed in the next release.

Version 2.0.1

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 2.0.0

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.10

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.9

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.8

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.7

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.6

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.5

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.4

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.3

• On Windows the vizInterface and all opNav related modules is not properly linking. Thus, all associated modules, including saving to Vizard binaries, is not working in this version.

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.2

• On Linux and Windows the vizInterface and all opNav related modules is not properly linking. Thus, all associated modules, including saving to Vizard binaries, is not working in this version.

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found. The code compiles, but auto-completion etc. doesn’t work in that module.

Version 1.8.1

• When deleting .conan and doing a build with opNav set to true, the required dependencies can’t be found on the repo on the first install run. Running it again makes it work. This is fixed in the next release to run properly on the first try.

• If openCV is conan installed for Release only the Xcode would give false error messages that it can’t find the library. This is now fixed in the current release.

• In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found. The code compiles, but auto-completion etc. doesn’t work in that module.

• On Linux and Windows the vizInterface and all opNav related modules is not properly linking. Thus, all associated modules, including saving to Vizard binaries, is not working in this version.

Version 1.8.0

• The new conan based built system might need the conan cache folder .conan to be deleted and reset. This is typically in the user’s home folder. After this you need to re-run the conan setup commands:

  $ conan remote add conan-community https://api.bintray.com/conan/conan-community/conan
  $ conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan
  

• If running Windows the path to the Basilisk library destination folder must be set, see Setup On Windows.

• On Linux and Windows the vizInterface and all opNav related modules is not properly linking. Thus, all associated modules, including saving to Vizard binaries, is not working in this version.

• If running Windows, be sure to use pip install conan to get conan, and don’t download the binary installer, see Setup On Windows. The binary installer causes several issues with this new build system in that it contains its own copy of Python, and thus checking for required python packages does work.

• The new build system provides many speed improvements in doing a clean or partial build, but some small changes are required to update BSK python simulation scripts to be compatible with the new build system. These changes include:

  • In BSK python simulation scripts, BSK modules should be included using the indirect method. Thus:

    from Basilisk.fswAlgorithms.cModuleTemplate import cModuleTemplate
    

    becomes:

    from Basilisk.fswAlgorithms import cModuleTemplate
    

  • The pyswice package is now imported from topLevelModule. Thus:

    from Basilisk import pyswice
    

    becomes:

    from Basilisk.topLevelModules import pyswice
    

  • The support file pyswice_ck_utilities.py has become a regular suppoort file in src/utiliites. Thus, it is imported using:

    import Basilisk.pyswice.pyswice_ck_utilities
    

  • Similarly, pyswice_spk_utilities.py has moved to the utilities folder. To include spkRead function replace:

    from Basilisk.pyswice.pyswice_spk_utilities import spkRead
    

    with:

    from Basilisk.utilities.pyswice_spk_utilities import spkRead
    

  • To include loadGravFromFileToList function replace:

    from Basilisk.simulation.gravityEffector.gravCoeffOps import loadGravFromFileToList
    

    with:

    from Basilisk.simulation.gravityEffector import loadGravFromFileToList
    

• If you have written custom BSK modules outside of the BSK distribution, the swig *.i files and some code files will need to be adjusted as follows:

  • To include the swig_common_model.i file, replace:

    %include "swig_common_model.i"
    

    with:

    %pythoncode %{
    from Basilisk.simulation.swig_common_model import *
    %}
    

  • If Eigen variables are being swig’d, then import:

    %include "swig_eigen.i"
    

  • To swig C arrays of variables, then import:

    %include "swig_conly_data.i"
    

  • To provide support of C++ std::string types, then import:

    %include "std_string.i"
    

  • To provide support of C++ std::vector class, then import:

    %include "std_vector.i"
    

• The files in _GeneralModuleFiles folders are now built into a separate library with the parent folders name plus Lib. This means in the IDE like Xcode and Visual Studio the code in _GeneralModuleFiles is shown in a folder with this library name. Thus, for example, code in src/simulation/environment/_GeneralModuleFiles are shown in the IDE folder environmentLib within the environment parent folder. This keeps the BSK folders cleaner and with less duplicated code being displayed.

• A new python package dependency is Pillow. This is needed for the test scripts for C++ Module: camera to run.

• In Xcode the build will complain that it can’t find the <Eigen/Dense> library. The code compiles ok. The work around this conan issue is to run the build twice, once for Debug and once for Release. At that point it can be run just once.

Version 1.7.5

• C++ Module: groundLocation was not converting between the planet and inertial frame correctly. This is now fixed in the later releases.

Version 1.7.4

• None

Version 1.7.3

• On Windows Basilisk didn’t compile due to missing math #define delaration in geodeticConversion.cpp/h. This is fixed in the latest release.

Version 1.7.2

• None

Version 1.7.1

• None

Version 1.7.0

• None

Version 1.6.0

• None

Version 1.5.1

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

Version 1.5.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• Here the reaction wheel dynamics have been modified such that the RW state output message is no longer hard-coded to rw_config_0_data, etc. Rather, now the ModelTag string is pre-pended to make this output msg name unique with. Any scripts that is logging this RW state message will have to be updated. The reason for this change is to allow multiple spacecraft to have RW devices and unique RW state messages.

• There was an issue doing a clean compile using Python 2 which is addressed in the next version

• test_reactionWheelStateEffector_integrated didn’t run on Python 2, this is fixed in the next version.

Version 1.4.2

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

Version 1.4.1

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• We ran into issues compiling on Linux where libsodium and conan were not compiling properly This is fixed in the next point release.

Version 1.4.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• BSK_PRINT has been replaced within Basilisk modules using bskLogging (for C++) and _bskLog (for C).

• WINDOWS ONLY: there appears to be an issue compiling vizInterface with the new bskLog method on Windows. We are working a point release that will fix this.

Version 1.3.2

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

Version 1.3.1

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

Version 1.3.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

Version 1.2.1

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

Version 1.2.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• The magnetometer unit tests don’t pass on all platforms. This is corrected in the next release.

Version 1.1.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• the unit tests of the magnetometer module don’t pass on all operating systems as the test tolerances are too tight. This is resolved in the next release.

Version 1.0.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• Swig version 4 was released over the summer. This version is not compatible with our current Basilisk software. Be sure to install swig version 3.0.12.

Version 0.9.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• Swig version 4 was released over the summer. This version is not compatible with our current Basilisk software. Be sure to install swig version 3.0.12.

Version 0.8.1

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• Swig version 4 was released over the summer. This version is not compatible with our current Basilisk software. Be sure to install swig version 3.0.12.

Version 0.8.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• Swig version 4 was released over the summer. This version is not compatible with our current Basilisk software. Be sure to install swig version 3.0.12.

Version 0.7.2

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• The python pandas package is now required to run BSK. The installation instructions have been updated to reflect this.

• Swig version 4 was released over the summer. This version is not compatible with our current Basilisk software. Be sure to install swig version 3.0.12.

Version 0.7.1

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• The python pandas package is now required to run BSK. The installation instructions have been updated to reflect this.

Version 0.7.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• The python pandas package is now required to run BSK. The installation instructions have been updated to reflect this.

Version 0.6.2

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• The enableUnityViz python function how has different inputs. Earlier python scripts must be updated. See the scenarios for examples. The arguments are now provided as optional keywords.

Version 0.6.1

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• This version of Basilisk no longer support the ASIO module that communicated with the Qt-based visualization as the BOOST library has been removed. This visualization has been replaced with the new Vizard visualization.

• The thrMomentumDumping now reads in a 2nd required input message to determine if a new dumping sequence is requested.

Version 0.6.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

Version 0.5.1

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

Version 0.5.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• the exponentialAtmosphere module has been replaced with a module based on the new atmospheric density base class. BSK simulations that used the older module must update to use the new module. The module unit test scripts illustrate how to use this module, and the module PDF documentation discusses this as well. The dragEffector integrated test is also updated to make use of the new module

• The MRP_Feedback() has the control vector domega0 removed and keeps this term now as a permanent zero vector. Any code that was setting this needs to be updated to not set this parameter anymore.

Version 0.4.1

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• The numpy python package can’t be the current version 1.16.x as this causes some incompatibilities and massive amounts of depreciated warnings. These warnings are not related to BSK python code, but other support code. Thus, for now be sure to install version 1.15.14 of numpy.

Version 0.4.0

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• Version 4.x.x and higher of pytest works again with Basilisk. You are free to install the latest version of pytest.

• As we are now using the conan package management system, you can’t double the the Cmake GUI application. Instead, you must either launch the Cmake GUI application from the command line, or run CMake from the command line directly. See the platform specific Basilisk installation instructions.

• The numpy python package can’t be the current version 1.16.x as this causes some incompatibilities and massive amounts of depreciated warnings. These warnings are not related to BSK python code, but other support code. Thus, for now be sure to install version 1.15.14 of numpy.

Version 0.3.3

• WINDOWS ONLY: Windows users cannot currently run pytest directly on Basilisk src/ directory (there will be non-resolved python path issues that will result in erroneous ImportErrors). Instead, to verify proper installation of Basilisk, windows users must enter the specific subdirectory they are attempting to test, only then to run pytest. This should result in appropriate behavior. Right now there is no known solution to this issue.

• The latest version of pytest (version 3.7.1) has a conflict with the RadiationPressure module unit test. We are still investigating. In the meantime, using pytest version 3.6.1 is working correctly.