fmincon with simulink model

Hello, I'm struggling with fmincon, as I'm still a beginner. I have a Simulink model that simulates the behavior of an electric vehicle and a track specification (maximum speed in different sections, total length).

The model takes as input the throttle and brake pedal pressures (steering is not relevant in this case) and outputs various vehicle dynamics parameters such as speed, jerk, acceleration, and SoC.

My goal is to determine the optimal pedal usage to complete the track while maximizing the remaining SoC, using the results obtained from the model.

I wrote a MATLAB script for this, but the throttle and brake pedal vectors never change—they always remain the same as the initial values u0 that I provide.

Does anyone know what might be causing this issue?

My cost function is:

function [cost, c, ceq] = myCostAndConstraints(u, timeVec, steeringTS, w1, w2, w3, w4, w5, total_distance)
N  = length(u)/2;
throttleProfile = u(1:N);
brakeProfile    = u(N+1:end);

myThrottleTs = timeseries(throttleProfile, timeVec);
myBrakeTs    = timeseries(brakeProfile, timeVec);

in = Simulink.SimulationInput('optimization_offline_model');
in = in.setVariable('myThrottleTs', myThrottleTs);
in = in.setVariable('myBrakeTs', myBrakeTs);
in = in.setVariable('steeringWheelAngle_ts', steeringTS);

try
    simOut = sim(in);
catch ME
    warning("Simulation error: %s" + ME.message);
    cost = 1e6;
    c    = 1e5; 
    ceq  = [];
    return;
end

try
    timeSim      = simOut.tout;
    speedData    = simOut.v_z.Data;
    SoCData      = simOut.SoC.Data;
    jerkData     = simOut.j_z.Data;
    distanceData = simOut.distance.Data;
catch ME
    warning("Error extracting signals: " + ME.message);
    cost = 1e6;
    c    = 1e5;
    ceq  = [];
    return;
end

SoC_final      = SoCData(end);
time_elapsed   = timeSim(end);
distance_final = distanceData(end);

penalty = 0;

if any(SoCData < 0.2)
    penalty = penalty + w1 * (0.2 - min(SoCData(SoCData<0.2)));
end

vLimHard = 41.5;
violV = speedData - vLimHard;
violV(violV<0) = 0;
if any(violV > 0)
    penalty = penalty + w5 * sum(violV);
end

avgJerk = mean(jerkData);
maxJerk = max(abs(jerkData));
penalty = penalty + w3*(max(0, 0.2 - avgJerk))^2 + w3*(max(0, avgJerk - 0.7))^2;
if avgJerk > 0.6
    penalty = penalty + w3*(avgJerk - 0.6);
end
if maxJerk > 0.9
    penalty = penalty + w3*(maxJerk - 0.9);
end

cost = - w1*SoC_final + w2*(time_elapsed) + w4 * abs(total_distance - distance_final) + penalty;
disp("Cost function =" + cost); 

vLimVec = getVelocityLimit(distanceData, vLimHard); 
c = speedData - vLimVec;
ceq = throttleProfile .* brakeProfile;
end

Answer 1

[Shantanu Dixit]

Hi Gabriele,

If I understand your query correctly, the throttle and brake pedal vectors remain exactly as your initial guess throughout the optimization. In other words, they do not change during the fmincon iterations. Here are a few points to check that might help diagnose and resolve the issue:

• Hard Equality Constraint on Pedal Signals: As a potential workaround you can introduce a penalty term in the constraint : 'ceq = throttleProfile .* brakeProfile', which forces the product of the throttle and brakes signals to be exactly zero at every time step (enforcing that both the pedals are not pressed simulataneously). If the initial guess 'u₀' already meets the condition, then a deviation from this will violate the constraint and 'fmincon' may stick to 'u₀' to avoid incurring a penalty. By replacing this hard constraint with a penalty in the cost function allows some flexibility while still discouraging simultaneous pedal engagement.
• Sensitivity of Simulink model: 'fmincon' uses finite‐difference approximations to compute gradients: https://www.mathworks.com/help/optim/ug/fmincon.html#mw_14804fca-69c2-4fd5-8754-1794951ff1da. If the model is not very sensitive to small variations in u (due to the fixed-step size or numerical rounding) the estimated gradient may be nearly zero. When fmincon sees a flat cost function, it will not update u significantly.
• Finite difference options: You might consider increasing the finite difference step size by setting the 'DiffMinChange' option in 'optimoptions': https://www.mathworks.com/help/optim/ug/fmincon.html#busog7r-2. If the cost function only shows meaningful variation for larger changes in u, then a larger finite difference increment can help 'fmincon' detect a descent direction.

Additionally, it might be useful to review this guide from MathWorks on troubleshooting solver issues: https://www.mathworks.com/help/optim/ug/when-the-solver-fails.html

Hope this helps!

[Gabriele]

Thanks for the reply.

I solved the problem by changing the form of the problem. It was caused by:

1. Input size: x0 was too big and fmincon could not optimize it
2. Fmincon, at first tried to change x0 with small variations and this did not lead to substantial changes in the final result

In any case, your suggestions will be very useful, so I will try to remember them for the next time.