- aditya mehrotra.

# chip updates: design updates on the controller and the system, we messed up [updates]

Updated: Apr 1, 2020

So I noticed online there's this lovely block diagram of the control system for the NEO PID motor controllers and etc.

This would've been nice to look at before coding everything...

Yes sometimes we really don't realize how many features the things we are using actually have! So from what I can see in this diagram, we're of course using the PID controller feature on the SparkMax, but there's two other features we aren't using. First, is the kF, or the feed-forward constant, I think that can help us compensate for gravity/things like that. And the Limit, which can limit the output voltage of the motor so the system doesn't over-current! Both amazing features I wish we were using.

But let's create a system analyzer to see if they actually do what we think they do. Creating a *linear *model of the system is a bad idea because this system is VERY not-linear. But there's a possibility we can neglect the affects of gravity based on some other assumptions and make it linear.

Now here's something interesting. Let's plot the torque required by the motor just to keep the part of the leg that's actually a problem up, the heavy part.

Now look at this, we can develop a formula and bounds of interest in the region of the torque exerted by the gravity mass of this leg in its area of operation. If we assume the leg with only be between 0deg and 90deg for theta_1 (a reasonable assumption), then the CoG of the leg will be between 56deg and 146deg roughly based on a previous calculation, and then we can say the torque is equal to the mass of the leg, times the cos of theta, times r, times the gravity constant and if we plot this on 56 to 146 degrees look what happens.

That is an incredibly linear plot, especially for something like a cosine function. Like waow, that's really lucky, but that *also* means we can linearize this function! And include it in our model! We can include things like the torque produced by the motor at certain voltages and speeds as well.

But we're not done with the LEG model yet. WE still need to include things like a FORCE from standing. Even though, we can model that more as a disturbance and not as part of the system. A large, disturbance, but a disturbance none the less. So we don't *need *to include that in the initial system model, we can *add that in later.*

Now what we need to do is *linearize *the cosine function and create a model that converts RMS Voltage input, to torque, to acceleration, to velocity, to position change, each dt.

After some *basic *linearization of the cosine function, here we go this is what we get. The torque required is -1.43...*Theta+2.28...=T. That's a linear function and frankly, it matches really really well with the cosine curve shown. The orange is the line, the blue is the cosine. In this region, we're working pretty well.

*Now what do we do?* Well we need to start making some other models and using the difference equations to start developing a basic model of the system. Now it's time for the motor/gearbox.

So now let's estimate some system and motor parameters. If we work on an estimate we derived in 2.12 that 30/pi=Kt*Kv, then since we know the Kv, and we googles R=36mOhms, and we can estimate the rotor inertia to be about that of a CIM motor at 7.75*10^-5, and we know some other relations we can say...

And we can also use the model that the I of the system is equal to the I of the leg + the I of the motor times the gear ratio squared so...

Now we have a model that tells us at a certain position, what is the acceleration based on a voltage we give it and the current position. We can integrate that twice to find the output position (this is in revolutions of the motor not theta of the leg but we can deal with that later).

Either way we now have a model of the system that could work but we need to start putting it together. In the form of a Laplace transform so we can actually plot the system on Matlab and see what the response is.

Now we have a full system transfer function based on our model. It should be relatively accurate based on what we made up for the motor and gravity models. Now what we want to do is make a bode plot of the system and analyze it, and we want to create a step response plot which is *more* of what we care about you know.

This is a very interesting Bode Plot because what this is saying is that at 0-frequency input (i.e. step response) we're at 0db gain (which is good which is what we want, we want it to go to the set point we give it not increase or decrease), and the PHASE is +180 degrees. Which means our phase margin is margin = +180deg+180deg which is 360deg. That's a large phase margin meaning for step responses it seems like we are stable.

I'm running that analysis by my friend Quang because I'm not sure that's correct but let's see what he says.

RAN THE ANALYSIS BY QUANG:

So Quang says this system is "pretty damn unstable" because 180 degrees is the same as -180 degrees. So we're literally AT -1 with this system. Which makes not much sense because the system is stable physically. I think the model is wrong we'll look at it later.

WAIT: I FOUND IT, it's a MATLAB ERROR.

We did the Bode Plot of the *closed-loop transfer function, *we want the OPEN LOOP ONE. Here's the *new BODE*.

So our phase at roughly 0dB is about -0.89 deg. Which means our phase margin is roughly. 180deg. Which means, yea this is really unstable none the less! I still think the issue is with the model because the system hasn't blown up to infinity in real life.

The step response proves how unstable it is. So we may need to do some PID tuning or fix the model. Very unstable, yes, mmmmm!

Yum. Let's fix this later.