zii

I have not looked at those, but I am somewhat scared of the low level configuration that would be needed by other microcontrollers (non-STM32), which I would have no experience. But I would love to read the code, if it is easily available... I see You have posted about this also on endless-sphere.com . @lizardmech, have You extracted / published the code that comes with that MCU. OK, Thank You for adding me. Though, I do not currently see any need to specifically change things in your branches - as I have pushed my changes to my fork (also merged your added comments) & it is available there if anybody wants. I did record in arrays 1000 samples of motor_rotor_position, id, iq, hall_position (respectively in plot) and then transmitted them to computer via bluetooth. Half of the screen is with lower rotational speed, the other - with higher. id and iq appear to be quite "noisy". As I did value-saving in fast loop ( @ 20 kHz ), I interpret those peaks as the id, iq value before being averaged by EMA filter. You can see that the maximums and minimums for that periodic waveform of iq (disregarding non-filtered values of iq), correlates to the hall sensor position waveform. I think that this oscillation of iq value should be eliminated before continuing to balance controller. So I think it would be worth for be to do what @electric_vehicle_lover suggested: So I have a question - for what exactly do you depend only for that "once per 360º" value? I might try to automate all the "motor rotor correction angle" calculations, and then the hall sensors could be calibrated individually much easily.

@electric_vehicle_lover Ok, so firstly, I have pushed my adjusted code onto this new branch on my fork of Your code. I named one of the commits such to indicate that it was the one used to get the following plots from SerialPlot. (BTW, as I am using OS X, I had to compile SerialPlot myself, which took me almost a day to find all the problems with libraries, cmake & code). As I said previously I did rename a few things the "my way"; also the tabs that I use for whitespace somewhat makes it now a bit harder to follow actual diff's not just whitespace changes. So... I did try to do similar tests to what You had done and plot motor_rotor_position, interpolation_angle, interpolation_sum and interpolation_angle_step. In the following plot You can see values from when I (with pot) decelerate motor until it goes into reverse direction and keep it there (with practically slowest speed that the motor still rotates). And then in the motor_rotor_position part of the plot You can see how interpolation manages to start and track angle only after single electrical cycle. In the next one I tried to torture the interpolation part with rapid pot turning at slow speeds. So after that I also did test similar to Your other plot with id, iq, correction_value, motor_speed and duty_cycle (overlayed & multiplot respectively); as I use power supply with current limit set to 850 mA there are times where You can see that it has kicked in: Thus far it doesn't seem far from what You got. But now I checked what happens with id, iq values at slow speeds and this is what i got (which I did not expect): The slower the motor rotates, the greater the amplitude for id, iq oscillation. I did not expect it to be so bad. In this last plot at the middle time of the time axis the motor has stalled. I remember testing original firmware long ago, and seeing that it manages very smoothly and continuously to slow down wheel with great torque to zero speed (I was applying force with hand). I also remember that it seemed to me that the controller had some minimum speed, below which it would NOT actively regulate (speed would slowly only go down), but it still managed to do the continuous slow-down. Is it correct to say, that currently set_pwm_duty_cycle(target) is basically a constant torque controller, not a constant speed controller, thus low values of torque (or duty_cycle or potentiometer value) obviously translate to the fact that I can easily hold it and it won't be able to "escape" my hand's hold? What does everyone else think about this FOC slow speed behaviour? P.S. I will now try to do some more tests of my own...

