suggestions for the next release 5.17 -> 5.18

[Zapatero]

Getting closer to the OEM status!
Again some suggestions for the next release, as many problems already have been solved:

• Regeneration \\ Sudden Regen
  The biggest issue i have left is the sudden regen above 7K RPM. This is a real safety-issue for me!
  Duscussion is here: viewtopic.php?f=7&t=2226
  .
• Regeneration \\ Not consistent
  Regeneration is not consistent. I Think it is just not linear and there needs to be a formula placed that flattens the issue out. For Example Regen Is very powerful below 2000 RPM but has to be stronger between 2000 RPM and 3500 RPM, then it is stronger again around 4000 RPM.
  .
• Would REALLY love to see "idcmax" and "idcmin" values in the mappable overview, as i think they are essential, if not obligatory, for every built. No one should drive an electric car without these values!
  .
• I still have a minor rattle and shake here and there at low RPMs, but that's quite a bit bitching and moaning as it is pretty good now
  .
• Again some complaining about things that are already pretty good, but as a power thirsty person i just dont feel all the potentially available torque at the low RPMs

To sum it up, the Hill Hold, Field-Weakening, and much smoother throttle (especially in the downramp) of version 5.17R is totally awesome. If the sudden regen is gone i finally would give the car to anyone to drive it without further explanation as it would just behave like any other car that came from a factory!

[arber333]

Getting closer to the OEM status!
Again some suggestions for the next release, as many problems already have been solved:

• Regeneration \\ Sudden Regen
  The biggest issue i have left is the sudden regen above 7K RPM. This is a real safety-issue for me!
  Duscussion is here: viewtopic.php?f=7&t=2226

Hm... your post got me thinking.
My Lebowski controler has a setting that is called acceleration limiter. This limits acceleration to a band of say 7k - 10k eRPM/s which would account to somewhere at 1000rpm/s for 8 pole motor.

Could there be a function to limit acceleration/deceleration to some humane value above 7000rpm? Maybe that would solve that issue.

[johu]

I still think it has something to do with the d-current controller not transitioning quickly enough from, say, -30000 to +30000 digits for d-voltage. If you carefully come off the throttle at that speed, nothing happens, only if you come off quickly.

[geduxaz]

and where is 5.17 published? i see only 5.14

[johu]

It isn't really
viewtopic.php?p=35796#p35796

[Zapatero]

I still think it has something to do with the d-current controller not transitioning quickly enough from, say, -30000 to +30000 digits for d-voltage. If you carefully come off the throttle at that speed, nothing happens, only if you come off quickly.

I can certainly say this is not the case for me. Doesn't matter how gentle i let go off the gas, the strong regen occurs.

[johu]

ok, that's interesting. Maybe I'd always been so gentle that the car coasted down to a non-critical speed. Would be interesting to test on a downhill, didn't see any in Ulm though

But it explains why the extra-slow ramp from 3 to 0% didn't help

[janosch]

[*] Would REALLY love to see "idcmax" and "idcmin" values in the mappable overview, as i think they are essential, if not obligatory, for every built. No one should drive an electric car without these values!

Zapatero I was just looking into this again, as I wanted to set idcmin & idcmax as described here: viewtopic.php?f=13&t=370&p=29370&hilit= ... ion#p29370

But I don't have TX/RX buttons in the 5.14 firmware (also not in 5.17 I think) next to idcmin & idcmax, did you change them from PARAM_ENTRY to VALUE_ENTRY to be able to define the mapping and update via CAN?

Edit: Just realised, I can just set it like here with the command string:
https://openinverter.org/wiki/CAN_commu ... IO_via_CAN
(but I think they should be in the Spot value section so they can be set with buttons, maybe I will make a PR)

[johu]

I won't put them in spot values, as some people might want to program static limits.
The better solutions is the reworked ESP gui which allows mapping parameters to CAN. But that still has some quirks so it's not official yet
viewtopic.php?f=5&t=1673

[johu]

Tested the field weakening some more.
Now I found when I disable FW completely the controller would start oscillating at around 4500 rpm. The more KI, the more oscillation. Now, surprisingly when I raise KP the oscillation pretty much goes away. With curkp=50 it spins up to 6500 rpm without field weakening.

