Results showing up as NaN

I have been working on a launch control simulation and something happened recently because the matrix z is returning only NaN values now... I do not remember changing anything in the script or the function. I have also attached below the main function used with the code... maybe you spot a mistake there...

global m g I h lR lF r LCREV_MAX LCSPEED_MAX 

LCREV_MAX = 12000;
LCSPEED_MAX = 35;

m = 295;                % mass of vehicle including driver
g = 9.81;               % gravitational acceleration
r = 0.23;               % wheel radius
I = 0.2645;             % tyre moment of inertia
h = 0.28;               % CoG height
lR = 0.765;             % Distance of CoG to rear axle
lF = 0.765;             % Distance of CoG to front axel

z10 = 0;                % initial x position
z20 = 0;                % initial linear velocity
z30 = 0;                % initial angle of rear wheel
z40 = 0;                % intial angular velocity of rear wheel
z0 = [z10 z20 z30 z40]; % initial conditions vector

t0 = 0;                 % intial time
tf = 6;                 % final time 

[t,z] = ode45('LC_eom',(t0:0.1:tf),z0);

x = z(:,1);             % position as first column of z matrix
v = z(:,2);             % linear velocity as second column of z matrix
theta = z(:,3);         % angle as third column of z matrix
omega = z(:,4);         % angular velocity as fourth column of z matrix

[Andrew Newell]

Unfortunately, LC_eom depends on several other functions, so there is no way of knowing. However, one of those global variables could be modified in an unexpected way by one of the functions.

[Alexandru Bortea]

Unfortunately I cannot upload the other 8 files due to the daily upload limit.. Is there any other way I could send those other functions?

[Andrew Newell]

You could combine them all in a zip file and upload them.

[Rik]

You should be really careful with global variables, they make debugging very difficult. It is better to use functions instead.

If you really need to use global variables, make the names very descriptive, so you avoid most of the unintentional changes.

For now I would recommend to use the debugger to go through your code step by step, keeping an eye on your workspace to see if anything fishy is happening.

[Alexandru Bortea]

I attached all files below. I have been trying to use the debugger and I am aware there are small errors in the functions, however, I do not see how the errors might affect the my z matrix (which is the one with NaN values).. Apologies if there are any obvious mistakes in my code, I am fairly new to coding..

[Stephen23]

Using globals is not going to help write reliable code, as the documentation clearly states:

"However, global variables carry notable risks. For example:"

• "Any function can access and update a global variable. Other functions that use the variable might return unexpected results."
• "If you unintentionally give a "new" global variable the same name as an existing global variable, one function can overwrite the values expected by another. This error is difficult to diagnose."

"Use global variables sparingly, if at all."

Globals come second on this list of bad MATLAB code practices:

https://blogs.mathworks.com/videos/2010/03/08/top-10-matlab-code-practices-that-make-me-cry/

And globals have been discussed on this forum many times:

https://www.mathworks.com/matlabcentral/answers/332403-global-variables-in-a-guide-gui

https://www.mathworks.com/matlabcentral/answers/14857-where-do-people-learn-bad-programming-habits-i-e-goto-global-and-eval

https://www.mathworks.com/matlabcentral/answers/51946-systematic-do-not-use-global-don-t-use-eval

https://www.mathworks.com/matlabcentral/answers/74626-how-to-declear-global-array-and-how-to-use-it

https://www.mathworks.com/matlabcentral/answers/319613-how-to-use-global-variable-as-local-variable

[Andrew Newell]

One reason you may be using global variables is that ode45 expects a function with two variables. However, that is easily handled using anonymous functions. For example, the function LC_eom needs m, I and r in addition to t and z. However, these are just parameters that (I presume) aren't changing while ode45 is running. You can define

function dz = LC_eom (t,z,m,I,r,)

in LC_eom.m and then, LCS.m, define

fun = @(t,z) LC_eom(t,z,m,I,r);

and use that in ode45:

[t,z] = ode45(fun,(t0:0.1:tf),z0);

[Alexandru Bortea]

Thank you very much for all the answers, I'll try to remove all global parameters and individually use them in the functions.

Answer 1

[Andrew Newell]

Here is one source of NaN's: In slipratio_fun with the initial value of t=0 and v=0, you have omega=v=0. The line

sx (abs(omega)*r>=abs(v)) = -1 + v./(omega.*r); % acceleration

sets sz equal to NaN because it's dividing by zero.

[Alexandru Bortea]

yes but for the next iteration, it should be fine from what I understand

[Alexandru Bortea]

After playing around with the function, I found out that if I put the condition before the others it does provide good values for the velocity. However I was still encountering the error "I needs to be same length as B in A(I)=B". So I came up with this... and it seems like it's working. Is is correct to do so?

sx (abs(omega).*r >= abs(v)) = -1 + v(abs(omega).*r >= abs(v))./(omega(abs(omega).*r >= abs(v)).*r); % acc
sx (omega<0 & v>=0)        = 1;                  % fwd with wheels rwd 
sx (omega>0 & v<=0)        = -1;                 % rwd with wheels fwd
sx (omega.*r==v)           = 0;                  % free rolling

[Andrew Newell]

The code seems fine, but I wonder if the physics is right. Note that the second and third conditions override the first condition, but then the fourth condition overrides the second and third. And there are two regions that are not accounted for. Try diagramming the regions on an omega vs v plot and you'll see what I mean.

[Alexandru Bortea]

Luckily this is a straight line simulation, meaning that the car will be constantly accelerating. However, thank you for pointing out, my formula for slip was wrong for the acceleration. I have now corrected that! Is there a way I could avoid the conditions to override the previous ones? Thankfully, I don't need it here but I have other more complicated functions that might show wrong results because of that (e.g. injcut_fun file included .zip in the comments above)

sx (abs(omega).*r >= abs(v)) = -1 + (omega.*r)./v; % acc

[Andrew Newell]

I think it's really a physics problem now. If you have two overlapping conditions with different results, which one is correct? I can't answer that without knowing more than I want to about the model. Sorry!

[Alexandru Bortea]

I should be able to deal with it myself! Thank you very much for helping me with the code part!!!

[Andrew Newell]

You're welcome. Glad to help!