Add motor characterisation

[mcells]

This adds a function to characterise a motors resistance, d&q-axis inductance and electrical-zero-angle.
It should run on all platforms, as long as there is working current sensing (and optionally an angle sensor for the electrical zero only(!)), but I can only test on the ESP32, so it would be great if someone tried this out on other micros.
And perhaps someone could try the stepper motor support, because I´m not sure if the measurements will need a correction factor there.

In my experience, the resistance measurement is quite accurate for gimbal motors, with maybe -+10% for a drone type BLDC.
The inductances are less accurate and vary about +-10% for gimbals and can occasionally be as bad as +-20-50% for drone motors, but doing several measurements will usually reveal a pattern.

The electrical zero is a datum that pretty much comes out as a side-product of the d&q measurements, which is why i´ve included it. Whats very useful is that during the measurement the motor doesn´t move (or shouldn´t, at least), so the electrical zero is less dependant on low friction and pole pairs. As is, it can vary a bit, but this variance will not increase with higher pole count.
Due to there always being two possible values, we cannot easily determine the true zero, so we still need an approximate zero. That´s why this won´t replace our current zero finding method, only supplement it.

This is something we wanted for some time, but the question is whether my implementation is appropriate or a bit overkill.
I know the theory behind this code isn´t very simple, but I´ve tried to make the code somewhat understandable.

What do you think?

[runger1101001]

I love it. Thanks so much for sharing this.

I will try it out as soon as I can (traveling at the moment), I should be able to try it on a variety of our architectures.

One thing I wonder is if we could split it out into a separate class, rather than having to put it right into FOCMotor?

[askuric]

This is awesome @mcells, thanks a lot!
I'll make sure to test it too, on the steppers as well.

One thing I wonder is if we could split it out into a separate class, rather than having to put it right into FOCMotor?

I actually like it in the FOCMotor, at least for now. As we will eventually refactor the calibration part in the future we can separate the calibration methods in their own classes or something else that will suite the paradigm. What are your thoughts @runger1101001

However, it might be worth checking if the additional memory requirements are too much for arduino UNO and atmegas328 or even stm32f103 chips like for the bluepill. But they seem to compile well in the CI so that is a good sign.

[mcells]

Thanks!

in the future we can separate the calibration methods in their own classes or something else

This would be my prefered way of doing it, because else a separate class would mean even more declarating of objects than is already necessary at the moment.

atmegas328 or even stm32f103

I just tried compiling the example sketches with added characterisation and I´m afraid it won´t really fit onto the 328, even when stripping out the commander.
The stm32f103 should fit, I´m at about 88% flash usage.

Without explicitly calling or referencing the function it doesn´t use any flash, so the 328 will still work without it.

[runger1101001]

I actually like it in the FOCMotor, at least for now. As we will eventually refactor the calibration part in the future we can separate the calibration methods in their own classes or something else that will suite the paradigm. What are your thoughts @runger1101001

I'm easy, if you prefer it there.

I prefer it outside, because I think there could be many different implementations of it, and we'd like to make it "swappable" for the user. But as you say, we can always move it later.

Another big concern I had was regarding the ATMega 328P, but you guys have already checked it and confirmed it compiles as long as you don't use it, so ok for me.

I think a future step also needs to be to integrate it into Studio and WebStudio, and our Python API, so these tools can use the output. That also requires some thought.