avslab / basilisk Goto Github PK
View Code? Open in Web Editor NEWAstrodynamics simulation framework
Home Page: https://hanspeterschaub.info/basilisk
License: ISC License
Astrodynamics simulation framework
Home Page: https://hanspeterschaub.info/basilisk
License: ISC License
Provide Basilisk support for Vizard 2.1.3.
The new spinning body BSK effector module is using a new state msg definition that is identical to the hingedRigidBodyStateMsg
message. This break compatibility with other modules using this message. We need to delete that new message type and use consistently the same message.
We are currently integrating on the body frame acceleration, rddot_BN_N, which incorporates the additional acceleration terms when point B is not coincident with point C. All of this technically works mathematically, but it does not consider the integration errors that are affected by rounding errors on large orbit numbers combined with the higher frequency dynamics of the rotation motion of the spacecraft. Essentially, it is a bad design because bottom line we should be integrating on rddot_CN_N for orbits and then backing out the body frame states.
I've been trying to containerize Basilisk for some other work I'm doing. I eventually found that there was a line in conanfile.py
that was unable to execute in a docker container.
docker build
was failing on this line: https://github.com/AVSLab/basilisk/blob/develop/conanfile.py#L292
I added a solution here that uses a --docker
flag to slightly alter that line so it's compatible within a container.
Solution is here: Jmiceli17@ffcb586
Here is a snippet of the dockerfile
that I have been using:
FROM ubuntu:20.04 AS basilisk-deps
# Install all Basilisk requirements & dependencies
RUN apt-get update && \
DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
git \
git-lfs \
build-essential \
python3 \
python3-setuptools \
python3-dev \
python3-tk \
python3-pip \
python3-venv \
swig && \
rm -rf /var/lib/apt/lists/* && \
update-alternatives --install /usr/bin/python python /usr/bin/python3 10
# Initialize git lfs
RUN git lfs install
# Build/install the Basilisk sim
FROM basilisk-deps AS basilisk
# lfs clone basilisk to ensure all large files are cloned
RUN mkdir -p /opt/basilisk && \
git lfs clone -b develop https://github.com/Jmiceli17/basilisk.git /opt/basilisk
# TODO: use master branch from AVS github once the basilisk team gets it updated
WORKDIR /opt/basilisk
RUN pip3 install --upgrade setuptools
# Install dependencies for Basilisk
RUN pip3 install --no-input \
-U pip \
wheel \
conan==1.56.0 \
cmake \
pandas \
matplotlib \
pytest \
parse==1.18.0 \
numpy \
protobuf==3.20.* \
sphinx==5.3.0 \
breathe \
sphinx_rtd_theme==0.5.1 \
recommonmark \
pytest-xdist \
pytest-html \
docutils \
grpcio
# Create default conan profile and configure it
RUN conan profile new default --detect && \
conan profile update settings.compiler.libcxx=libstdc++11 default && \
conan profile update env.CC=gcc default && \
conan profile update env.CONAN_CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY default && \
conan profile update env.CONAN_CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY default && \
conan profile update env.CONAN_CMAKE_FIND_ROOT_PATH_MODE_PACKAGE=BOTH default && \
conan profile update env.CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER default && \
conan profile update env.CXX=g++ default
ENV CONAN_NON_INTERACTIVE=1
# Build the Basilisk simulation framework
RUN python3 ./conanfile.py --vizInterface=True --allOptPkg --docker
Improve Vizard's display of multi-body spacecraft (i.e. parent spacecraft + effector(s)) to remove unnecessary display components and improve ease of use of GUI menus and panels.
Refinements to Vizard's display will include:
Create a configureable body rate limit such that the simpleInstrumentController will can image if the magnitude of the body rate is less than the limit. For backwards compatibility, this config will default to an arbitrarily high value.
Extend the current pull-request action to build and compile on Macos for Python 3.9.
clean up the BSK download info now that the full repo has been moved and tested.
This module implements the logic to control the torques delivered to a 2 degree of freedom rigid body attached to the main hub.
Describe your use case
Add support for the Vizard 2.1.4 features.
Describe alternatives solutions you've considered
None
Additional context
None
Describe the bug
The fileName local variable in MagneticFieldWMM::initializeWmm
is a fixed length char array. When basilisk is located in a folder tree depth whith a path string length of great than the fixed 100 characters, the module fails to find the WMM.COF because the path is malformed (cut off).
To Reproduce
Steps to reproduce the behavior:
MagneticFieldWMM
will fail.Expected behavior
The module to find WMM.COF regardless of location of basilisk on the OS. Tests to pass
Desktop (please complete the following information):
Additional context
I realize that any solution might not sufficiently account for the OS limits on path length. That's a much deeper and more nuanced topic.
The time taken to build for the CI workflows would be decreased slightly if we employed caching. The cache should be per PR, per platform. Aspects to investigate caching for are:
In avsEigenSupport, a method converts from C array to Vector3d and vice-versa, but none exists for the conversion to and from MRPd. Once this method is added, a refactor is also needed anywhere we use the cArray2EigenVector3d to convert from C array to MRPd.
Hi! I am attempting to install and build Basilisk in WSL2 on my Windows machine (WSL2 is running Ubuntu 20.04).
I have been following the install steps here: http://hanspeterschaub.info/basilisk/Install/installOnLinux.html
but I am unable to build the project. This is the error that I see when running
python3 conanfile.py
python3 conanfile.py
My ~/.conan/settings.yml
file does contain values for arch_build
so is it possible that conanfile.py
may be outdated?
I am using the develop
branch of Basilisk
Thanks for the help!
The boreAngCalc module calculates the boresight angle error between a body-frame axis and a celestial body. We should improve this module also to compute the boresight angle when given an inertial heading instead of a celestial body. This module also needs refactoring, as it is written in C++ but uses C-style functions for mathematical calculations.
A number of astrodynamics utility libraries are included in the sim_model
component, but they should not be. They are otherwise available to users via focused python packages and utilities. sim_model
is ostensibly the simulation driver component of Basilisk (and I advocate that it be renamed to that end so it is very clear the function and significance of this code, but that's for another day :) ). It is a core component of the Basiilisk internals and not a user facing component. This is further demonstrated by the fact that sim_model
is abstracted away from the user via SimulationBaseClass
.
Create a thermal module that increases or decreases sensor temperature based on the incidence angle of the sun with respect to a face of the spacecraft. Include power consumption from the sensor in heat computation.
This module adds the ability to simulate a two-axis system, such as a CMG, a dual-gimbal antenna, or a dual-hinged solar panel. This system can either represent a rigid body attached to the hub via a universal joint or a set of two rigid bodies attached in sequence to the hub through rotary joints. The formulation is general to simulate any configuration that fits the two-degree-of-freedom formulation.
We have a really nice Eigen::MRPd type available, however, there are a number of places in our code base where we use a Vector3d typecast where we should instead use MRPd. Also, In all those places we often assign an MRPd value instead of initializing from a type specific constructor.
This issue should refactor the Eigen::MRPd type to include a constructor that takes a double array as a parameter. Additionally, refactor places in the code base where we are using and type casting a Vector3d where we would achieve greater clarity and safety by directly using an MRPd type.
Add a status variable to the simpleInstrumentController fsw module to match the instrument data and power modules, where the status of the instrument can be set to turn off the instrument.
Some features need to be added to the spinningBodiesOneDOF module to keep it up to date with spinningBodiesTwoDOF. These features include adding a torsional spring and damper as well as including logic to lock the axis.
Some additional refactoring will also be added.
It appears that the mechanism by which wrapped C-messages can be recorded is limited to the case where such C messages are self authors. Indeed, the recorder's creation only reads from the payload
field of the message structure :
Consider msg_C.h
//! structure definition
typedef struct {{
Msg2Header header; //!< message header, zero'd on construction
{type}Payload payload; //!< message copy, zero'd on construction
{type}Payload *payloadPointer; //!< pointer to message
Msg2Header *headerPointer; //!< pointer to message header
}} {type}_C;
This definition comes in play when a recorder associated to this C message is created
//! -- Use this to record C messages
Recorder(void* message, uint64_t timeDiff = 0){
this->timeInterval = timeDiff;
Msg2Header msgHeader;
Msg2Header* pt = (Msg2Header *) message;
messageType* payloadPointer;
payloadPointer = (messageType *) (++pt);
this->readMessage = ReadFunctor<messageType>(payloadPointer, &msgHeader);
this->ModelTag = "Rec:";
Message<messageType> tempMsg;
std::string msgName = typeid(tempMsg).name();
this->ModelTag += findMsgName(msgName);
}
It is my understanding that the pointer payloadPointer
on the line preceding this -> readMessage()
actually points to the payload
field of the message definition structure, and not to the payloadPointer
field. This if fine for self-author messages that are written to, since payloadPointer == &payload
is true for self-author messages. Recorders work just fine in this case.
However, this is no longer the case for subscribed C messages as their payload
field is never written to. So creating a recorder for such a subscribed C message and hoping for the recorder to pick up whatever was written in the upstream message fails : the recorder will always record a zero payload (the content of the message's payload
field).
I think a way around would be to replace the call to the ReadFunctor constructor by the following (note the pointer that is passed to the constructor of the ReadFunctor, which once de-referenced should be equal to the payloadPointer field of the message structure)
Msg2Header* pt = (Msg2Header *) message;
messageType* payloadPointer;
payloadPointer = (messageType *) (++pt);
messageType ** payloadPointerPointer;
payloadPointerPointer = (messageType ** )(++ payloadPointer)
this->readMessage = ReadFunctor<messageType>(*payloadPointerPointer, &msgHeader);
The question as to how the Recorder constructor can detect that it is dealing with a Subscribed C message is still open though.
What are you thoughts about this ?
This flight software module is used to determine the angle of a rotating solar array in order to have the power-generating surface of the array always pointing at the Sun. The angle is defined with respect to a user-defined, body-frame zero angle direction.
There are two files bskPkgOptions.txt and bskPkgRequired.txt in the docs/ directory. These files are referenced by the conanfile.py to ensure python build and runtime dependency are installed. Beyond this current usage, there is a need to have something like (if not exactly) a python requirements.txt file generally available in the src/ directory, for use by the caching step in github actions. I suggest that these files should not be located in the docs/ directory, rather out at the top level of the directory structure so that they can be used and referenced, by build and runtime processes that need them.
Some users are experiencing challenges getting the large BSK support files (spice files, etc.) installed unless they have installed lfs
in advance. Need to update the BSK web page to recommend installing lfs
before pulling the repo.
Extend the current pull-request action to build and compile on Windows for Python 3.9.
Make the next tagged release of Basilisk
In the BSK scenario scripts there is a line that is often copied to new scripts. It contains a typo where the work time
is repeated as time time
.
When scenarioGroundLocationImaging.py
saves off the Vizard binary, the 3 ground location do not show up in Vizard.
The issue is that simIncludeGravBody.py
sets the displayName
value to Earth. This makes Vizard label the planet as earth
, and not with the planetName
value of earth_planet_data
. The latter is a spice data name for earth. If the simulation sets the displayName
value it is transferred to Vizard. If not, then planetName
is passed along. As the simIncludeGravBody.py
now automatically sets displayName
strings, this simulation script should have been updated to pass along earth.displayName
instead of `earth.planetName.
minor nitpick!
From a python file in my _UnitTest
folder :
from Basilisk.utilities import unitTestSupport
filename = inspect.getframeinfo(inspect.currentframe()).filename
path = os.path.dirname(os.path.abspath(filename))
#some stuff related to figure
unitTestSupport.saveFigurePDF("velocity",plt, path)
The figure gets saved as _UnitTestvelocity.pdf
in the parent folder, instead of velocity.pdf
in _UnitTest
folder
The KeplerianOrbit module's coupling with GravityEffector.GravBodyData is undesirable. The KeplerianOrbit module is using the GravBodyData to get at the mu gravitational constant parameter. No other feature/aspect of the module needs the GravBodyData type. We should uncouple these two and change the KeplerianOrbit module to take a mu value which is obtained from a source of truth location such as astroConstants.h. Decoupling these also provides a simpler generated Python API where the user of the KeplerianOrbit module won't be surprised that the gravy body type appears. Rather, users are coached to use single source of truth APIs to get at constants.
Currently the Custom.cmake files are executed via include()
prior to the definition of the module's compilation target by swig_add_library()
. As a result, Custom.cmake files cannot set module specific compilation flags, include configurations, and dependencies configurations (such as interface visibility etc.).
This issue seeks a refactoring of the Custom.cmake execution so that it can be executed after the call to swig_add_library()
and thus have access to the compilation target `${TARGET_NAME} in the Custom.cmake scope. Having access to the target means that custom includes, libraries, and compilation flags can be set specifically for the target. As a result build dependencies, configurations, and compilation flags can be encapsulated and localized to the module's custom.cmake (the place where the settings apply, rather than the global scope), thus decreasing coupling throughout the build system and increasing compilation unit cohesion.
This new dynamic effector module uses a faceted spacecraft model to calculate the force and torque acting on a spacecraft due to solar radiation pressure.
This module profiles a prescribed motion message for a specified translational maneuver. To simulate a rigid body following prescribed motion connected to a spacecraft hub, the profiled states written by this module using the prescribedMotionMsgPayload
message can be connected to the prescribedMotionStateEffector
dynamics module.
It appears that the header pointer corresponding to a to-be-recorded C message is not properly passed to the ReadFunctor constructor inside the Recorder(void* message, uint64_t timeDiff = 0)
that is called when one wishes to record a C message content.
See the corresponding excerpt from messaging.h
//! -- Use this to record C messages
Recorder(void* message, uint64_t timeDiff = 0){
this->timeInterval = timeDiff;
Msg2Header msgHeader;
Msg2Header* pt = (Msg2Header *) message;
messageType* payloadPointer;
payloadPointer = (messageType *) (++pt);
this->readMessage = ReadFunctor<messageType>(payloadPointer, &msgHeader);
this->ModelTag = "Rec:";
Message<messageType> tempMsg;
std::string msgName = typeid(tempMsg).name();
this->ModelTag += findMsgName(msgName);
}
Note that it is the not-initialized msgHeader
var that is passed to the ReadFunctor constructor instead of pt
.
One consequence is that this->readMessage.timeWritten()
is bogus when the recorder's UpdateState() method is called.
Is this a design feature ?
Describe your use case
Basilisk officially does not support Python 2. There is a small amount of code in the code base which specifically accommodates the option between python 2 and python 3. We should remove these accommodations as they are redundant.
Describe alternatives solutions you've considered
Refactor code base removing python 2 accommodations.
This module profiles a prescribed motion message for a specified 2 DOF rotational attitude maneuver.
The module converts two given reference angles and their corresponding rotation axes for the attitude maneuver
to a single 1 DOF rotation for the maneuver. Simple Principal Rotation Vector (PRV) addition is used on the two
given reference PRVs to determine a single PRV for the attitude maneuver.
This module profiles a prescribed motion message for a specified 1 DOF rotational attitude maneuver. To simulate a spinning body following prescribed motion connected to a spacecraft hub, the profiled states written by this module using the prescribedMotionMsgPayload
message can be connected to the prescribedMotionStateEffector
dynamics module.
Provide back of the envelope analysis and algorithm overview for trade between key Lambert solver algorithms, comparing computational efficiency as well as robustness of algorithm to throwing NaNs (or not converging to a solution).
The prescribed motion class is an instantiation of the state effector abstract class. The module is used when the states of a rigid body attached to the spacecraft hub are completely known and hence may be prescribed.
This module implements a simple 1D PID controller to actuate a spinning body 1D, based on an input spinning body message and a spinning body reference message.
Reaction wheels in BSK have maximum and minimum torque supplied as parameters, but no functionality checking power use in the state effector. This ticket seeks to add a maximum power parameter in reactionWheelStateEffector, as well as logging out for fault detection purposes.
Note: There is an already an existing basilisk/src/simulation/power/ReactionWheelPower module. This module is part of a group of power modules monitoring power use and battery voltage across a whole spacecraft. Adding computation of RW power use to reactionWheelStateEffector.cpp is duplicate and somewhat contradictory compared to the computation of RW power use in ReactionWheelPower.cpp.
The goal of this ticket is to have a simple way of enforcing reaction wheel power limits in BSK, but if a higher fidelity model is desired in the future, linking of a powerStorageBase to inform the maximum power limit in the RW state effector is seen as a more comprehensive solution. For now, the collection of power modules operates separate of effectors which is ideal for not having to set up an entire set of power nodes when one wants only a simple power limit added to their reaction wheels.
This flight software module computes a reference attitude for a spacecraft subject to multiple pointing constraints. The computed reference attitude aligns a certain body fixed direction with an inertial axis while maximizing the incidence of sunlight on the solar arrays.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.