• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 84 subscribers
  • Views 1243 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Inertia Estimation with InstaSPIN-MOTION

Sean Hanley
Prodigy 130 points
Other Parts Discussed in Thread: MOTORWARE

I am trying to use InstaSPIN-Motion to control a IPMSM to drive a small vehicle.  The motor is connected to a gearbox that connects to the drive wheels.  I've gotten it mostly working, but I am seeing 2 problems at this point that I think may be related.  First, when I accelerate from zero speed, or when I go from driving at a constant speed to a reference speed of zero I am getting a lot of loud chatter from the motor/gearbox.  When I finally do get moving there is a very noticable speed oscillation for the first 5 seconds or so that dies out as long as the load and Vref don't change.  If either of those change the process seems to start over again.

I tried increasing the SpinTAC bandwidth to deal with the speed oscillation, but that made the chatter at startup even worse.  Also this only happens when there is a significant load (The vehicle and I together probably weigh 400lbs+ and we are driving on flat ground).  If I put it up on blocks I don't seem to have any problems.

My newest theory is that the problem has something to do with the inertia estimate.  I first estimated the inertia with the vehicle up on blocks, with the motor attached to the gearbox.  (Inertia = 0.45544, Friction = 1.2742).

 I thought the speed oscillation might be because of the large increase in inertia when the vehicle was loaded.  I decided instead to do the inertia estimation under normal load (vehicle and passenger weight).  When I used these values (Inertia = 40.244544, Friction = 21.8908) the system became unstable at 0 speed with a lot of loud chatter.

I then tried the estimate with the motor not connected to anything (Inertia = 0.159, Friction = 0.8607) This seems to be the best result for the start up chatter, but the speed oscillation in steady state seems to be more pronounced.

One last point, the linkage in the gearbox is such that for the first 1/4 mechanical rotation, until the gears mesh the motor sees almost no load, and on reversal it would be the same thing, there would be 1/4 turn that would see no resistance and then the entire momentum of the system.

I'm thinking that I'm going to need to control the inertia (and possibly bandwidth) setting dynamically due to this "play" in the gears.

Has anyone come across a similar situation before?  I'd like to know if I'm heading down the right road before I waste too much more time.

