HeliCAT-DARTS: A High Fidelity, Closed-Loop Rotorcraft Simulator for Planetary Exploration

Abstract

HeliCAT-DARTS is a high-fidelity rotorcraft dynamics simulator developed for the design and development of rotorcraft for planetary exploration. While initially developed for the life cycle use of the Ingenuity Mars Helicopter mission, the simulator now supports a broad range of rotorcraft configurations and applications. HeliCAT provides a GNC testbed and aerial mobility analysis platform for rotorcraft design, closed-loop flight software development, verification and validation (V&V), and mission operations. This article discusses the design and use of the HeliCAT simulator and results from technology demonstrations and missions.

1. Introduction

Rotorcraft provide unique capabilities for exploring extraterrestrial environments. In comparison to exploration vehicles such as rovers, rotorcraft are able to travel farther and faster to destinations of interest. Moreover, they only require suitable take-off and landing zones and can fly over terrains that may not be traversable by rovers due to obstacles or rough terrain. These advantages have motivated the Mars Ingenuity mission, which involved the first rotorcraft to fly on Mars [1]. The success of this mission has continued to motivate future missions such as the potential use of helicopters for returning samples from Mars [2].

Designing a first-of-a-kind rotorcraft like Ingenuity for operating in the Martian atmosphere environment required unique tools for design, development, and operation. Among the tools developed was HeliCAT-DARTS—hereon simply called HeliCAT for brevity—for rotorcraft dynamics modeling and simulation. This simulation tool served as a testbed for the guidance, navigation, and control (GNC) algorithm and software development and as a tool to analyze flight performance and dynamics. HeliCAT was used throughout the life cycle of the Ingenuity mission, including the following:

• Conceptualization: HeliCAT was used to understand the fundamental differences between helicopter flight on Mars vs. Earth, as well as how to design a rotor system to make the helicopter robustly controllable in the Martian environment.
• Sizing: HeliCAT was used to size the helicopter with the appropriate mass, thrust, and power margins, as well as control authority for flight.
• Design trades: HeliCAT was used for a wide variety of design trades throughout the development cycle; for developing operating envelopes, sensors, and actuators; specifications; terrain requirements; landing stability; and algorithm design.
• Test design: HeliCAT was used to develop experiments and tests during development utilizing test vehicles, ground support equipment, test setups, and test procedures. Experiments were rehearsed in the HeliCAT framework to practice and refine parameters and procedures prior to conducting the actual test.
• Verification and validation: HeliCAT was a cornerstone of the verification and validation (V&V) campaign for flight, allowing simulations of end-to-end flight scenarios across the entire range of relevant environmental parameters.
• GNC algorithm and software development: HeliCAT was used to prototype GNC algorithms and eventually close the loop around GNC flight software for end-to-end simulated testing of flights on Mars.
• Mission operations: HeliCAT was used throughout the operations of the Ingenuity helicopter. It was a critical tool for mission operators to plan, visualize, analyze, and execute Ingenuity’s flights.

To support these uses, HeliCAT has been designed to simulate the helicopter in a variety of environments—on Mars, in a pressure test chamber, on Earth, etc.—and in a variety of configurations—free-flying, attached to a test stand, attached to a tether, etc.

HeliCAT combines the right elements to make it a full life cycle product, from conceptualization through mission operations. This was preferable for designing and flying the Ingenuity helicopter, as opposed to utilizing a suite of pre-existing tools for different purposes. The downsides of the latter approach include the overhead of learning and using multiple tools and accepting the uncertainties and inconsistencies that come with an analysis pipeline that uses multiple tools. Instead, HeliCAT was created to fill a niche that combines analysis techniques to model a particular environment on Mars and to design and fly Martian helicopters.

HeliCAT was built upon the DARTS/Dshell simulation framework for flexible multibody dynamics modeling, analysis, and simulation at JPL [3,4]. This framework includes the ability to combine multibody dynamics models with so-called Dshell models for components such as actuators, sensors, motors, avionics, and environmental models [5]. DARTS/Dshell’s capabilities for terrain modeling [6] and visualization [7] were also utilized by HeliCAT but are not discussed in detail in this paper.

