Version 2.0 Release Notes
Version 2.0.7
new C Module: forceTorqueThrForceMapping to map commanded forces and torques to a set of thrusters
updated Vizard documentation on the setting flags
orbitLinesOnandtrueTrajectoryLinesOnadded power and fuel tank modules to the BSK_MultiSatDynamics class.
improved the DV calculation of the spacecraft state output message by integrating the gravitational acceleration using the current integration scheme rather than using a first order approximation.
updated install script to be able to have
conaninstallopencvagain. Something changed with theconanrepo that broke this.updated BSK install instructions on the M1 Apple Silicon platform as Basiliks can now run natively
Version 2.0.6
updated C++ Module: vizInterface to support Vizard 1.9.1 and the ability to visualize generic sensor types and antenna communication status
updated C++ Module: ephemerisConverter to also convert the planet orientation states, not just the translational states
added a C++ Module: planetNav module that adds noisy to planet ephemeris, similar to simpleNav.
created a new device command status message DeviceCmdMsgPayload and updated C Module: simpleInstrumentController, C++ Module: simpleInstrument and C++ Module: spaceToGroundTransmitter to make use of it.
added C Module: attRefCorrection to adjust the reference attitude by a fixed rotation
added scenarioAttitudePrescribed to illustrate how to prescribe the spacecraft orientation
added new modules C Module: mtbFeedforward, C Module: mtbMomentumManagementSimple, C Module: dipoleMapping and C Module: torque2Dipole which are using in combination to achieve MTB based RW momentum dumping.
added a new magnetic RW momentum dumping example in scenarioMtbMomentumManagementSimple which illustrates using the above new MTB related modules to change the momentum, as well as drive the nominal momentum to a desired value using C Module: rwNullSpace.
created a new architecture based on
BskSimcalledMultiSatBskSim. It exploits the new messaging system to create a simulation with any number of spacecraft in a highly modular way. It allows for the addition of homogeneous or heterogeneous satellites without having to hard code their properties into a single dynamics or FSW script. It will be a foundation to test the upcoming multithreading capabilities of Basilisk.added three example scenarios that showcase this new architecture. See scenario_BasicOrbitMultiSat, scenario_AttGuidMultiSat and scenario_StationKeepingMultiSat.
added a new FSW module C++ Module: formationBarycenter. It computes the barycenter’s position and velocity of a swarm of satellites. This barycenter can be either computed with cartesian coordinates (usual mass-weighted average), or using orbital elements weighted average. Will be useful for spacecraft formations defined around the barycenter of the swarm and not a chief spacecraft.
enhanced C Module: locationPointing to support the target input msg being either a location message or an ephemeris message
updated install notes to ensure Linux python3 developer libraries are installed, and to ensure that
wheelpackage is installed along withconancreated C++ Module: smallBodyNavEKF to simulate autonomous navigation in proximity of a small body
added a AttRefMsgPayload output message to the C Module: locationPointing module.
added C++ Module with C-Wrapped Output Message to the section on learning how to create BSK modules
updated C Module: locationPointing to support 3D rate damping as an option
Version 2.0.5
fixed issue in C++ Module: waypointReference to interpolate between waypoint
nand shadow set of waypointn+1when these are described by opposite MRP sets. Updated documentation and corrected typos in scenarioAttitudeConstraintViolation.Added C Module: hillStateConverter and C Module: hillToAttRef modules for formation flight navigation and attitude-driven differential drag
Added representative scenario scenarioDragRendezvous demonstrating attitude-driven differential drag formation flight
Added new scenario scenarioDragSensitivity showing how to do a differential drag spacecraft control sensitivity analysis
updated C Module: celestialTwoBodyPoint to account for a case where the celestial objects are in opposite directions
replaced
acos()andasin()withsafeAcos()andsafeAsin()which ensure that arguments are clipped to be within and including -1 and 1updated C++ Module: dataFileToViz to allow the
Reset()method to be called multiple times. If a data file was already opened, then it is closed before the next data file is opened.updated C++ Module: groundLocation to also output SEZ coordinates, as well as range, azimuth, elevation, south, east and zenith coordinate rates. These coordinates are always computed regardless if a spacecraft is visible to the target. Check the
hasAccessmessage variable to see if the spacecraft is visible.updated the OpNav examples script to set a black sky background in the Vizard camera images
added a new Python method
isSubscribedTo()to query if the input and output messages between two modules are connectedupdated C++ Module: gravityEffector documentation to properly pull in the RST documentation and link to the PDF describing the gravity models
updated
setAllButCurrentEventActivitymethod in SimulationBaseClass to work with multiple satellites. We can now add an index at the end of each event name that guarantees only events with the same index are affected. TheuseIndexflag must be set toTrue.added new magnetic torque bar effector in C++ Module: MtbEffector
added new FSW module to control the RW momentum using MTBs in C Module: mtbMomentumManagement
new tutorial example script scenarioMtbMomentumManagement
updated C Module: rwNullSpace to have an optional input message of desired RW speeds. These desired values default to zero so the module retains the earlier behavior if this optional input message is not connected.
added two lines in C++ Module: waypointReference to normalize the attitude quaternion that is read from file.
Version 2.0.4
updated C++ Module: spacecraft
Reset()method to write all spacecraft and effector state output messages with their initial values. This way these output messages are correct as already as calling theInitializeSimulation()method.fixed an issue that could prevent
.subscribeTofrom a C++ to C wrapped message object to not function properly.new C Module: simpleInstrumentController that sends an imaging command to a C++ Module: simpleInstrument if the attitude error and access to a C++ Module: groundLocation module are within requirements.
new scenarioGroundLocationImaging example script that demonstrates the aforementioned module integrated into a full on-board data system.
new C Module: etSphericalControl module that controls the relative motion of the Electrostatic Tug
new scenarioDebrisReorbitET example script that demonstrates using the Electrostatic Tug and the Multi-Sphere Method
updated C++ Module: groundLocation to always compute the elevation, range and azimuth information, even if the satellite does not have access. The output message variable
hasAccessprovides access information.added scripting support for Vizard 1.8.4
updated scenarioGroundLocationImaging to demonstrate the use of the new
vizSupport.createTargetLine()method
Version 2.0.3
new integrated scenario in scenarioAttitudeConstraintViolation. Shows how to use the C++ Module: boreAngCalc to display keep-in and keep-out constraint violations while performing slew maneuvers.
new C Module: locationPointing module to do 2-axis attitude control which aligns a body-fixed vector to a desired inertial location
new scenarioAttLocPoint example script how to point a spacecraft body axis towards Boulder
new integrated scenario in scenarioAttitudeConstraintViolation. Shows how to use the C++ Module: boreAngCalc to display keep-in and keep-out constraint violations while performing slew maneuvers.
updated C Module: inertial3DSpin to make the attitude input message optional, updated documentation to be RST only and more descriptive of the associated math, and changed the module variable
omega_spintoomega_RR0_R0enables the message
recorder()module to function if the message structure contains structures itself.make the build system compatible with Python 3.8 and higher on Windows
fixed custom RW support method in
simIncludeRW.pyfixed new C++20 related compiler warnings
Version 2.0.2
new waypoint reference module in C++ Module: waypointReference. It can be used to read an attitude maneuver from a set of waypoints on a text file, likely generated outside Basilisk.
updated C++ Module: gravityEffector to allow the planet message module (
spiceInterfaceorplanetEphemeris) to be called either before or after thespacecraftmodule update is calledFix a range of long-standing HTML Documentation build warnings and issues
Renamed the messages
CirclesOpNavMsgPayloadtoOpNavCirclesMsgPayloadandOpNavLimbMsgPayloadtoOpNavLimbMsgPayloadto avoid sphinx naming conflictsunified the identical
ukfUtilities.c/hfiles inattDeterminationandopticalNavigationfolders intoarchitecture/utilitiesadded a new RW encoder simulation module C++ Module: encoder
Fixed a bug in the onboardDataHandling module that allowed for data that did not exist to be downlinked
changed default behavior of
python3 conanfile.pyto automatically compile the Basilisk project. This was a common stumbling point for new users. The build flag--buildProjectcan be used to enable automatic compiling or not. For developers making new code this should likely be set toFalsewhen configuring the project.Fixed a bug in SimulationBaseClass that prevented creating an event with multiple conditions
added
ShowExecutionOrder()method to SimulationBaseClass to print to the terminal the order that the process, tasks and modules are executed.added
ShowExecutionFigure()method to SimulationBaseClass to create a figure illustration the execution order.added a new Seeing the Order of Process, Task and Module Execution web page on how to visualize the BSK process, task and module execution
added new
bskSimexample scenario showing how to alternate between flight modes in scenario_AttModesprovide scripting support for Vizard 1.8.2 release
Version 2.0.1
Added the ability to clear the data of a message recorder using
.clear()Fixed a rare issue where RW data didn’t stick
Fixed an issue subscribing to a C++ wrapped message object from python
Cleaned up documentation on using datashaders and bokeh to interactively plot large simulation data sets. The script
scenarioAnalyzeMonteCarlois updated to discuss the particular challenges in running this datashader example of plotting data.enable Monte Carlo
pytesttest scripts to run on macOS if Python 3.9 or higher is usedenable opNav scenario
pytesttest scripts to be tested bypytestif the build flag--opNavis set to true and the path to Vizard application is set in BSK_OpNav.fixed an issue that prevented subscribing to a C++ msg from python
moved C Module: cModuleTemplate and C++ Module: cppModuleTemplate to a common folder
src/moduleTemplates. The associated HTML documentation now appears inside theDocumentationtab undermoduleTemplates.added the
src/utilities/makeDraftModule.pyscript that is able to create a draft module template givenmodule name
module description
module location
list of module input or output messages containing
message variable name
message payload definition
message description
message type (ie.
CorC++)
The script then generates either a C or C++ module folder that contains the elemental
*.c/cpp,*.h,*.icode which compiles into a functioning prototype module. Also included are the module*.rstfile which provides the basic description and message table (including hyperlinks to message payload type and message description), as well as a functioning python unit test that loads the module, connects zero’d input messages and sets up output message recorders. The coder can then take this draft module code and modify to achieve the desired functionality. The page moduleTemplates discusses how to use it and provides to 2 sample auto-generated modules that get created insidesrc/moduleTemplateswithpython conanfile.py.new thermal motor module in C++ Module: motorThermal. It it be used to simulate the temperature of a RW motor.
Version 2.0.0
New message system with strong type checking. You now get a much simpler method to create message objects, how to connect them within python, create stand-alone messages in python, etc. If you engage with a message of the wrong type you get immediate compiler warnings.
New C++ based message recording system that is much faster than the older python based message logging
New messaging recording now stores the message data separately from the time a message was recorded and the time the message was written
Removed the arbitrary distinction between
FSW,SIMandINTmessages. All messages are now available to all modulesBoth C and C++ based message interfaces are now auto-generated when running
python3 conanfile.pycommandNew ability to create zero’d message structures in the modules
Seamless message subscribing in Python across all modules types (C, C++ or Python)
New generic RW device type in simIncludeRW and updated the support library to work with BSK2
Updated simIncludeGravBody to work with BSK2. If needed the C++ Module: spiceInterface and EpochMsgPayload message is created within the gravity factory class.
Updated simIncludeThruster to work with BSK2
Updated fswSetupRW to work with BSK2
Updated fswSetupThrusters to work with BSK2
Update Basilisk module documentation that shows all input and output message variables, their type and explanation
Cleaned up the Basilisk src folder layout by moving all Basilisk architecture support files to src/architecture. This impacts some include statements
Made the C/C++
#includestatements all relative to src to make it easier to find the associated files in the source codeUpdated message names to now all comply with the Basilisk message naming convention.
Updated vizSupport to work with BSK2. It is now much easier to include RW, thruster and CSS devices. Further, the simulation gravity bodies don’t have to be explicitly provided to the
vizSupport.enableUnityVisualization()method. Rather, these are pulled from the spacecraft object directly.C++ Module: reactionWheelStateEffector is updated where the list of RW configuration parameters are now linked from python, not copied. As a result it is now possible to stop the simulation and change RW parameters on the fly, emulating a failure with a physical change in the RW mechanics.
changed the output message type of C++ Module: magnetometer to be compatible with C Module: tamComm
Created several instructional pages in the Quick-Start documentation folder. The examples folder has moved to the Quick-Start guide as well. The new quick start guide now discusses
how to write Basilisk python simulation scripts
how to write C++, C and Python modules
Added installation instructions to run Basilisk on a computer with the Apple M1 processor
added C++ Module: spacecraftLocation module to allow checking for satellite to satellite line-of-sight access
made
maximumRangean optional variable in C++ Module: groundLocationrenamed
spacecraftDynamicsto C++ Module: spacecraftSystem, and renamed the associatedspacecrafttospacecraftUnit().renamed
spacecraftPlus()to be now simply C++ Module: spacecraftrenamed the spacecraftPlus associated messages to SCStatesMsgPayload and SCMassPropsMsgPayload
renamed
fswModuleTemplate()to be C Module: cModuleTemplate. This makes this naming consistent with the new C++ Module: cppModuleTemplate.renamed rwMotorVoltageInterface to C++ Module: motorVoltageInterface. This motor model can be used for both RW and hinged panel devices.
added support to creating custom gravity bodies to simIncludeGravBody. Including support to have custom gravity bodies shown in Vizard as well. The example script scenarioCustomGravBody provides an illustration of this functionality.