Any insight is welcome.

  • 0
    Intellectual 960 points

    I have experienced similar results. When I'm testing my motor unconnected (low inertia), it starts and executes far better, although when i add an excessive load, I can sometimes get it in a mode where it halts, jitters, accelerates well beyond the RPM setting (i.e. setting might be 50, but it will spin to a guess of 500). Generally, a lower bandwidth has helped, though that has different issues.

    When I place the normal inertia on (i.e. the rest of the product, which creates added rotational inertia), the inertia estimates may be run, they seem fine and I plug these in. However, the system does not start well, nor execute well with this higher, compensated, inertia. I will experiment with lower/higher inertia values to see their effects. The fact that the inertia routine runs well, tells me that my custom control loop needs improvement, however the success of the lower inertia tells me the TI system might not compensate for higher inertia too well.

    I want the system to recover gracefully in overload conditions, rather than over-accelerating. I assume I can watch for the bad conditions and use a controlled response.

  • 0
    Guru 12800 points

    Sean,

    I think the chatter you are getting at zero speed is because of the backlash in the gears.  With sensorless, it cannot hold a zero perfectly, so it will move from one end of the lash to the other.  In your application do you need to hold a zero speed at the motor?

    In this application there is a lot of friction, what are the values for acceleration and jerk that you are using?  You could be saturating the speed controller which can cause it to ring a little bit when exiting saturation.  Try decreasing the acceleration ramp when changing the speed reference.  This will allow the motor to track the reference instead of acting like a step input.

  • 0 in reply to Adam D. Reynolds
    Intellectual 960 points

    > what are the values for acceleration and jerk that you are using?

    Adam, if I understand Sean's system, he is not using a velocity profile. Does the acceleration and jerk settings have an effect on non-profile systems? For instance, say the speed reference comes from a pedal that the operator pushes. Thanks.

  • 0 in reply to Bill McConnell
    Guru 12800 points

    Bill,

    The values will only have an impact if he is using the profile generator.  If he is using a pedal to directly set the speed reference to the speed controller than the profile settings don't matter.

  • 0 in reply to Adam D. Reynolds
    Prodigy 130 points

    Changing the max acceleration using CTRL_setMaxAccel_pu() definitely changes the acceleration even though I am setting the speed ref directly.  That hasn't solved my problem though.  I think I may be slipping poles on startup.  This motor is drawing more current than I expected.  I'm going to beef-up the board for more current and see if that helps.  

  • 0 in reply to Sean Hanley
    TI__Guru** 119670 points

    This actually sounds like what commonly happens in most traction applications when you start-up sensorlessly.

    I believe what you are seeing are more the effects of inaccurate angle estimation into the control system.

    There are 3 areas of importance: initial angle, low speed angle, and then the transition to FAST

    The angle estimate from FAST will initially be incorrect, and it will take some level of speed before there is enough Bemf and current feedback to produce a good estimate. 

    If you just command a speed/torque, assuming the load isn't too high you will generate enough of a torque (even if the angle feedback is incorrect) to cause enough rotation for Bemf feedback and for FAST to converge on a good angle, at which point you can drive the control system in a stable manner with effective torque capability.

    If you turn on ForceAngle it removes the FAST estimated angle from the feedback circuit and produces an angle estimate as if the rotor angle was rotating starting initialy at 0 radians at a fixed frequency  of  USER_FORCE_ANGLE_FREQ_Hz.  This causes the control system to produce a stator flux that rotates at a known rate (so it should be smoother) but it is not necessarily (and unlikely) to be oriented correctly for maximum torque generation as we have no idea where the real rotor flux is oriented. 

    What you will see is that if the stator flux is rotating, but the magnitude (Iq) of the vector is not high enough for the load, you will get a torque pulse.  The rotor will be attracted to the stator, but not enough force is generated to move and lock in with the stator, so the stator then advances too far ahead, the torque reduces, and eventually as the stator flux makes it's full electrical circle the rotor will actually be attracted in the opposite direction until the stator sweeps by and then it is attracted in the correct direction.

    You can play with this start-up a bit. I think you will find that having a high enough Iq (or actually Vq output from the Iq controller) and a slow FORCE_ANGLE_FREQ will give the best results.  But you may still get an initial first pulse backwards if your orientation is incorrect, and you could still experience some jerking.

    Idealy you would want to solve the initial angle (Initial Position Detection) issue. Starting at 0 radians just doesn't work well enough under full load.  The first thing we recommend is using Rs Recal or a direct Id injection to help align the rotor to an optimal orientation. But if the load is too high it will take a substantial Id injection to move the rotor. This does work very well in many cases. In industry this type of technique is referred to as align-n-go.

    We have developed and released a technique based on  High Frequency Injection that can detect the initial rotor angle position, however it only works with highly salient motors (which are specially designed and rare).  We are finalizing another technique that works with non-salient, standard BLDC / Surface Mount motors.  We are having tremendous success with getting a very good initial rotor flux angle with this technique. We will release this as a library in MotorWare that works with the InstaSPIN solutions.

    However, just having the initial angle doesn't solve all of the problems.  You still need to drive from 0 speed - through an area where you don't have a good angle estimate - and then transition to the FAST feedback when it is valid.

    During this initial start-up and low speed, even if you have a good starting angle, if you don't start-up with enough torque to actually move the rotor the stator flux is just going to keep rotating around (Based on ForceAngle since there is no valid estimated angle feedback), creating the original problem.

     

    Regarding the transition point where FAST can take over:

    1. this has to be tested for your motor and application, it's very Flux * Hz and ADC scaling dependent. It may be 1/2 Hz or it may be 20 Hz.

    2. You need to be aware that while ForceAngle Enabled turns off the angle output from FAST, there is another variable that actually turns off internal calculations inside of FAST.

    #define USER_ZEROSPEEDLIMIT   (0.002)    

    You need to end up setting this value so that USER_ZEROSPEEDLIMIT * USER_IQ_FULL_SCALE_FREQ_Hz <= 0.5 * USER_FORCE_ANGLE_FREQ_Hz 

    This insures that the FAST estimator is fully running below and up to the frequency where FAST may take over.

    FAST will only take over from ForceAngle (when enabled) once the estimated speed from FAST is > USER_FORCE_ANGLE_FREQ_Hz 

     

  • 0 in reply to ChrisClearman
    Prodigy 130 points

    If I had a mechanical brake on the shaft of the motor that engaged locked the rotor at a speed high enough to still get an angle estimate from FAST when stopping, could I use the last angle estimate at startup as the forced angle at startup rather than using 0 radians?  

    Then I would just need to figure out how much current I need to keep the rotor from slipping to the next pass of the stator.  Unfortunately that's going to change depending on a number of factors.  If I could remove the play between the motor the gearbox I would think I would be able to use the higher inertia and friction estimates that I got with the vehicle on the ground and moving.  With those estimates MOTION should command a higher startup current which should at least improve the situation.  Does that sound correct?

  • 0 in reply to Sean Hanley
    TI__Guru** 119670 points

    Sean Hanley said:
    If I had a mechanical brake on the shaft of the motor that engaged locked the rotor at a speed high enough to still get an angle estimate from FAST when stopping, could I use the last angle estimate at startup as the forced angle at startup rather than using 0 radians?

    Yes, this is something we think will work. If you can "save" a close angle value right as you stop, and seed this into the estimator before you start-up again, it will certainly act as an "IPD estimation".

    Starting up in Torque mode, or with the speed controller saturated will certainly improve the situation.