@electric_vehicle_lover OK, I got the motor running smoothly quite easily by the procedure You stated - manually calibrate MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT and the ...LEFT one as well. Here are the values that worked for me: #if MOTOR_TYPE == MOTOR_TYPE_EUC1 #define MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT 5 #define MOTOR_ROTOR_DELTA_PHASE_ANGLE_LEFT -52 About Your question regarding my purchase of the board(s)... I'll tell a little more of my backstory: Almost a year ago I was asked if I could develop electronics and firmware for something similar to electric unicycle, so I was given few of these boards. As I, quite frankly, did not estimate correctly the time this all would take (given, I'm also studying at university, and have not previously done PMSM control), I have not finished the project to this day. In the year, however, I did try to port the VESC code to non-ChibiOS STM32F4 ("bare metal"), read a lot of publications/materials about FOC control, state observers, SVM, PMSM. So, about STM32 flashing - as I remember I also wired JLink programmer to NRST pin of the MCU. So there was no problem with that back then. Now I don't need that NRST pin, as I had to fix a non-working board from multiple non-working, thus I used hot air to resolder the same MCU I used a year ago. So now I read your code more thoroughly and most of it makes sense to me. In few places I didn't understand what was the idea of that part of the code. For example, pwm_duty_cycle_controller.c:420-421 - what is the idea behind this re-calculation. in the PWM_PERIOD_INTERRUPT() interrupt, I tried to follow the TIM3 setup code, and it seemed to me that it was configured to fire event only a single time per upcount + downcount (so as no if(...) would be required), and I can confirm with an LED and oscilloscope, that it indeed fires only once per 50us cycle. (Actually it did fire twice if I did turn the LED off after TIM_ClearITPendingBit(TIM3, TIM_IT_Update); , but that seems understandable) I don't fully understand the part with #define DO_INTERPOLATION 1, which You have currently implemented in place of an observer. To my understanding (and correct me if I'm wrong), duty_cycle (by your naming convention) sets the SVM PWM amplitude, which effectively sets the power that should go to the motor, and by turning potentiometer to some value, MCU just tries to put current 90 degrees ahead of the current motor angle, such that all the power goes into torque, so effectively, it just tries to run it as fast as the friction and electrical losses cancel the power put into it. And (disregarding two possible directions) for low potentiometer values, it will rotate slower, because the losses are lower and for higher potentiometer values it will rotate faster as the losses become higher. (BTW, I'd call duty_cycle something like "power" / "amplitude", as the actual duty cycle of the PWM changes as per SVM). Moreover, I tried cleaning up / refactoring some of the code for me personally to be easier to follow. I could do a pull request (like this), but I did not create a new branch... What should I do? I would appreciate some help in this, if possible. Little bit about what I noticed in the code: About the SVM waveform: I saw that it was not generated to cover full amplitude of 0 to 1800. Also, the 0th element of array is not 900, so at angle 0, the SVM angle is not 0. In my SVM version I corrected these things. I think that this corresponds to " -1 " you have in https://github.com/EGG-electric-unicycle/firmware-gen2_boards/blob/modifiedFOC-motorMicroWorks30kmh/motor_foc.c#L145here. Also, there were some if-else statements, for which if and else parts did the same thing. And that same code copied 3 times with 1 parameter change (I did put it into inline function). And then I checked, what You were printing out in every 10th FOC_slow_loop() iteration. And for me i_d, i_q values are not stable at all, which I expect to be almost constant. Cheers, Zigmars

I attach a photo of my board, I got it around a year ago and I think this one is from MicroWorks. I tried to do what You suggested and did manage to get motor to run with potentiometer speed control (I did have to set MOTOR_TYPE to MOTOR_TYPE_EUC1). To power the board I used a Lab PSU, with a 3A limit (@ 64V) and noticed that: at slow speeds there is irregular / not so smooth motion of the motor in low speed region current is drawn much more aggressively than past some speed threshold, after which the current draw seems to be as good as with original Chinese firmware going from low speed to higher speed, that threshold (in previous bullet) is at higher speed, than going from higher to lower (some hysteresis) there is asymmetry such that in one direction the speed threshold for when rotation gets smooth is much higher than in the other To my thinking, everything except the 4th point could be attributed to the fact that speed/position detection at low speeds isn't very good with either motor-mounted hall sensors or ACS712. What do You think, is that so? cheers, Zigmars

Hi everyone, Wonderful work you have done here, including the documentation. (Especially I love those great videos on control theory. Nice find.) I am trying to run latest version of this firmware (modifiedFOC-motorMicroWorks30kmh) on a 1st generation board (I think it's 1st gen... well, it's the one with a single XL7001 12V, 5V regulator). What I want is to try and reproduce similar behaviour as the original Chinese firmware (just on a bench setup, not driving it ). I commented out the section, which waited for some potentiometer value in the main.c and if I've understood correctly, what else I should do to get the desired behaviour: (1) set the balance PID coefficients; (2) set MOTOR_TYPE accordingly. I was wondering if anybody could (a) say, am I missing something else that I should modify in code; (b) tell what are PID parameters that have worked for You. cheers, Zigmars