I tried the modified FW controller that aims to limit uq amplitude. Don't really think it worked, I get over current shutdown when coming off throttle at high rpm.

[celeron55]

I'm going to say if you get that regen issue somehow sorted, it has a high chance of also getting us further with the MGR. I think something about low throttle (= low Iq current) field weakening is broken in the FOC firmware.

[catphish]

Additional suggestion for 5.18:

• Autopilot with full self driving

[arber333]

Additional suggestion for 5.18:

• Autopilot with full self driving

Well maybe not directly. But lets put some command interface open for this as you can use UAV Pixhawk autopilot in rover mode. It could use CAN for commanda and drive remotely...

But i wouldn know why would you whish that as i fully enjoy my driving experience...

[Bratitude]

Well maybe not directly. But lets put some command interface open for this as you can use UAV Pixhawk autopilot in rover mode. It could use CAN for commanda and drive remotely...

Or open pilot https://github.com/commaai/openpilot

But i wouldn know why would you whish that as i fully enjoy my driving experience...

lots of hwy driving in North America. It’s not generally a joyful or restful experience. These systems are actually really nice to have.

[johu]

I'm going to say if you get that regen issue somehow sorted, it has a high chance of also getting us further with the MGR. I think something about low throttle (= low Iq current) field weakening is broken in the FOC firmware.

Well today was special. We drove some 250km to pick up some solar panels. I think I must have forgotten the new FW software on the inverter. So I was overtaking, meaning full throttle above 6000 rpm with low battery voltage. When I let go the throttle car would accelerate further! Motor heated to 90°C within seconds, likewise the battery from 25 to 40°C. Hope it wasn't damaged too much. Anyway, the brake is always stronger so I could stop safely. After that BMS was confused and gave me 15 kW power limit (reason: CapDrop), otherwise car drove normal again. You guess I stayed away from high revs after that.

It was still amazing to see how much torque this motor can develop even at high revs and within the 900A current limit. Probably shows once again that something is not done correctly in "standard" mode, so celeron must be right.

@arber: kind of thought about your emergency stop button after that

EDIT: anybody spot the difference?

Code: Select all

esum += FP_FROMINT(((ylim - y) * frequency) / ki); //anti windup

Code: Select all

esum += FP_FROMINT((ylim - y) * frequency) / ki; //anti windup

This well meant fix was supposed to further reduce integrator windup. Now FP_FROMINT macro is applied to (ylim - y) * frequency and before it was applied to ((ylim - y) * frequency) / ki. This leads to integer overflow rather quickly. Just surprised it didn't trigger an over current event.

EDIT2: after a nights sleep I thought about this further. So the inverter was basically dumping full amplitude onto the motor but this did not lead to over current (900A) or fuse blow (350A). The only explanation for this is that the battery could not deliver any more current so the closer I came to a halt the more it was basically short-circuited! Thats why it heated up so fast. From experience, does anyone think this one-time event will cause any long term damage? Before this the delta of highest to lowest cell was 10 mV, now it's roughly 20 mV

[johu]

I have now changed the PI code again

Code: Select all

   s32fp err = refVal - curVal;
   s32fp esumTemp = esum + err;

   int32_t y = FP_TOINT(err * kp + (esumTemp / frequency) * ki);
   int32_t ylim = MAX(y, minY);
   ylim = MIN(ylim, maxY);

   if (ylim == y)
   {
      //before esum += FP_FROMINT(((ylim - y) * frequency) / ki);
      esum = esumTemp; //anti windup, only integrate when not saturated
   }

   return ylim;

So now temporarily doing the integration step but only actually remember it for the next round if the controller output isn't saturated. Seems more robust and also less instructions.

I should also mention that I never released the faulty code, so you're all safe!

[arber333]

EDIT: hope your post was for fools day because if not... i just arrived from Amsterdam and i didnt thought of the date.

Sorry to bring you the bad news, but when i pushed the ampera cells over the low voltage limit once they heated up really fast. I left them cooling off for an hour or so. But later when i inspected them i saw the last cells in the stack were deformed. Even the last plate on each s8de was pushed outside. I would suggest you to inspect structure of your battery just to be sure.