A key aspect of the DARTS/Dshell simulation framework is the ability to design component models for configuration and reuse across multiple projects and domains. While this paper focuses on rotorcraft applications, DARTS/Dshell-based simulations are in use for cruise/orbiter spacecraft, landers, rovers, and robotics projects [8]. This important reusability feature reduces the time and cost for developing simulations, allows the maturation of the component models over time, and reduces the verification and validation (V&V) effort. The HeliCAT development adopted this approach by designing simulation components to support several different deployments for ongoing missions and technology development for future generations of helicopters. For HeliCAT, this meant implementing a general-purpose rotorcraft simulator that can be used for different classes of vehicles with different rotor configurations, such as coaxial vehicles, classical helicopters, and multicopters. As a result, HeliCAT has been used across a variety of projects, including Ingenuity, Sample Recovery Helicopters [2], Mars Science Helicopter [9], and MAHD (mid-air helicopter delivery) [10].

The remainder of this article is structured as follows. First, the simulation is described, including details on both the multibody model and the Dshell models. This section also includes a discussion on different vehicle configurations. Next, the simulation usage is presented. This section describes how to run a simulation and common use cases such as time domain simulations and creating linear state space models for control design and frequency domain analysis. Then, we discuss simulation results and comparisons between the simulated data and data collected from physical systems. Finally, the article finishes with some conclusions and future work.

2. HeliCAT Simulation Overview

The simulation overview is broken into two main sections. The first describes the multibody model used for the rotorcraft dynamics. The second section describes the Dshell models used in the rotorcraft simulation, which includes aerodynamic models, actuator models, sensor models, environmental models, etc.

2.1. Multibody

DARTS is a tool for building and simulating general multibody dynamics models. This framework uses a minimal coordinate approach based on the Spatial Operator Algebra (SOA) methodology [11], which provides low-cost recursive computational algorithms for solving the equations of motion. DARTS includes support for rigid and flexible bodies [3,4], as well as the articulation joints that connect them. The nominal multibody dynamics model used to represent a rotorcraft in HeliCAT is a set of rigid bodies connected by joints with optional spring-damper models on said joints. The mass properties of each of the rigid bodies include the mass, center-of-mass offset, and inertia tensor. Optional springs and dampers on each joint can be tuned to approximate the flexible body modes of the rotorcraft, as described in detail later in this section.

The root body of the multibody model is the fuselage. Attached to the fuselage are the rotor systems, the landing gear, and other appendages for the vehicle. The main components of the rotor system are a mast or rotor arm, the hub, and the blades. The hub attaches the blades to the mast via a configurable series of hinges that span the pitch, lag, and flap degrees of freedom. The landing gear is represented by a configurable set of bodies that are attached to the fuselage with hinges to represent the landing gear’s flexibility. Examples of additional appendages that have been modeled include wire harnesses during testing, robotic arms, and payloads.

The HeliCAT simulator has a command line interface (CLI) which also supports the use of configuration files to define the simulation model. This CLI has over 300 options that the user can use to tailor simulations. These include the ability to do the following:

• Vary the topology of the multibody model, including the number of rotors and blades on the rotorcraft, as well as the ability to dynamically attach/detach other multibody objects, such as test equipment, a host vehicle, and a payload.
• Adjust the order, location, orientation, and degrees-of-freedom of joints.
• Vary the mass properties of each body.
• Enable/disable Dshell models, specifying their execution frequencies and their parameters.
• Specify dynamically varying inputs such as wind disturbances for control inputs.
• Adjust simulation-related parameters such as the type of integrator method and step size.
• Specify visualization-related parameters, e.g., visualization backend and frame rate.

The multibody as described thus far is used in every HeliCAT simulation. However, since HeliCAT is built on DARTS, it can be further customized, and the CLI can be extended for a given project or mission. For example, Earth testing of Ingenuity included a gravity offload mechanism consisting of a tether attached to an actively controlled motor based on force feedback. The gravity offload mechanism and its interaction with the helicopter was modeled in HeliCAT as part of the design and rehearsal for Ingenuity’s test program. Ingenuity extended the CLI to include this mechanism and expose its parameters.

Approximating Flexible Body Behavior

