FOC low speed stuttering

[mjc506]

What sort of numbers are expected from lastFrequency? Turns per second? Degrees per second? Digits per second? Electrical or mechanical? Sorry, found it - resolver turns per second.

Speed output from the observer code is just integrator1*constant - by default 1/2pi which gives turns per 0.1 seconds.

Made the code edit, will test tomorrow before submitting the PR.

[mjc506]

That's better, working now...
https://github.com/jsphuebner/stm32-sine/pull/9

Seems to output a 'smoother' speed reading, especially at low speeds. Also seems to handle fast speed changes as far as I can test here (grabbing the motor shaft at 1000rpm hurts, but the speed reading appeared to drop equally quickly haha)

Same comments as above re pot and pot2, still not found the cause of that yet.

[johu]

You need a torque measuring glove for that
Will try it on Touran next week, currently my wife (finally) uses it for commuting, don't want endanger that

[mjc506]

haha at least it was only a pulley rather than a gear

Yes, nothing to discourage that!!

[mjc506]

Found the cause of the runaway on braking - first was my plugging in my phase wires backwards, second was that lastFrequency must be absolute - must not go negative.

Updated binaries attached! And I've removed the previous ones from the last post.

Edit: Apologies again - these were the wrong binaries, see below...

[bexander]

I can't get this SW to work? I get 0V udc reading and hence no inverter start.
I reload 5.0 and everything works.
Am I missing something or is there a misbehavior in the SW?

EDIT: I uploaded .bin using the web interface.

[mjc506]

That sounds like I might have uploaded the 'motorcycle' firmware instead... Apologies, give me a few minutes and I'll double check!

Edit: Yes, I'm really sorry, that was my 'motorcycle' firmware. Corrected binaries now double checked and attached...

[bexander]

Now it works.
Unfortunatly it has no effect on the stuttering and now it is also unstable at standstill. I can see an increased current draw when selecting a direction compared to neutral and can also feel it in the car.
Some plots to illustrate:

Test SW, unstable angle when selecting a direction.

5.0 SW, very stable.

Test SW, interesting jump in angle, pressing the brake the whole time so no motor movement.

Test SW, for angle noise comparison

Any other plots that can be helpful at this point?

[mjc506]

That's weird, not seen that on my setup, although it's only on the bench. I'll have another play when I get home.

So you have <0.5degree noise with the 5.0 (atan2) software? I don't expect the observer code to give a massive improvement in that case.

I can't explain the jumps in angle with changing direction. There's no 'direction' input in the angle code, only thing I can think of is some very small movement of the motor getting in there? (Do you have idle switched on?) But even if so, that much change in angle isn't great.

Could you try plotting angleobs and angleatan? This should confirm that both output the same angle, and any instability in the observer code compared to the atan2 code.

One other question - did you choose 'TIobserver' for 'anglemode' (beneath the dropdown to choose the encoder type on the web interface)? It defaults to the atan2 code.

[bexander]

Ok, I totally missed that I have to change a parameter... There is then something else in the test code making it unstable. I don't expect the direction signal to be the cause, but rather the fact that the inverter starts outputting PWM, hence driving the motor.

I think we can leave the jump in angle for now. Not the main issue. There is of course some backlash in the gear reduction etc so the motor can turn slightly even if I'm pressing the brake.

I get the same instabillity with both atan2 and TIobserver. However with TIobobserver I get no observable noise on angle...

atan2, angle left, angleatan & angleobs right

TIobserver, angle left, angleatan & angleobs right

Angleatan and angleobs seem to agree but there is a about 90 degree angle difference between angle and selected angleatan or angleobs?? Is this due to my number of motorpolepairs(4) or resolverpolepairs(2)? And what does the angleofs do, default to 2048? Could this give an 90 degree offset?

[mjc506]

My fault, should have pointed the new parameter out

The instability is strange, I'll dig into it when I'm home and see if I can find a cause. I could also put the new observer code into 5.0 perhaps as a test.

