The double Gordian knot of current_sense

Sorry I thought it’s the hoverboard motor.

You divide it by 2 if it’s wye

…soon :grimacing:
I found a way to slow down the whole process including immediate direction changes.
Have to test it with hall sensors, but they can’t be worse than the AS5600…

Only if you need to know the resistance of a single phase for whatever reason. The voltage-based current calculation doesn’t care whether it’s delta or wye, only the total resistance from one terminal to the other. Basic Ohm’s law. The two equations in my last post are literally all there is to it. It’s amazing how well it can work with such a straightforward approach.

I’ve been measuring the resistance on my motors with a basic multimeter and getting good results. My meter only has one decimal place and my motors are in the 0.1 to 1.2 Ohm range, so with 17 Ohms you should have more than enough precision. There must be something unexpected going on. But as said previously, you really shouldn’t have to be fiddling with this when you have hardware current sense.

1 Like

All the PID values are default values for faster MCUs. But I also read, that I should divide “my” PID values by phase_resistance, when I use DC_current instead of voltage controlled torque.
I have a lot more to test, before I run it on the hub motor

I did that and it had a big impact.
But I also figured, that a phase_reistance < 1R would work the wrong way round if someone would take that rule literal. (eg hub motor with 0.3ohm would tripple the P and I coeff)