Catapult assisted takeoff - launch phase settings

[tpleece]

Hi,

I'm working an a HALE project using SHARPy and I wish to perform some dynamic coupled modelling of launch/ catapult-assisted takeoffs. I'm using the generate_hale.py file in sharpy/cases/coupled/multibody_takeoff as a reference but I can't see how the launch process is implemented in this file, it seems to go straight to free flight. Can you direct me to any documentation on the generate_dyn_file function and how to use the dynamic_forces and forced_for_vel capabilities?

[ngoiz]

Hi @tpleece,

This is indeed a complex case

For the catapult-takeoff likely the best case to start off with is this one and you can see in the function below that the takeoff settings are specified through Lagrange

sharpy/scripts/optimiser/base_case/generate.py

Line 717 in 41b6cb6

def generate_multibody_file():

and then implemented through controllers

sharpy/scripts/optimiser/base_case/generate.py

Line 886 in 41b6cb6

'controller_tail': 'TakeOffTrajectoryController',

This is not my area of expertise but hopefully from this optimisation case (the generate.py file is used within the optimisation routine here)

Hope this helps,
Norberto

[ngoiz]

Hi Thomas,

First, yes, the settings that had to be removed is a new feature of SHARPy to avoid old settings creeping along (or typos etc).

I've had another look at the script and the only thing I can think of is that you don't have the StaticTrim solver in the flow, as otherwise the trajectory file will not be generated. That is my only guess if your equilibrium shape is being computed. If you attach the output log maybe we can have another look.

Thanks,
Norberto

[tpleece]

Hi Norberto,

The trajectory file was being generated previously. Line 979 if 'StaticTrim' not in flow: generate_trajectory_file() suggests I should not be using StaticTrim. If I remove the if statement and add StaticTrim to the flow, I have to set initial thrust to 0 to get a converged trim condition. But I still get the same result of just solving for an equilibrium shape with the launch stage never starting.
I've attached my output.log, if you are able to take a look that would be really appreciated.
output.log

Thanks,
Thomas

[ngoiz]

Hi Thomas,

Hmm, the simulation log looks alright to me. Despite of the StaticTrim setting the thrust to 0, I would have expected the launch to initiate and then if the thrust is 0 the plane to glide, but indeed the aircraft remains static at the initial condition.

By any chance, can you try without StaticTrim in the flow? i.e. just run this:

flow = ['BeamLoader',
            'AerogridLoader',
            'StaticCoupled',
            'DynamicCoupled',
            ]

Maybe give the aircraft some non-zero thrust but I wouldn't think that should affect the launch phase.

Then, hopefully the columns in the trajectory file do make sense to you, i.e. they should be positions in x and z, which will be a function of the ramp angle,

sharpy/scripts/optimiser/base_case/generate.py

Line 282 in 41b6cb6

x_ramp = -0.5*np.cos(ramp_angle)*acceleration*t_hist_ramp**2

so if they are correct that's the only thing I can think of.

Let's see if the trim issue is what is holding it back, if not, the final thing to test out is whether we have broken something in the development phase, as the CATO optimisation was done around 2020. If nothing else works, I would give it a shot with v1.1.1

Hope this helps,
Norberto

Or maybe @fonsocarre has some insight into how to get the launch to work.

(Modified the title for future reference)

[tpleece]

Hi Norberto,

Thanks again for your help. I tried again without StaticTrim in the flow and it still did not work. The Trajectory file makes sense to me and is being generated correctly.

I've now got v1.1.1 running and now the launch phase is working properly.
base.log
So it does seem like something has broken in the more recent versions, I'll have a look around to see if I can identify where and try to help fix it if I can. Should I open a separate bug report for this?

Thanks,

Thomas

[ngoiz]

Many thanks, Thomas, for trying these options out, I guess the "good news" is that we now have something to look for.

I'll transform the issue into a bug.

I was having a quick look and the TakeoffTrajectoryController has seen no changes since v1.1.1, so I'm guessing the issue is in the DynamicCoupled solver that new routines may be overwriting the output from the controller

sharpy/sharpy/solvers/dynamiccoupled.py

Line 501 in 41b6cb6

structural_kstep, aero_kstep = self.process_controller_output(

I'll see if I have some time and have a more thorough look as well.

Thanks,
Norberto