The traditional approach for modeling flexible body modes in HeliCAT is by including optional springs and dampers on joints that represent the flexibility of the system, including flexibility of the mast, the landing gear, and the blades. Using externally gathered information about the rotorcraft, either from a Finite Element Model (FEM) or tests of the physical system, these springs and dampers are tuned to approximate the given flexible body behavior, e.g., tuned to match mode shapes and modal frequencies of linearized versions of the nonlinear dynamics model. Tuning the modal frequencies can involve isolating individual joints of the rotorcraft, e.g., isolating the motion of the legs in the FEM and tuning the springs in the HeliCAT to match the modal frequencies. After tuning the individual parts of the system, the full system free-free modes (the modes of the entire system with all joints unlocked) are compared to the FEM’s full system free-free modes. This approach is iterative and manual in nature and requires significant time to develop an accurate model.

DARTS includes convenience methods for model linearization to facilitate such tuning (see Section 3.3.2 for more details on linearization). This allows users to easily create time-invariant state space models from which eigenvalues can be extracted. This can be wrapped in a nonlinear solver to help automate the process of tuning the springs/dampers of the system.

DARTS also has the capability to directly model body flexibility [12,13]. Recent efforts have focused on developing convenient and automated tools for translating between FEMs and DARTS flexible bodies. These new features can be used in HeliCAT to replace the rigid-bodies-plus-springs approach, which improves accuracy and reduces the manual aspect of tuning the flexible model. Figure 1 shows an example from a pilot study where one of the legs that make up the landing gear was replaced with a true flexible body. The second leg bending mode shape of this model is shown in Figure 1.

2.2. Vehicle Level Component Dshell Models

HeliCAT serves as a testbed for GNC simulations and includes models for sensors and actuators. This section discusses the nonmultibody dynamics components of HeliCAT, which include aerodynamics, actuators, sensors, flight software (FSW) interface, the environment, and terramechanics models. Also discussed in this section are the models that mimic components in various nonfree flight configurations such as test stands and tethers.

2.2.1. Aerodynamics Models

To model aerodynamic forces on the blades, HeliCAT combines Blade Element Theory with a dynamic inflow model based on actuator disc theory [14,15]. The method is described in Ref. [16] and is summarized here as follows. Each blade is discretized into several rectangular blade elements, each with its own chord, twist, and sweep. Associated with each element is an airfoil table parameterized by Mach number and angle of attack, typically produced using two-dimensional CFD. At each time step in the simulation, an interpolation is performed on the current Mach number and angle of attack to produce nondimensional coefficients for lift, drag, and pitch moment at each element. These coefficients are then converted into dimensional forces and moments based on the span and chord of the blade element, atmospheric density, and the wind-relative velocity of the section. Individual contributions of each blade element are summed to obtain the total contribution from each blade attached to the vehicle. Additional corrections such as yawed flow (that is, treatment of flow along the spanwise direction of a blade element), tip losses, and unsteady aerodynamics due to acceleration are included based on [16,17].

The Mach number and angle of attack local to each blade section are determined by calculating the wind-relative velocity of the section. The wind-relative velocity vector is a function of ambient atmospheric winds, vehicle motion, rotational speed of the rotor, blade pitch, blade twist, and rotor inflow. To produce lift, a helicopter rotor adds downward momentum to the surrounding air, resulting in a flow of air through the rotor disc. To estimate this flow as a function of rotor thrust, aerodynamic moment, and the helicopter’s wind-relative velocity, HeliCAT implements a version of the Peters and HaQuang dynamic inflow model [14] that is augmented with selected tuning parameters to bring the model into alignment with experimental data (see [16] for details) [18,19].

Several models, including the dynamic inflow model and a model capturing ground effect, depend on knowledge of the helicopter’s tip path plane. The tip path plane is the plane swept by the tips of the blades that is continuously estimated by a dedicated model based on the rotor motion. An adaptation of the ground effect algorithm proposed in Johnson’s Rotorcraft Aeromechanics [17] is used in HeliCAT to modify the inflow seen by rotors based on their proximity to the ground. A simplified diagram showing the aerodynamics computation flow is shown in Figure 2. The figure does not show each model’s connection to the multibody model. All Dshell models can get information from the multibody. For example, the tip path plane model gets information about the positions of the tips of the rotor blades. In addition, certain models can apply information to the multibody model. For example, the blade element models apply forces and moments to the blades in the multibody.