Ok, no noise with TIobserver is good, it's doing what it's supposed to (although I don't think your previous encoder noise was bad at all!)

angleatan and angleobs are both 'resolver degrees', whereas angle is scaled to electrical degrees - it won't (shouldn't) just be a fixed offset, but unless you can turn the motor fairly slowly through 360deg it might look like an offset - in your case, electrical degrees = resolver degrees * (4/2) (or angle = angleobs * (motorpolepairs/resolverpolepairs) or angle = angleatan * (motorpolepairs/resolverpolepairs))

Angleofs - do you mean sincosofs? This is also mine (but in Johannes's code now too). It only affects those with encoders (not resolvers etc) and just allows setting the 'midpoint' of the encoder output if it's not centred on 1.65V

Thanks for testing

[bexander]

Yes, the instability is strange. I'm thinking that it might not be caused by your additions either.
If you can create a .bin file of the SW before you added your changes I can test with that and then we will know if it is caused by this or something else?

Ok, nothing strange about the difference between angle and angleobs, just me not understanding the inner workings of the SW...

Correct, I mean sincosofs.

[mjc506]

Here's a few .bin files - all 'pre observer' code, at various stages after 5.00, with 5.03 just before I added the observer code.

f23c855 is 5.03 (latest) without the observer code
c038762 is 5.03 without the ADC sample time changes
f1c7897 is 5.00 plus some additional IDC filtering (and the sincosofs, which shouldn't affect you)

There are other commits between those, but those seem the most likely...

[mjc506]

If you're bored, try the attached too - This is the last 5.03, plus the observer code, plus the syncadv removed - this has direction as an input, and the observer code already accounts for the delay between reading a signal and processing it (although perhaps not adjusted to suit the hardware perfectly)

[johu]

Loving this! Good news that the dodgy syncadv may become obsolete. I think it was calculated to compensate 100us delay between sampling and processing.
viewtopic.php?f=7&t=153&p=3964&hilit=syncadv#p3964

[mjc506]

Yeah, that rings a bell. I'm not sure of the best way of testing which method is best?

Code: Select all

      uint16_t syncOfs = Param::GetInt(Param::syncofs);
      uint16_t rotorAngle = Encoder::GetRotorAngle();
      int syncadv = (frq - FP_FROMINT(10)) * 10;
      syncadv = MAX(0, syncadv);

      //Compensate rotor movement that happened between sampling and processing
      syncOfs += FP_TOINT(dir * syncadv);

      angle = polePairRatio * rotorAngle + syncOfs;
      frq = polePairRatio * Encoder::GetRotorFrequency();

vs

Code: Select all

      int32_t cos_sin_anglast = cos*SineCore::Sine(integrator2)/32767; //angle_last = integrator2
      int32_t sin_cos_anglast = sin*SineCore::Cosine(integrator2)/32767;
      int32_t sum_one = sin_cos_anglast - cos_sin_anglast;
      integrator1 += sum_one*K2/frequency;
      int32_t gain1 = sum_one*K1;
      int32_t sum_two = integrator1 + gain1;
      integrator2 += sum_two/frequency;
      int32_t sample_delay_comp = integrator1/(2*frequency);
      uint16_t obs_angle = sample_delay_comp-integrator2+16384; //digits, 2pi rad = 360 deg = 65536 digits. Offset and -ve to match original atan2 code - prevents need to reset encoffset
      Param::SetFlt(Param::angleobs, FP_FROMINT(obs_angle) / (65536 / 360));
      lastFrequency = ABS(FP_FROMINT(integrator1)/TWO_PI);

To be honest, they're pretty similar, although yours includes a fixed time delay which is probably better?

[bexander]

Ok, did quick test with results as follows:
stm32_foc_5.03_f23c855.bin, no instabillity
stm32_foc_c038762.bin, not tested due to above result
stm32_foc_f1c7897.bin, not tested due to above result
stm32_foc_TIobs_nosyncadv.bin, instable at standstill with a direction selected, same as with syncadv

My conlusion, there seem to be something going on in the TIobserver that leads to the instabillity.
Let me know if I can test anything else to assist.

[mjc506]

Brilliant, thanks for that. Gotta be the observer code... I will have a hunt...

[mjc506]

I'm really confused. I can't replicate this at all here (although this is only on the bench, but it's still a complete inverter/motor/encoder/etc setup).

Here's the TIobs_nosyncadv firmware that you had instability issues with running here: (angles on the left, direction on the right)

No steps in angle, or anything obvious changing when direction is changed.

What are your idle settings? (I have no idle set here)

From your previous images:

This is with the atan2 angle code, and 'only' a few mechanical degrees movement. Although using the atan2 angle calc, this is still using the observer speed calculation though (which then affects synadv)
This sort of makes sense - there will be a bit of movement due to play in the drivetrain and compliance from various bushings etc, so the motor could easily be turning a few degrees even with the wheels locked. That the movement appears to be in the same direction in forward and reverse could be down to the observer code outputting a (small) speed (absolute) by the firmware not changing its sign as the speed is lower than its threshold? Not certain why the stock firmware doesn't display any movement though - kinda ruins the above theory, but the 'movement' could actually just be syncadv being overly sensitive at low speeds...


The big step at the beginning is harder to explain...

My best theory is that this is down to the speed calculation in the TIobserver code - the observer sync advance wouldn't affect the atan2 measurement, and whatever is affecting it affects both atan2 and observer angles equally (and the 'shape' of the disturbance looks like the behaviour of the observer). I don't know why I can't replicate here though. (apart from no idle meaning no movement or pwm output on angle changes - it's difficult to hold the motor still)

Would you be willing to:

• Share your idle settings
• Try the attached 'stock_speed' firmware (this uses the original speed calculation)

Could you do a plot with angle, angleatan, angleobs and direction? (This can rule out differences between the two angle calculations, and also scaling behaviour to get 'angle')
I guess unplugging your motor phase wires and doing the direction test would get a 'true no movement' sample, but that seems rather excessive!

If the 'stock_speed' firmware works for you, then I can either implement a threshold like the stock firmware, or make the syncadv less sensitive at lower speeds perhaps? Or just keep the stock speed calculation

[bexander]

Here are my parameter file for the 5.0SW. Idle at stock -100, so should be deactivated.

Prius_MGR_FW5_00FOC_2021_03_31.json

(1.28 KiB) Downloaded 285 times

With the stm32_foc_stock_speed.bin the instability is gone!

Tested again with stm32_foc_TIobs_nosyncadv.bin, instability is back. Made a plot as per below. Had to move the car slightly to get the instability to start. Hard to see with this scale but there are a slight oscillation in angle.

stm32_foc_TIobs_nosyncadv.bin

Regarding the instability. I can hear it and feel it in the car and I also see an increase in battery current. It might be down to my combination of motor/resolver pole pairs, mass off the car, backlash in gearbox etc. Thats why you are unable to recreate it in your setup.

As you guessed, it seem to originating from the speed calculation.

[mjc506]

Progress

Ok, no idle. Which should mean no PWM at zero throttle, even in drive or reverse... Unless it's seeing movement and trying to regen? Your brakerampstr is 30Hz though, so it'd need quite a high 'speed' to be trying that. Other possibility is you're not actually sending 0 throttle? (I think you've checked that previously though, or am I getting confused with someone else...)

Either way, a partial solution (although I assume it hasn't fixed your low speed oscillation?). I'll have a play with the speed calculation parts and see if I can get things smoother.

[bexander]

I have not checked specifically that I actually send 0 throttle but if I didn't wouldn't I get the same instability with other SW? I can double check if you want me to?

Unfortunately I notice no effect on the low speed oscillation but I think this is a great improvment anyway. The difference in noice from atan to TIobs is substantial. So that is a good thing!

[mjc506]

No, you're right, I'm just clutching at straws

Yes, a shame, but one thing off the list of possibilities. Current sensors next?

[bexander]

Ok, so with 5.0SW, should I make a plot of the current sensor output looking for possible disturbances?

Just for my understanding of the control algorithm of the FOC. The only feedback is the motor position (resolver) and the phase currents, right? Or is the DC-bus voltage also an input to the control algorithm?

[mjc506]

I believe that dc bus has a small input (adjusts some variables to account for higher/lower than nominal voltage) but should be a fairly smooth input anyway.

Current and angle are the main inputs though, but the Clarke Park transforms and how they use the inputs far beyond my understanding really.

Have you tried John Volk's recent firmware? It 'softens' the motor response at lower speed and throttle settings, intended for the ldu, but I can't see why it wouldn't work generally?