avslab / basilisk Goto Github PK

This module implements the logic to control the torques delivered to a 2 degree of freedom rigid body attached to the main hub.

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

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.

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:

• python pip packages
• conan packages
• git lfs portions of the repo (if possible/sensible to do so)
• built conan libs (possibly)

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).

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.

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.

Describe your use case
Add support for the Vizard 2.1.4 features.

Describe alternatives solutions you've considered
None

Additional context
None

Extend the current pull-request action to build and compile on Macos for Python 3.9.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

clean up the BSK download info now that the full repo has been moved and tested.

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.

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.

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.

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.

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.

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.

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 ?

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.

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.

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.

Extend the current pull-request action to build and compile on Windows for Python 3.9.

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.

Provide Basilisk support for Vizard 2.1.3.

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.

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.

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:

• separate toggle for effector coordinate systems
• effector bodies cannot be chief spacecraft in relative orbit calculations
• no orbit lines for effector bodies
• no sprites for effector bodies
• nest effector bodies under the parent spacecraft in dropdown menus
• group actuator and device components on GUI display panels by parent spacecraft instead of by body (do not have separate display panels for effectors)

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

Make the next tagged release of Basilisk

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 ?

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.

Overview

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

Steps to Reproduce

• Install dependencies according to the steps in http://hanspeterschaub.info/basilisk/Install/installOnLinux.html
• From the Basilisk home directory, run python3 conanfile.py

Other Notes

• No conan commands seem to work for me
  

• 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!

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:

1. Install basilisk in a directory structure where the path to the WMM.COF file is more than 100 characters in length.
2. Build and run all tests and those using 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):

• OS: Macos
• Version 12.6.1
• Python version 3.9.15

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.

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.