A goal of HeliCAT is to enable the simulation of general rotorcraft configurations with arbitrary positions and numbers of rotors and blades. Aerodynamic forces and moments can readily be calculated independently for each blade section using the process described above. For configurations where rotors are placed in close proximity to one another, for example, the coaxial configuration of Ingenuity, HeliCAT provides the ability to model interference between rotors. Interference is handled as a modification to the relative wind experienced by a rotor as a fraction of the inflow generated by another. HeliCAT also provides a general framework to implement fuselage aerodynamics models. For example, Ingenuity implemented a simple blunt body drag model where the coefficient of drag is independent of flow direction. HeliCAT allows air loads on the body to be represented by higher fidelity, angle-of-attack-dependent models, but this is generally unnecessary for low-density environments such as Mars.

2.2.2. Actuator Models

Actuator dynamics can be captured with dedicated models. For Ingenuity, swash plate servos and the associated lower-level controls were represented by a second-order response to commanded inputs, with a bounded slew rate and time lag. Equations (1) and (2) show a second-order response to a command input, $x_d$, with a slew rate bound of L. In these equations, x is the current position of the system, $\dot{x}$ is the velocity, $\ddot{x}$ is the acceleration, $\omega$ is the natural frequency, and $\zeta$ is the damping ratio.

$$\ddot{x}=\left\{\begin{array}{cc}0,\hfill & \mathrm{if}\dot{x}>L\hfill \\ 0,\hfill & \mathrm{if}\dot{x}<-L\hfill \\ {\omega }^2(x_d-x)-2\zeta \omega \dot{x},\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(1)

$$\dot{x}=\left\{\begin{array}{cc}L,\hfill & \mathrm{if}\dot{x}>L\hfill \\ -L,\hfill & \mathrm{if}\dot{x}<-L\hfill \\ \dot{x},\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(2)

A time lag is implemented for each actuator to account for the delay in the response of the actuator to its input. The propulsion motors were represented by a DC motor model outputting torque as a function of applied voltage and back EMF.

In HeliCAT, blade pitch is dynamically prescribed as a function of the current collective and cyclic action from the servo model. On the physical helicopter, the servos control the position of a swash plate that is connected to the blades via pitch links. The connected servo, swash plate, and blade linkages form a closed-loop, nontree multibody topology. DARTS, and thus HeliCAT, are capable of simulating such topologies using minimal coordinates [20,21]; however, this is more computationally demanding and was not deemed necessary in the case of Ingenuity.

2.2.3. Sensor Models

HeliCAT contains IMU, altimeter, inclinometer, and camera models. These models mimic the real sensors of the rotorcraft being simulated. The IMU, altimeter, and inclinometer models calculate a truth value using quantities from the dynamics, e.g., the true acceleration of the accelerometer in the IMU, and then add white noise and bias. The noise characteristics can be controlled by the user to mimic the sensors of their rotorcraft.

The camera model uses a user-specified CAHVORE camera calibration file [22]. Using these parameters, the model simulates images from the scene for the rotorcraft camera using the IRIS real-time ray-tracing module [7]. Then, the image buffer is piped through user-specified filters that can include noise, blur, grayscale, contrast, gamma correction, vignetting, and brightness. The data from the sensor model’s image buffer flow through the FSW interface to the FSW where they are used to make control decisions.

2.2.4. Flight Software Interface

As a GNC testbed, HeliCAT is designed to interface and close the loop with the FSW. This entails sending sensor data to the FSW, receiving control commands from the FSW, and generating extraneous data for logging and debugging from the FSW. These tasks are done by the FSW interface model. It is important to emphasize that HeliCAT itself is not the FSW. However, via the FSW interface, HeliCAT can interact with the FSW that will run on the physical hardware. HeliCAT does include a simple controller (implemented as a Dshell model) that can be used in place of FSW for testing purposes.

2.3. Environment

HeliCAT has multiple terramechanics models that can be used to calculate the contact force between the helicopter landing gear and the ground. These range from simple spring-damper-plus-Coloumb-friction models to more complex models such as Terzaghi and Bekker–Wong [23,24]. The contact force calculation requires collision detection between the rotorcraft’s landing gear and the terrain. Collision detection is done by comparing the height of the landing appendages to the height of the terrain, which is represented as a digital elevation map (DEM). DARTS provides multiple ways to specify this DEM, from simple analytical functions—flat terrain, sloped terrain, sinusoidal, etc.—to using DEMs from real-life data such as scans of the Martian surface [6]. In addition to providing information for the elevation of the surface, DARTS also provides fine-grain control of the visuals of the DEM, which is important for accurately simulating vision-based navigation [7].

HeliCAT also includes atmospheric models with different levels of fidelity. These models provide density, speed of sound, temperature, and wind velocity data. The simplest model provided is one where all the values remain constant. HeliCAT also provides the user the ability to use more complex models such as the GRAM atmospheric models. For example, the Mars GRAM model can even account for factors, such as seasonal dust concentration on Mars, and can provide dispersions for parameters like winds and density along a user-defined path, in addition to mean values [25].

2.4. Vehicle Configurations

In addition to free flight, HeliCAT supports modeling configurations used for designing and testing a rotorcraft, including attaching the helicopter to gimbals, test stands, tethers, landers, jetpacks, etc. Coupled with the environment options, this allows users to easily simulate multiple test configurations, e.g., attached to a tether in a pressure chamber.

The ability to easily change the vehicle configuration builds on the flexibility provided by DARTS (and ultimately the underlying SOA multibody dynamics framework). Modifying the vehicle configuration, e.g., attaching the helicopter to a test stand, requires modifying the underlying multibody topology. However, since SOA is structure-based, and the DARTS API provides simple methods to attach/detach bodies, implementing these different configurations is simple and straightforward. In addition to the multibody topology, other aspects of the simulation may need to be modified as well, e.g., adding models for the motor of a test stand arm. These modifications are facilitated by the Dshell framework [5].

While HeliCAT supports common vehicle configurations, users can create their own custom models and configurations to meet their needs. Some examples of this are the lander egress for SRH and the jetpack for MAHD [10]. The lander egress model for SRH attaches the helicopter to a lander; see Figure 3. This attachment consists of a custom six-degree-of-freedom (DoF) spring-damper model. When the rotorcraft detaches, there are other custom-built models to simulate various egress assistance hardware. For the MAHD jetpack, an additional assembly is created to model the jetpack, with thrusters and a controller for those thrusters (see Figure 4). During the descent and landing sequence, the helicopter is initially attached to this jetpack and then detaches and flies to the ground on its own power.

3. HeliCAT Usage

3.1. Running a Simulation

HeliCAT provides hundreds of options to the user to tailor rotorcraft simulations. These include the following:

• Mass properties, locations, and number of bodies that make up the rotorcraft;
• Atmospheric properties;
• Terrain and terramechanics properties;
• Vehicle configuration and associated properties;
• Sensor properties;
• Actuator properties;
• Data logging information;
• Flight-software-related parameters;
• Time stepping parameters, e.g., integrator, step size, etc.

Individual projects can further extend the parameters that a user can change by adding project-specific options, e.g., jetpack-related options and vehicle configuration for MAHD. HeliCAT uses the Dclick CLI framework within DARTS to manage this large number of options and provide a way to easily combine and review them. The Dclick framework builds upon the open source click and pydantic Python modules. Dclick provides the follwing:

• Support for specifying options via configuration files and the CLI. This includes support for partial configuration files and the ability to combine multiple config files and CLI options together.
• Support for exporting the final version of configuration options to a file for archiving/review.
• Automatic, hierarchical help generation. This is particularly important for discovery and self-documentation when the number of options is large, as it is in HeliCAT.
• Support for unit specification and conversion.
• Support for type checking and data validation.

HeliCAT’s extensive CLI serves as the main entry point for running simulations. Included in this CLI are options to execute Python scripts with arbitrary, user-defined scenarios. This provides an easy way to use the entire DARTS API in HeliCAT. Users can also use an interactive Python session to interact with simulations.

3.2. Time Domain Simulations

Time domain simulations are the main tool used to analyze a given design’s aerial mobility performance. As mentioned earlier, the CLI can be used to easily modify parameters so that users can check how a given variable, e.g., air density, affects the flight performance. Once a given design is chosen, users can evaluate its performance in a variety of representative environments using parametric and Monte Carlo simulations.

HeliCAT comes equipped with tools to allow users to easily specify variables and associated distributions when running Monte Carlo simulations. Moreover, the user can easily control how many simulations to run in total and how many to run in parallel. This process is fairly straightforward due to the extensive aforementioned CLI. Furthermore, since the CLI can manage vehicle configurations, one can perform Monte Carlo simulations over any of the previously mentioned configurations, including and beyond free-flight scenarios.

All of these time domain simulations have a rich suite of data logging options that come with HeliCAT. Moreover, this system is easily extensible, so users can tailor the variables to log as needed. This will be discussed more in the offline analysis section below.

3.3. Offline Analysis

Oftentimes, the simulation produces results for post-analysis by other tools. The most common data generated by the simulations are logged variables. The DARTS API, and thus HeliCAT, offers a way to log and store the time history of numeric quantities in the simulation such as joint states, flight software telemetry, and Dshell model values such as the density output of an atmospheric model. This data logging is extensible and customizable, so users can easily add custom variables to log. The data can be logged to a variety of file types, such as CSV and HDF5, and can even be used in live plotting tools such as plotjuggler.

3.3.1. Post-Processing Simulation Data

The aforementioned data logs were utilized by external tools after the simulation was run. Commonly, these variables are combined and plotted by analysts. For example, one might plot an estimate of the fuselage velocity from the FSW, along with the true value of the fuselage velocity to get a sense of how well an estimator is performing.

Another common use case is plotting values from a suite of Monte Carlo runs. This is useful for tasks such as determining landing ellipses. These data can also be ingested by a variety of other tools. For example, for SRH, the trajectory of the helicopter when egressing from the lander was ingested into a CAD (computer-aided design) tool to determine the clearance between the helicopter and the lander during egress. This process can be done with many trajectories from a set of Monte Carlo simulations, where parameters like the wind velocity and angle of the lander with respect to gravity are varied. Figure 5 shows examples of what these helicopter trajectories look like when input into the CAD. This process (Monte Carlo simulation plus post-analysis in CAD) was done multiple times to see, for example, how the diameter of the lift-off assistance mechanism impacted the helicopter-to-lander clearance on egress. The data from this and other such simulations were used in trade studies and design decisions for the helicopter egress mechanisms.

3.3.2. Linear State Space Models

Rather than the full nonlinear DARTS model, controller designs typically use linear time-invariant (LTI) models for the helicopter dynamics. Since a given helicopter’s dynamics can vary significantly in hover compared to forward flight [16,17], a bank of LTI models at different flight conditions are used for control design and analysis. HeliCAT includes processes to create these LTI models.

The first step is to find a trim state. This is the helicopter state for the user-provided external wind and helicopter velocity values that keep the helicopter hovering or traveling steadily at the chosen velocity. The trim state is found via an optimization process that determines values for the multibody and Dshell model states, such as the helicopter’s pitch and controls, which includes the collective and cyclic controls on the blades and voltage control on the propulsion motors. Helicopters are unusual in that even this steady behavior is actually periodic due to the rotating blades, so the optimization algorithm searches for the combinations of states and controls such that the beginning and ending state of a single rotor rotation are identical.

The next step is to linearize around the trim state using the DARTS framework’s general-purpose linearization capabilities. Due to the periodic nature of helicopter dynamics, HeliCAT linearizes at several uniformly spaced points along a single rotor rotation. Combining these linear models yields a periodically linear time-varying model. To generate a time-invariant model that captures the dynamics of the helicopter at frequencies relevant for controls, the system is modeled by a harmonic expansion of the state up to a chosen multiple of the rotor frequency with higher-order terms discarded (see [16] for details about this process). This LTI model is suitable for use in frequency domain control design and analysis [26,27,28]. The controllers are then implemented and tested in time domain simulations against the full nonlinear model.

The LTI models are also valuable for evaluating modal frequencies as described in Section 2.1 and for facilitating comparisons between HeliCAT models and other tools. Linearized state–space HeliCAT models of MAHD helicopter configurations were compared against linearized models of the same configuration in CAMRADII, which constitute a comprehensive analysis tool for rotorcraft that has been used in NASA and industry applications [29,30].

4. Results

HeliCAT has been used on a number of projects, but most comprehensively by Ingenuity, which relied upon it from early conception through operations on Mars. In this section, we will focus on results from this process.

4.1. Fundamental Flight Physics

In the initial phases of Ingenuity, HeliCAT was used to understand the differences in fundamental flight physics between a Martian and Earth environment. Due to the lack of experimental reference data for small-scale coaxial Martian helicopters, quantitative modeling errors were expected in certain areas, which could only be corrected through experiments. An extensive set of experiments were performed in JPL’s 25-foot Space Simulator where the Martian atmosphere could be replicated. The results of these experiments were in some cases used to tune the HeliCAT model. This was true in particular for the dynamic inflow model, which was expected to have inaccuracies due to its simplified form and semi-empirical nature.

As mentioned in Section 2.2.1, the interference between rotors was handled as a modification to the wind-relative velocity seen by each rotor as a fraction of the inflow generated by another rotor. In HeliCAT, this value was utilized in the dynamic inflow and blade element models to modify the wind-relative velocity when calculating the aerodynamic forces. In hover, the experimental results lineed up well with an interference model, where the lower rotor saw the entire inflow of the upper rotor, but without any coupling in the opposite direction. In forward flight, as the wake was progressively convected away by the relative wind, the experimental results indicate that the coupling was reduced. Figure 6 shows the measured thrust versus the thrust modeled in HeliCAT using the level of coupling present at hover. These data were captured with a wind speed of 11.2 m per second to mimic forward flight at 11.2 m per second. The rotor rotational speed during data collection was 238 radians per second. As a result, the thrust between HeliCAT and the experiment should differ noticeably, as the interference factor used does not match the flight conditions. The data captured in this figure were used to tune the interference factor for forward flight. Figure 7 shows the same comparison after tuning the interference factor, which reduced the coupling in forward flight. The difference between the two was much smaller in Figure 7 than in Figure 6. For other examples of what was learned in aerodynamics experiments, see [16,31]. Control design is beyond the scope of this article. Therefore, for details on how this and other aerodynamic experiments were used in conjunction with an ensemble of linear models to ensure controller robustness, see [27].

4.2. Flights on Mars

Originally, Ingenuity was only designed to fly for a few flights on Mars. For these flights, HeliCAT was intended to be used as a functional validation tool of the flight sequences sent to Ingenuity, but it was not used to assess performance. Before each flight, a single HeliCAT simulation was performed in a simplified environmental setting to ensure the flight would execute as expected.

Due to the success of the first few flights, the Ingenuity mission was extended. The extended mission included flights that far exceeded the original operational parameters, which required both simulation and FSW upgrades [32]. Over time, and with growing confidence in the simulation given numerous successful flights on Mars, HeliCAT stopped being a functional validation tool and transitioned into the primary means of evaluating flight performance, safety, and ensuring mission success.

One instance of this test process identifying the safe path is depicted in Figure 8 with several flight trajectories and an elevation profile between points A and B. Ingenuity needed to traverse from A to B while crossing the dynamic terrain regions between the safe airfields marked by the yellow polygons. Initial testing showed that the straight 500 m flight from A to B (dashed black line) was prone to tripping fault protection when reaching the steep downhill near the end of the flight, causing an early landing. The steep hillside, high horizontal speed, and slow response of the vertical control channel caused the vehicle to fly too high above ground level, exceeding the threshold set to ensure successful measurements from the laser altimeter. This concern led the team to split the flight into multiple sections. Focusing on the second flight targeting point C, the simple flight trajectory (red dotted line) was again rejected due to HeliCAT results indicating the terrain negatively impacts the FSW, and the vehicle accumulated significant navigation error, particularly near the end of the flight when reaching the large downhill at an angle. Iterations led to the final flight plan for Flight 56 (blue solid line) that included a mid-waypoint to enable the vehicle to fly slower and straight downhill to point B before flying quickly up the flat terrain of the airfield to point C. Though Figure 8 only shows one trajectory per flight design, Monte Carlo analyses were used to generate 40–80 trajectories per design allowing for landing dispersions to be evaluated against airfield allocation.

Overall, the HeliCAT Monte Carlo results well bounded the performance as seen on Mars. In only a few flights did Ingenuity land outside of its expected landing dispersion or the allocated airfield. A review of HeliCAT results and flight data identified the atmospheric winds and actual Martian terrains being the primary driver. The actual terrain was far more dynamic than the simulated DEM and exacerbated issues seen in HeliCAT. The FSW, taken to the limits in the extended mission, performed worse when traversing curved terrain (i.e., rounded hilltops) in comparison to monotonic slopes. If large gusts or terrain disturbances occur early in the flight, the vehicle can integrate the error over the entire flight to create larger position error s at landing.

It can be difficult to directly compare detailed HeliCAT and flight results over long traverse flights as shown above, because the terrain heavily influences the dynamics behavior. To simplify, a multialtitude popup flight was selected to reduce the impact of terrain due to the horizontally stationary flight. The Flight 59 flight plan is shown in Figure 9, where the vehicle hovered at five altitudes. This flight accomplished several engineering and scientific goals: (1) tested the laser range finder to a new max height of 20 m, (2) validated new GNC algorithm parameters for touchdown detection at a decreased descent speed of 0.75 m/s (nominally 1.0 m/s), and (3) hovered at various altitudes to better understand atmospheric winds and boundary layer effects on Mars. Note that the North–East–Down coordinate system defines positive height above ground level as a negative position.

Flight 59 was executed at a predicted density of 0.0140 kg/m³ using the highest rotor speed setting of 2700 RPM. An overlay of results in Figure 10 and Figure 11 compare the simulated and in-flight vertical velocity and yaw angle, respectively. Gyroscope, accelerometer, altimeter, and vision odometry measurements were fused in FSW via a Kalman filter to generate onboard estimates [33]. For simulated HeliCAT results, there are both truth and estimated values, whereas the truth is unknown for in-flight results. Figure 10 shows an overall good match, though in-flight data had higher noise and greater variation in the performance between each step response. This is due to the aero and dynamic models insufficiently capturing the complex Maritan flight and impact of real Martian winds, which are much more turbulent and time-varying than simulated in the Ingenuity HeliCAT environment. Figure 11 highlights the navigation challenges for Ingenuity, as error can creep into the FSW estimate causing the yaw heading (and horizontal position when integrated over time) to drift from the truth. Evaluating this knowledge degradation prior to flight was critical to ensure Ingenuity could traverse difficult terrain and land within a designated airfield. In-flight estimates were compared with raw gyroscope measurements to confirm that the noise in the signal was real motion and not noise induced by the estimator dynamics. In-flight behavior was again noisier than simulated and had a stronger vertical acceleration to yaw angle coupling than predicted by the simulation, which is likely due to a combination of winds, errors in parameter tuning, and the degradation of the vehicle over multiple years of Martian flight.

Last, HeliCAT was used for V&V FSW updates before they were uploaded to the real system and to investigate anomalies that occurred during operations on Mars. HeliCAT simulations were key in understanding vehicle performance and capability when new types of activities were planned, such as flying into new terrain, flying faster or to new heights, and conducting in-flight system identification [34].

5. Conclusions

HeliCAT is a high-fidelity, closed-loop rotorcraft simulator written using the DARTS/ Dshell framework. It is designed to be used throughout the entire life-cycle of a project from conceptualization to mission operation. This article described the major components of the HeliCAT simulator and how they can easily accommodate a large variety of rotorcraft. Furthermore, the article describes how the simulation can and has been extended to meet specific mission needs, e.g., helicopter egress for SRH. In addition, this article showcased common usage scenarios with examples. Finally, some of the simulation results were shown.

The HeliCAT simulator had sufficient fidelity and performance to design, validate, and operate the Ingenuity rotorcraft: the first rotorcraft to fly on Mars. Moreover, it is currently in use for other extraterrestrial rotorcraft projects at JPL. While these are significant achievements for the software, future missions and technology demonstrations that contain larger rotorcraft and more sophisticated GNC will require improvements to aspects of the simulation.

One of these aspects is the flexible body modeling. The goal of HeliCAT is to understand how the compliance of the rotorcraft components interacts with the GNC and impacts the aerial mobility of the rotorcraft. The rigid-bodies-connected-by-springs model was sufficient for the life cycle of Ingenuity. However, newer rotorcraft, such as the SRH, have more interference between the GNC and flexible body models. Projects are already incorporating the more sophisticated flexible body modeling that DARTS offers. Fortunately, the SOA-based DARTS formulation contains the ability to simulate flexible bodies, which is a capability that has been used since Cassini [35]. More recently, a pipeline has been established to simplify the process of transforming an FEM into a DARTS flexible body model and improve the cadence of design iterations [12,13]. Since the flexible body simulations and HeliCAT are both built using DARTS, it is straightforward to combine the two, as shown in the small pilot study mentioned earlier (see Section 2.1 for more details).