.. _bskKnownIssues: Basilisk Known Issues ===================== .. caution:: The use of ``cMsgCInterfacePy`` is depreciated. Use ``messaging`` instead. Version |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. - 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: .. code-block:: python :linenos: # 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: .. code-block:: python :linenos: # 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: - :ref:`coarsesunsensor` - :ref:`reactionWheelStateEffector` - :ref:`thrusterDynamicEffector` For working examples, refer to these scenarios: - :ref:`scenarioAttitudeFeedback` - :ref:`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 :ref:`magnetometer` and :ref:`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 :ref:`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``. - :ref:`simIncludeGravBody` set the moon radius in km, not meters, and was thus 1000x too small when visualized. - In the python library :ref:`RigidBodyKinematics` the ``subMRP()`` routine didn't compute the expected result if the denominator was small. This is now corrected. - :ref:`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 :ref:`magnetometer` and :ref:`simpleVoltEstimator` modules. This is now fixed in the current release. - Propagation matrices were private in the :ref:`simpleVoltEstimator` and :ref:`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 :ref:`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. - :ref:`vizInterface` was not able to save to a binary data file. This is now fixed in the current release. - :ref:`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. - :ref:`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 :ref:`fueltank` or :ref:`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 :ref:`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 :ref:`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 :ref:`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 :ref:`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 :ref:`facetSRPDynamicEffector` module was double counting a cosine term in the SRP force calculation. This is corrected in the current release. - The :ref:`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 :ref:`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. - :ref:`hingedRigidBodyStateEffector` and :ref:`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 :ref:`vizInterface` has changed. See :ref:`vizardSettings` 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 :ref:`geodeticConversion`. This is used in the ``specifyLocationPCPF()`` method inside :ref:`groundLocation`, and in :ref:`msisAtmosphere` and :ref:`albedo`. - :ref:`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. - :ref:`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. - :ref:`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 :ref:`installWindows`. - 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 :ref:`installWindows`. 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 :ref:`camera` to run. - In Xcode the build will complain that it can't find the ```` 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** - :ref:`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 - :ref:`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 :ref:`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** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
**Version 0.9.0** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
**Version 0.8.1** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
**Version 0.8.0** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
**Version 0.7.2** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • The python pandas package is now required to run BSK. The installation instructions have been updated to reflect this. .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
**Version 0.7.1** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • The python pandas package is now required to run BSK. The installation instructions have been updated to reflect this. .. raw:: html
    • .. raw:: html
**Version 0.7.0** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • The python pandas package is now required to run BSK. The installation instructions have been updated to reflect this. .. raw:: html
    • .. raw:: html
**Version 0.6.2** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
**Version 0.6.1** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • The ``thrMomentumDumping`` now reads in a 2nd required input message to determine if a new dumping sequence is requested. .. raw:: html
    • .. raw:: html
**Version 0.6.0** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
**Version 0.5.1** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
**Version 0.5.0** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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 .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
**Version 0.4.1** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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``. .. raw:: html
    • .. raw:: html
**Version 0.4.0** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • Version 4.x.x and higher of pytest works again with Basilisk. You are free to install the latest version of pytest. .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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``. .. raw:: html
    • .. raw:: html
**Version 0.3.3** .. raw:: html
    .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html
  • 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. .. raw:: html
    • .. raw:: html