pheidlauf / aerobenchvv Goto Github PK

trimmerFun now gets called based on the initial condition. I think it should instead be called during the control design based on the trim state, which is then output like the LQR gains.

This might affect performance... after the change we should check if the GCAS system still works. We might need to use a gain-scheduled version if better control is needed.

The rate limit check for ps_accel is as follows:

if(max_ps_accel > flightLimits.psMaxAccelDeg)

However, max_ps_accel is computed in radians / s / s... not degrees:

max_ps_accel = max(abs(ps_accels)); % rad/s/s

It's also unclear to me why the first element of ps_accels is assigned to 1... shouldn't this be zero? Otherwise, 1 rad / s / s is 57 degrees /s /s... so the computed minimum acceleration will never be below this.

ps_accels(1) = 1;
for i = 2:length(ps_hist)
    ps_accels(i) = (ps_hist(i) - ps_hist(i-1))/(time(i) - time(i-1));
end

trimmerFun gets called with 5 arguments from RunF16Sim.

The code starts out with:

if(nargin==2)
    x=Xguess;
    u=Uguess;
elseif(nargin<5)
    printOn = 0;
else
    x=zeros(13,1);
    u=zeros(4,1);
end

The 'else' case gets used, which means the initial guess gets ignored. This should be changed.

The control design uses subf16.m, and the values of ay and az this model outputs. However, the simulation model uses subf16_stevens.m, which is almost the same, except for a few lines including a modification to ay:

ay=ay+xa*xd(9);           % moves side accel in front of c.g.

I believe this means the control design uses a (slightly) different model than the simulation.

We probably only want one S&L model, rather than having both subf16.m and subf16_stevens.m (maybe subf16.m could call subf16_stevens.m and drop the extra variables).

The program is not running. Missing files eg. src/main/FlightControllers/controlGains/oldCtrlGains.mat

I'm trying to reproduce the v2 controller in python and ran into an issue where I think ps is being computed incorrectly in Matlab.

This is done in subf16_morelli.m. The comments say:

% ps= p*cos(alpha) + r*sin(alpha)

and the computation is done as:

ps = x_f16_dot(7)*cos(x_f16_dot(2)) + x_f16_dot(9)*sin(x_f16_dot(2));

I don't see why it's valid to use the x_f16_dot states here? These are derivatives not state variables. Previously we had code that extracted the state variables from x_delta, which was the difference between the current state and the trim state.

The Ny_r computation has a similar issue. The old computation was Ny_r = ay/g + x_ctrl(6), the new computation is Ny_r = ay/g + x_f16_dot(9);

I think it's in radians / sec... I don't see the conversion in my_flypath.m

There are lines like:

de=max(-25*pi/180,min(25*pi/180,de));   %bounds elevator deflection between -25 deg and 25 deg

This uses hardcoded limits, rather than the ones set in ctrlLimits. Further, controlledF16 already limits these variables (to the ones in the settings), so I think these bounds can be removed.