iR seems to be the indication of battery overall quality and
I think if one pushes cells over discharge limit they will show permanent damage.

However i did notice selfhealing with Kokam cells. When i got some of them they were horribly deformed from overcurrent demand and i didnt wanted to just take them apart. So i left them assembled in winter cold for some months, sealed of course. In spring i opened container and surprisingly the deformation and bloating was gone on most of the cells. When i did cap check they all but a few retained 90% capacity. They still work in Mazda after 6 years.

If there is possible i would advise you to keep them outside in the cold and not drive them for several days. And later get a pulse charger and do some pulsing cycles at 0.5C if you have the time. Maybe that would break some dendrite crystals that cause cell decay...

Edit: you could move your statement and this comment under separate thread. Maybe someone would want to comment their experience.

[johu]

Yes will think of a new thread name and move stuff there.
No April fools, it happened yesterday.
So basically you have good and bad news then. I'll just leave the car outside (it's quite cold anyway). I think this whole incident was like 30s before I found a chance to pull over. I'd just overtaken a truck so you don't want to slam on the brakes in front of it. The temp sensors saw 42°C, at least that is still less than the 55°C that they are usually capped at. Might have peaked at more though. Will also inspect all wiring and crimps.

[EV_Builder]

Maybe we should add some run-time logic error checking.
- Like throttle off should result in amperage decreasing;
- Throttle off should mean lower revs (over time);
- maximum throttle signal change; (wire or ADC issues guard);
-


These type of guards/sanity checks can help with safety while maturing the product. It won't maybe be an instant failure but atleast if somethings cooking eventually it engages.

Basically we check behavior and that's always a good thing

[johu]

Yes, I thought about that also. It just has to be done in a way that the safety measures don't interfere with normal operation making it less safe/predictable.
So I thought about just shutting down PWM on
- gross exceeding of fmax
- Grossly failing to hit current control target for x time (that would have been the case in my scenario)

Throttle off doesn't necessarily mean lower speed, e.g. when going downhill

[arber333]

Yes, I thought about that also. It just has to be done in a way that the safety measures don't interfere with normal operation making it less safe/predictable.

Well i use acceleration limiter with Lebowski.
Could you have an observer set to some sane rate of change? It should not be part of the pwm process but rather on the side.
If the condition would be exceeded you simply suppress the pwm and keep the inverter function going so you can start into rotating field with some small % of throttle.
Anyone has any other idea?

[johu]

Just had an idea about this syncadv issue. Right now I am taking 8 samples of il1 and il2 in each PWM interval and then use their average for current control. Now it is already hard to argue how "old" that average really is. It is probably correct to say that it is half a PWM interval or 56us old.
The resolver is just sampled once per period, 40us into the period. So at the next period the age of that sample is 133us-40us=73us. So actually just 17us older than il1 and il2.
Implying that we would need to revisit the syncadv calculation in the first place. In 17us @ 100 Hz the "age-offset" would be 17us*100Hz*65536=111 digits=0.612°. (65536 digits=one electrical turn) or in other words 1.11 digit/Hz. Begs the question whether that needs compensation at all.

We could however ignore, say, the last 2 samples of il1 and il2 and thus make them "older", moving closer to the age of the angle measurement.

[johu]

So here is something for you to try. It has one new parameter, idiqsplit. When set to 100% throtcur would be translated 100% to d-current yielding no torque. 0% only gives q-current. Tune it to give best performance while keeping throtcur constant.

Please test some scenarios and start with syncadv=0 and fwkp/ki=0, so no field weakening to see how it behaves. Be careful, set a low ocurlim as I haven't tested it myself yet (the car is being used by wife herself, don't want to risk that)

[Dusty4]

Hey Johannes, I've given that firmware a go. I tried idiqsplit at multiple settings, they all responded the same. When coming off throttle above 7000rpm I'd still have around 20a positive current, when I try to brake through it it would progressively get higher to about 50a then at approx 3000rpm it would suddenly go to 0a. I thought it may have gone over overcurrent but there were no errors. Attached are my parameters, are there any other parameters you'd like set and plots that would be helpful
?

[johu]

Oh wow, so unwanted regen persisted down to 3000 rpm? What voltage are you running?