None of the detections work. I've tried increasing or decreasing the current, adapting the omega etc etc, but nothing seems to work.
I have the impression that the code ramps up the rotation speed way too fast for the motor to follow. Is there a way to adjust this?
OK. Update: The FOC hall sensor detect works. Then with say 2A current setting the motor starts to turn. It runs fine with about 2A.
I just realized: I'm running with the FOC parameters detected with my C8085 motor: R=16mOhm, L=6.84mH, Lambda=4.3mWb.
This motor has something like: R= 24, L=180 (measured by VESC6 360 before with other hardware), Lambda = 11mWb (not detected/measured, transported from other hardware).
So... Any suggestions on how to get the VESC6 do detect this motor better?
I have now entered the 11mWb and adjusted R and L values into the FOC tab. This still causes the VESC to do something wrong when the speed goes above whatever belongs with 33V. Ah. Just above the "2500" for sensorless. This event then regenerates enough energy into my lab powersupply to cause an overvoltage trip.
Not sure if I'm happy enough about all this that I dare try this with the 100A nominal batteries....
The flux linkage detection is a tricky part to get right since it has to be universal enough to spin up any motor without knowing anything about the motor, and there is a huge variety of motors. Did you notice if it makes a number of tries, or does it only run once? It is supposed to make up to 4 tries with different settings.
For FOC to work it is very important to get the resistance and flux linkage right, at least within 5 %. If your motor has 12 poles and 15 kv as you wrote in the other post 11 mWb sounds completely wrong. You can roughly calculate the flux linkage from the kv and number of poles with the formula
60 / (sqrt(3) * poles * pi * kv)
for your motor this gives
60 / (sqrt(3) * 12 * pi * 15) = 0.058903 Wb = 58.903 mWb
The detection box can still calculate the kp and ki parameters. The observer gain can be calculates roughly as 1000 / (lambda^2) where lambda is in mWb. In your case this would be 1000 / 58.903^2 = 0.28822
Regarding the detection, can you try if there are any BLDC parameters you can set in the integrate mode to make the motor spin up with BLDC? Because that is what the detection does. Detection starts by using BLDC in integrate mode to get the motor spinning slowly and then switches over to delay mode which does not have any parameter dependencies but has problems starting motors.
Hi Roger, I'm pretty sure it's possible to drive your motor. Benjamin will probably be able to give you advice. What you can do is the following:
Go to ADDITIONAL INFO and fill out the description fields and ad in a brief description. Try to be precise but brief.
- Motor manufacturer
- Motor Model
-Pole pairs
- Resistance
-KV
- etc.
If you go to "File", you will see that you can export the Motor XML.
Send this to Benjamin. We can also try to make a directory for the files.
The reason behind this is to help others, having the same motor, not having the same issues again. Once you and Ben figured out the best values, they can be published on the VESC-Website in XML format or can link straight into VESC-Tool. After a while there will be a list of beasty motors and the best settings for them available, which is a bonus for everyone in future.
Frank
Re: Tries:
I would have guessed from here that it does THREE tries. But you might be right, four. The later tries seem faster. So the motor wobbles less. So where it tries faster and faster, I would think it helps for my motor to go the other way.
When I tried to drive a harddisk motor, something like 15 years ago, knowing too little about BLDC motors, we managed in the end. Completely openloop. The trick to get a nice startup was to ramp up the field rotation and the field strength at the same time. For harddisk-motors of course the scale of the situation is very well known. So in this case, if you ramp up the current to the provided test current, while you rotate the field at 60 ERPM, I would guess that you catch the rotor. Next step is to slowly ramp up the speed. How slowly that is done, and what the end-value needs to be might be other parameters. But then I'd know a bit better how to tune the detection if it doesn't work. If during the first five seconds the motor doesn't start to rotate slowly, you need to increase the current. If then the motor stops while still making noises, the ramp up is too quick.
Consider that even if you're driving in FOC mode, you could mask out the driving of the third phase (for say 1/100 commutations) to measure the back EMF. Then you can algorithmically determine if you lost the motor or if it is still turning.
Re: The detection box can still calculate the kp and ki parameters
With the new interface I cannot change the boxes with the detected values. The Ki and Kp parameters are calculated when I hit "apply", right? But based on the (wrongly) detected Lambda value. .... I can only hit "apply" (= calculate) after a succesful lambda measurement. I switched motors and detected lambda there, allowing me to hit apply.
OK. I'll try starting the motor in BLDC mode by playing with the integrate mode parameters.
For "integrate" mode, there is also a "detect parameters", right? That one also doesn't work. What I remember is that the default value is somewhere like 52 or 62, but when I detected it with different hardware in the past I got a wildly different value like 1500. EDIT: Found my notes: Three BLDC detections gave integration limit: 1355, 1400 and 1434. And a coupling of 1426, 1735 and 1950. This was on different hardware, so it is possible that there were scaling issues.
In the end, I did manage to produce about 1kW of power in the motor. The battery didn't completely like me after that. :-) Tough being a battery. :-)
Did you try calculating the flux linkage and observer gain with the formulas I gave in #2?
The detection values help a lot. If you use them in BLDC mode, does it work then? I think you should reduce the coupling to 800 or so. If it works in bldc mode I can give you a firmware to try with similar parameters in one of the passes for FOC detection.
The best I got in BLDC mode is that it would spin up when I command 2A of current and give it a shove. I haven't been near the motor yet since your #2...
You gave me a formula for "observer gain". The Ki and Kp can "still be calculated by the detection box" according to you. I have not spent much time trying, but my first impression is that I cannot do that. As far as I know the parameters get calculated when I click apply and I cannot click "apply" without a valid (lambda) detection. I can detect a totally different motor, but what use is calculating those things with different parameters?
OK. I forgot to adjust the observer gain. I now have it smoothly accelerating up to 50V. When decelerating it has funnies with the duty cycle. I'm going to insert the calculated observergain.
http://prive.bitwizard.nl/VESC_TOOL_start_stop.png
I cannot find a way to recalculate Ki and Kp without having R/L/Lambda detected.
OK. With observergain changed from 53 (*10^6) to 0.28 as you suggested the funny spikes when slowing down are gone. Other funnies appear (IMHO).
http://prive.bitwizard.nl/VESC_changed_observergain.png
update: Yes, there are FOUR tries to spin up the motor in measure-labda procedure.
Edit: VESC_TOOL bugreport: The fixed-number-of-characters in the input fields is annoying. if I edit say 600 into 1500, I delete the 6, enter 15 and... the 5 is ignored because the input field is full.
Update:
http://prive.bitwizard.nl/VESC_5A_vs_10A.png
Is it possible to estimate the rotational energy in this motor from this picture?
My first guess is about 1000-1200J at the speed corresponding to 40V....
Update: I've given up trying to get the motor to spin with BLDC: I've swept the integration limit from 1500 down to 50 with te commanded current at 4A. I've also tried 2A for a bunch of values.
Because the result is less than binary (motor runs or does not run, but so far always: does not run), I have no clue if I should increase or decrease anything. I can just blindly try things and end up with the same result every time. I know the motor can run on 2 or 2.5A. I tried detecting (BLDC parameters) with 30A as well. Didn't overload the powersupply (capable of 10A .
> The observer gain can be calculates roughly as 1000 / (lambda^2) where lambda is in mWb. In your case this would be 1000 / 58.903^2 = 0.28822
I'm now moving towards my own hardware. As I doubt that you made the same pin assignment decisions as I did, I cannot upgrade the firmware right now. When I hit "calculate observer gain" in the old BLDC_TOOL, I get 5.6, and not the 0.288 that you calculated.
You should be able to calculate kp and ki if you only have the resistance and inductance. Apply will not work, but you can just type in the calculated values. There is also a separate calculate button to the left of the parameters that you can use to e.g. change the time constant and calculate again. BTW, your motor might work better with a higher time constant, such as 2000 µS.
BLDC Tool has a different way to calculate the observer gain, which does not work as well as VESC Tool. I spent quite a bit of time trying to understand the observer and finding a way to make it work with every motor I have. The new firmware also has an iterative approach to run the observer which works better in general, especially on motors with high ERPM.
I forgot to mention, if you got the motor running with FOC with the rough flux linkage estimation, there is a terminal command called
measure_linkage_foc
that you can use to measure the flux linkage in FOC mode. The only parameter it needs is the duty cycle to run with. I'm not sure since I haven't tried, but I think you can do the sensor detection first and then run this command in sensored FOC with a low enough duty cycle or with increasing the sensorless ERPM.
OK. So lambda does not come into play for the calculation of Ki and Kp? I missed the calculate button.
What sensorless-sensored cutover would you recommend? It's 2500 by default in VESC_tool and 2000 in BLDC_tool or the other way around.
My motor has really low Kv. High torque constant, lots of back EMF even at low speeds.
Isn't it more or less the case that once you get good ADC resolution on the generated back-EMF, then that's when you can switch to sensorless mode? So then the switchover should actually happen more or less like at 10% dutycycle. (My C8085 does 35kRPM. So 2000 RPM is only 6% duty).
Now that I can make the motor turn (because I managed to get hall-sensor-detection to work in FOC mode), I can make progress towards driving it with higher voltages and currents (I got 2.2kWh worth of HK batteries today... :-) ).
One of the things I'm a bit worried about is that the current waveforms are not even close to sinusoidal. Now I might have a signal integrity problem on my board, or the wrong opamps... stuff like that. So I compared things to what VESC6 samples and this is what I got:
Vesc6 gets: http://prive.bitwizard.nl/VESC_motor_current.png
My hardware gets: http://prive.bitwizard.nl/BLDC_samped_current.png
So my conclusion from this is: That seems to be normal. Still I'd like to understand why we're seeing such awful non-sinusoidal shapes....
P.S. Wouldn't it be a good idea to allow image uploads on the forum? I'm expetcting this is just a setting in the forum software, right?
Lucky you. I also ordered a lot of Hobbyking batteries a couple days ago, but after I did my order they told me that the packs are no longer in stock in the EU warehouse. Now I need to wait and hope that they will be in stock again soon.
Mh, both samples doesn't look very sinusoidal to me. So I don't know if it should worry you, when the VESC6s looks different than yours.
OT.:
So you are now using all three shunts of your hardware? Maybe I should search for your hardware and give it a second try. I don't even remember why I didn't tested it more. I think it was because of the lot of space that was not available in my skateboard and that I could not use my NRF nunchuk. But now I should have enough space in my bike. A higher voltage and current VESC would be a dream for all eBikers.
Btw.: I would also like to see an upload button for pictures.
> Lucky you. I also ordered a lot of Hobbyking batteries a couple days ago, but
> after I did my order they told me that the packs are no longer in stock in the EU warehouse.
Wasn't me! the ones I ordered are still listed as "in stock EU warehouse"
Benjamin sent me his "current state of the firmware" a few months ago, but I didn't have time to implement it on my hardware back then. So now I have more time, but I don't feel like putting in the hours to adapt old firmware....
OK. I've put in a bit more thought. The measurements were taken at "max RPM", that's when "funny" things start happening: you need more than the maximum available voltage applied at the top of the sine. This will distort the waveforms. I'll try to run at less-than-max speed next time....
The problem is that my motor seems to have a pretty constant-torque loss-curve. No dependency on the speed. So if I command 2A, the motor will not be able to overcome the cogging torque. At 3A it will. Shoving it at 2A also causes it to start. Then it can take up to 30 seconds before it reaches MAX RPM. Similarly my dummyload is (almost) constant torque too.
Anyway, the trick to have it stop at not-max-RPM is to load it and limit the battery current to something that causes the motor to spin at about half the maximum RPM (50% duty).
I ran my DT750 in FOC mode for some tests just now. So after that (I'm not sure I did the wise thing to save-as-xml the config that worked before), I ran the detection again for my big motor.
When I run the detection I hear the right sounds, I get a "detction result received" and... "R is 0. Please run a detection first".
Ah! Found it! The powersupply was still in a low currentlimit mode. The "wrong" error message put me off the right track for a while....
I have added:
} else if (strcmp(argv[0], "show_hall") == 0) {
int i;
int oldhal = -1, hal;
for (i=0;i<10000;i++) {
hal = read_hall ();
if (hal != oldhal) commands_printf("%d %d %d", (hal & 1) >> 0, (hal&2)>>1, (hal&4)>>2 );
oldhal = hal;
chThdSleepMilliseconds (1);
}
to terminal.c This prints expected patterns
1 0 1
1 0 0
1 1 0
0 1 0
0 1 1
0 0 1
1 0 1
1 0 0
when I turn my motor. My intern had soldered the conversion connector for the hall sensors. This resulted in one of the pins breaking off after a few connect-disconnect cycles. Debugging that was much easier with this debugging tool.
Somehow with my current hardware the old detected hall sensor table is no longer valid, and getting it to pass detection is again troublesome...
I SEE the motor jump from one of the BLDC positions to the next, something like 12 times and then in the other direction. I remember seeing the code try to move the motor smoothly, right?
Where do you download the source for custom builds? I couldn't find it on github or here.
FYI, I have now lowered the "sensorless ERPM" to 200 on this motor. Works fine. (Due to the low KV, there is significant BEMF at low speeds). The 100 ERPM hysteresis (200 actually, IIRC from reading the code) is a bit much...
The "hall sensor module" for this motor costs on the order of 600 euros. I would therefore expect some quality engineering, i.e. a more or less perfect sensor placement. So I took the measurements, and placed them "perfectly" around the 200 places around the circle. Then I adjusted the starting position to see if I could get a bit better performance from this. Not really noticable.
I did not automate the "change the settings and measure performance" loop.
Did you sort out the non-sinusoidal currents? Sounds like you had similar issues to what I get trying to run a fairly large inrunner motor I have. I have trouble getting it to start up or run the flux linkage detection. I get the same erratic currents as the image you posted earlier, adding a load didn't seem to do much.
My currents (and voltages actually) look more or less like sinewaves, but with some extra shoulders....
It's strange it runs correctly at 25 volts but not 50 volts. I think it might be a hardware issue and one mosfet isn't being switched correctly but I'm unsure which one, I replaced fets and drivers already. My suspission is phase 2 low side but I can't find any explanation or hardware fault that make sense for it to work at 25v but not 50v. First image is 25v, it goes sinusoidal given enough load, second is the same settings on 50v. Apart from the spikes phase 2 only has positive current I'm not sure if that would suggest phase 2 low doesn't work or phase 1 & 3 high sides don't work (gate driver bootstrap issue perhaps?)
http://i.imgur.com/7lIXlTB.png
I found the culprit, ferrite bead on the mosfet gate slowed turnoff too much for higher voltages.
I stumbled across something interesting while trying to fix it. I left space on my board to test out various filters on the analog signals, on the TI instaspin reference designs they had quite large capacitors on the 4 vsense signals (0.1uf) omitting them always resulted in instaspin not working on any custom boards I made, added them to my VESC board and discovered you can observe sinusoidal voltages as the motor is being driven in FOC mode. Made me wonder if they are using the information to assist the sensorless observer or their realtime stator resistance function.
http://i.imgur.com/ieemR1z.png
Benjamin, would it be an idea to give you access to my system at some point in time? Then you can try to get the motor to pass detection.
The thing is, the common motors go by themselves, but the more difficult ones always fail and nobody but you seems to know what to do. Your advice "play with the numbers a bit" is a bit vague: we don't know how to translate the failure mode in a direction that you'd play with the numbers. As there are three parameters to configure to allow the detection to run, scanning the three-D space for a working combination is quite difficult if you can't hill-climb. So, IMHO, the detection needs to get better. One way to try to achieve that is to "give" you the assignment to make a motor pass detection. I'm hoping that after you've seen what you need to do manually you'll be able to integrate it into the firmware.
One of the things that the VESC seems to have trouble with is to spin the motor without feedback. About ten years ago when I didn't know much about BLDC motors, I made a controller that would spin a harddisk. 100% blind: no feedback at all.
What you can do to spin a motor without any feedback is to rotate the field at say 3 ERPM. Then, over say 3 seconds ramp up the current to a value that the user says is acceptable for this motor. Next accelerate to a certain RPM. If it doesn't work, try slower. (or you could optimize and see how fast you can make things on the "easy" motors, and only slow down for the more difficult ones that e.g. I have.....).
Hey Frank, this post is quite old, but has this ever happened?
I am using a Flipsky 65161 motor and I am struggling in getting it to run smoothly. Maybe there is a XML file with settings that fit this model?
Thank you!