Firmware 5.03 is under development, and this thread is for beta testers. This firmware has some major changes in the FOC code which can significantly improve low-speed performance and fix some old problems (such as when the motor starts "screaming"). Due to the amount of changes there are most likely some regressions, so I would appreciate some testing and feedback. Here is a link to the beta build:
The release is now done!
VESC Tool also has a major new feature, which is a scripting page. I will make a video about that, but it you want to start testing it now there are some example scripts included that show how it can be used.
- Fixed inductance measurement bug.
- Speed tracker windup protection.
- Phase filter support.
- Phase voltage offset calibration.
- Better current offset calibration.
- Added power switch commands.
- Synchronize observer state when running in open loop.
- Force oberver state magnitude above 50% of flux linkage. This prevents the motor from getting stuck and 'screaming'.
- Observer global convergence update. Helps tracking the motor through 0 speed.
- Added HFI start sensor mode.
- Added TEMP_SENSOR_KTY84_130.
- Major UAVCAN update. See: https://github.com/vedderb/bldc/pull/269
- Avoid numerical instability when mapping is done over a narrow range. See: https://github.com/vedderb/bldc/issues/262
Added servo_out_enable appconf option, so that the PPM port can be used to control servos with the default firmware.
Better current controller windup protection.
Field weakening support (experimental, be careful and use at your own risk).
Limit hall sensor angle rate of change based on ERPM.
Added p_pid_gain_dec_angle parameter.
Low pass filter input voltage.
Dual hardware CAN-scan fix.
Use fast speed tracker for current controller.
Disable motor for 5 seconds after flash operations.
Added kill switch support.
Added process derivative term to position controller.
Added position PID-controller angle offset.
Configurable PID controller rate.
Added several AUX port modes.
Added configurable safe start modes.
Added fusion IMU filter.
Added constant torque PAS mode.
Correct scaling for resistance and inductance.
Fixed inductance measurement bug with f_sw > 30k.
Corrected inductance measurement algorithm.
Fixed max power loss calculation.
Better input current estimation.
Added raw sampled data mode.
Compensate inductance for motor saliency in observer.
Added MTPA mode based on measured current.
Faster overvoltage protection.
Added statistics counters.
VESC Tool Changelog:
- Fixed simultaneous CAN FW upload when other devices (such as BMS) are on the CAN-bus.
- Fixed configuration backup and restore over CAN-bus.
- Added test version information to about dialog.
- Added scripting page
- Syntax highlighting (needs some work).
- Recent files.
- Example files.
- Auto-completion tree (needs some work).
- Run in widget, window or full screen.
- Debug print output.
- Toggle line comment.
- Auto-indentation of line or block.
- Search, highlight and replace text.
- Only capture esc key for stopping the motor when connected.
- Fixed FOC detect all no can when connected over CAN.
- Added FOC wizard, setup data and profiles from mobile UI to desktop UI.
- Added usage page to FOC wizard.
- Added support for loading custom UI from firmware.
- Dark theme.
- Mobile UI refactoring.
- Configurable data polling rates.
- Better DPI scaling.
- Configurable plot line thickness.
- New CAN forwarding bar.
- Setting to disable screen rotation.
- New RT Data page and gauges.
- Upload bootloader before firmware if firmware has bootloader erase support.
- Added motor comparison tool.
Some tips for testing the phase filters:
- Make sure that all offsets are calibrated with the voltage you are using. This can be done on Motor Settings -> FOC -> Offsets. Make sure to calibrate the offsets before running detection.
- For motors with temperature sensors, make sure that temperature compensation is activated and that base temperature is set to what the motor had when detection was done. The compensation and base temp is found under Motor Settings -> FOC -> Sensorless. This should be done automatically when using the FOC-wizards.
- The phase filters can be enabled and disabled for comparing their impact.
This is great to see the continued progress and improvement of the VESC project!
Is there some data/info on exactly how the phase voltage filter is improving motor control? What is the expected impact of using them? Do the phase voltage filters need to have a certain RC constant in order for it to properly function with the firmware? Do some types of motors, say low-inductance, benefit more than others? Would hardware with low-side current sensing still benefit from having these phase voltage sensors?
Are there any details anywhere on what A.S.S. is doing from a technical standpoint? I know I can dissect the code and figure it out eventually. Just asking for convenience sake.
Is the switchable phase/current measurement filters used for HFI / "ASS"?
Or only detection? (ie, are the filters needed to be dynamically disabled for HFI / "ASS" operation?)
I ansered my question - current filters are disabled for HFI (but seems like you keep voltage filter on ;)
That vesctool version refuses to install on android 11.
Is the issue on my end?
I just tried the APK, it should work. If you have VESC Tool installed from the play store you probably have to uninstall it first to use the apk.
In a nutshell, the phase filters help tracking the motor at lower speed.
As the motor speed decreases, the magnitude of the back emf gets lower and lower. At some point it will be so low that noise, offsets and parameter errors will become so significant that the back emf no longer can be tracked. One of the issues at low BEMF levels is dead-time distortion. This comes from the fact that the motor phase voltages while the motor is driven are calculated from multiplying the input voltage with the modulation of each phase. The problem with that is that there is a short period between when the high-side FET and the low-side FET is on to prevent cross conduction; the so called dead-time. On low modulation the dead time has a significant impact on the voltage estimation, which makes it hard to track a low BEMF. The phase filter help this issue by measuring and low-pass filtering the phase voltages directly, which gives the actual voltage including the dead-time distortion rather than the estimated voltage. Feeding these voltages to the observer helps track the motor at lower speeds.
This sounds simple, but there are a lot of other issues with this approach, such as the introduced phase delay from the filters. As the signal levels get so low other effects also become important, such as the current measurement offsets and the ADC offsets where the phase filter measurements are sampled. Component value tolerances for the filters also get more impact at these low signal levels. The firmware now tries to deal with all of these problems at the same time so that the motor can be tracked at much lower speeds. This also required some updates to the observer.
So far my test results are promising. When all offsets are measured, just the tiniest movement is enough to track the motor, and tracking through 0 speed works really well. The problem is when starting the first time or when staying in 0 for too long, which starts the observer in a state that produces much less torque, which can't turn the motor to get some BEMF for starting to track it. To deal with that I have added a HFI Start "sensor mode" that will start by making a brief HFI pulse when the motor state is unknown, and then start tracking the motor normally. It will also do the same in situations where it otherwise would to to open loop. That seems to work really well on my mountainboard.
For hardware without phase filters, the updated observer and offset calibration updates should also help a bit, and the HFI start mode can be used then too.
Let me know how things work, and if there are any regressions. There are a lot of changes in the code.
Another update from todays release: The FOC-wizard is improved quite a bit. It should set better parameters by default than before when running detection.
I tried the latest dev branch (Commit 89c4d712e8ab6ac22c89e0c982d6b4426f8483ea, Mar 13 2020) and its performing pretty poorly on my setup. Running a 16" hub motor from a Solowheel Original EUC with a Cheap FOCer v2 ESC.
Startup performs similar to sensorless at startup maybe even a little worse, even tho I'm using sensors, and its very rough sounding and noisy all the way up until near max RPM. As a sanity check i tried 2 different ESCs and it was no different, however swapping back to the master branch made it run smooth as butter.
Not sure what all info/logs i can provide to help.
*EDIT* Just tried the same motor with a stormcore 100s ESC and it seems to work fine, so its something to do with the Cheap FOCer v2.
P.S. I really love this new wizard stuff, much cleaner and easier to use. Also the work of having to implement everything twice was very demotivational.
Thanks for giving it s try!
I just tried it on the old VESC 6 without phase filters, as well as on the unity and the stormcore 100D both sensorless and with hall sensors. Works fine as far as I can tell.
Are you sure that you had the firmware from that commit? It should say BETA 11 on firmware status in VESC Tool and not BETA10. The commit earlier the same day and a few commits before that probably had an issue with the hall sensors, which would make the motor sort of go to open loop even when using hall sensors.
Yeah, having the same wizard both in desktop and mobile is nice, and makes development easier. Did you also give the scripting page a try? I have used it a bit for some of my projects here, it is really useful. Soon I want to make it so that external hardware can upload a compressed QML-file to VESC Tool after connecting and provide a custom interface page. This is useful for LED-boards, loggers etc. to give them a custom interface without making the code go into the VESC Tool code base. Developing these QML-files is nice with the scripting page as they will have access to the same things. Changing and testing things is also super fast this way.
Ok, i double checked everything, the zip file in the first post is giving me BETA 10 for Cheap FOCer2, it has the issue, so i also tried compiling the latest code and got BETA 11 and still have the issue.
*edit* Got another user to try it and they described the exact same issue.
I just looked through the scripting page, and it looks like it can majorly cut my development time when working in QML, I'm for sure going to try it next time I mess with that stuff, which is on my todo list. As far as 3rd party hardware control, my master plan for can accessories was to write a bluetooth app that talks over uart with the esc, and has it can forward whatever I want to my can bus accessory so i could essentially make any can bus accessory bluetooth enabled so long as the esc has bluetooth. I could use that for my Balance Buddy.
Just tried it on a FlipSky 4.20 MINI, after doing the detection, I can't get the motor to spin, it just jerks for both sides. Running sensorless. I know this hardware has pretty poor phase current measumerent a bit of DC current offset on the readings, maybe this i interfering with the new sensorless startup
Sounds like there could be problems with some hardware versions. I will see if I can find a 4.12-pcb in my box and try it there.
What offsets did you get on the offset-tab under FOC?
I like the scripting page :) thanks benjamin !
short test, works fine
My offsets are
I think its fair to say my problem is similar to Pedrodemio's my motor mostly just cogs in both directions unless i crank up the current or give it a push.
i updated from 5.02 to dev_5_03 and started the test version from vesc-tool:
Error: "Could not deserialize motor configuration. You probably need to update the VESC firmware, as a new iteration of the test version has been made."
Now i can not read or write the motor configuration
EDIT: ah, there is a new version behind the link above :) working now
I think there are some factors that affect how other hardware handles some of these changes
A lot of the hardware I've developed matches these things and I've noticed how much they affect smooth control. Ben, are any of these factors known to affect the quality of motor control or ASS?
Phase filters are not working on my hardware, which is based on the VESC 75/300
Motor detection and running is smooth with disabled phase filter.
With phase filter enabled, motor detection just cogs in both direction
I did some testing with an old V4, and it seems to work. Only problem is that it by default uses BLDC, meaning that the offsets don't get sampled when changing mode to FOC. One workaround for now is to switch to FOC, write config, sample offsets and then run detection. I will try to fix this for the next update.
So far it seems to work on all hardware I have tested (2x low side, 3x low side, 3x phase shunts, 2x low side dual, 3x low side dual), with the exception of dual motor hardware with phase filters as I don't have any. Only problem so far was with the v4, but the workaround above works (although it also worked with the default offsets, just not as good).
Something that I don't have access to but that would cause problems for sure is hardware that has phase filters in the hwconf file (#define HW_HAS_PHASE_FILTERS), but has a problem with the implementation. If the hwconf file has no #define HW_HAS_PHASE_FILTERS the the config option is vesc tool should have no effect.
Another thing that will impact the performance is if the offsets are sampled with an input voltage that is significantly different from the voltage that is used with the motor.
Can you show me what your phase filter implementation looks like and which hwconf file you are using?
thanks. First, without phase filters the new detection runs much better than in older versions.
the phase filters are the same as in your design, just change the analog switch to one which is available on jlc
Maybe it is a problem with bad board design. I moved the switch near to the adc inputs, to have the capacitor as near as possible to the adc input. because i have a round design, the filter input voltage path is very long
I don't think the layout is so sensitive that it would completely stop working. Having it near the ADC-pin is good too.
Can you make sure that the filter actually is connected to GPIOC 9 and that the pin is configured as an output in the source file for your hardware?
yes, just checked again: schematic has GPIOC connected and inside my hw_gesc.c i use the default code
is the "PHASE_FILTER_OFF()" still correct ?
All working good on my A200S V3, which has 2x low side shunts and current + phase filters.
One thing I did a bit differently to your designs is my extra filter cap is connected to an open drain IO on the stm32. So I don't need the analogue switches. The pin is either floating or ground.
That seems correct. Can you plot the voltage signal while the motor is driven in the sampled plot?
I just made an update, seems to work better with the V4 now. The offset calibration is also updated so that the parts that don't need the motor to stand still are calibrated on every boot by default.
FOC wizard sets my battery cutoff start/end at 6v, despite selecting 10s on all of the 5.03 test versions.
You are right, I messed that up in the new wizard. Building a version now where that is fixed.
Tried the latest but it's still not working for me on the Cheap FOCer V2.
I checked a few things in the config, but I'm not sure where to start debugging the problem as I can't reproduce it. If someone can send me a unit that doesn't work I can have a look. You can also show me exactly how you are making the test, what the sampled and real-time data looks like etc. The more details the better.
here are two pictures of sampled data, triggerd with motor start.
the motor is configured with parameters from the wizzard without phase filters. sometimes the motor starts spinning after 2 or 3 seconds
Looks like not much is happening after 40 ms. Does it get a fault code? Does exactly the same test work with the old firmware? What are the current and voltage offsets?
the same test (try 10% duty cycle) works fine with the same firmware, but disabled phase filtes in the FOC filters tab.
this is with disabled phase filters:
with enabled phase filters the pictures looks like in the post above and the motor does this:
Uploaded another version now that seems to work better on the cheap FOCer 2
Still not running here, but its more or less a problem on my individual hardware :)
Detection ist not running. Either with HW_HAS_PHASE_SHUNT or without. in addtion the saved config is now not working when phase filters are disabeld...
I'm noticing on the latest builds that the balance app is struggling with the sleep function going longer than requested (1khz Balance, 1khz IMU). I think this problem has been creeping up for a while, as awesome features are constantly being added. But it seems like we might be hitting the limits of the CPU, tho tbh I'm not entirely sure how to measure CPU load or what the best way to go about reducing it is.
You can write threads in the terminal and see how much time is spent in the idle thread compared to the others, that is an indication on how many CPU resources are left for threads. This does not include the long motor control interrupt directly, but if little time is spent in the idle thread it means that CPU resources are running low. The CPU usage from the motor control interrupt is directly proportional to the switching frequency and the number of motors. For single motor hardware with f_sw at 30 kHz, more than 50% of the CPU resources should be unused.
When using the sleep function it does not include the time the thread itself takes to run, and if there is an interrupt in the middle that won't be included either. That means that the rate of the thread will always be a bit too low, and there will be some jitter on that. One way to improve that is sleeping based on absolutes times. Something like this should work:
guys, I want to build an external alarm based on IMU+ESP32 (more complex than that but to keep it short we leave it for now)
- Idea is to add "Alarm mode" on VESC, which would execute those steps up on ADC3 line going from 0v to 1.5v with VESC powerd on:
1. put VESC to some sort of lowest power consumption mode
2. Disable throttle input ADC1/PPM/CAN
3. monitor ADC3 for change
= VESC ready to act if alarm is triggered
- than if ADC3 goes to high (3.3v - alarm triggered):
1. wake up controller
2. Engage breaking to full power (ideally would be if there would be seperate paramter Alarm Breaking Force, so that it can be set higher than typical riding breaking / regen force)
3. go out of Alarm mode once voltage goes down to 0v on ADC3
That would be amazing option in my opinion specially for bicycles and e-scooter at very least!
if you are interrested in Alarm side it would function someething like that:
1. Arm 1.5v / Disarm 0v output (by phone APP or RFID tag readerr or what ever you want)
2. MPU650 triggered alarm would set output to 3.3v to VESC ADC3, send 3.3v to the FET to open up main battery power to the Siren, Send notification via Blync app over 3G shield (gps shield would also send GPS data over Blync app wher one could track)
3. reset gyro/accelerometer home position every second and go back from triggered to Armed after 30sec without motion detection (output down to 1.5v, siren outout off)
In theory basic alarm function could be implemented completely insidee VESC
- since it has Gyro/Accel on board
- has BT connection (so lock / unlock could be added to the phone App)
- Only not sure what connection could be used to trigger Siren activation (could ADC to be mapped as output - to send trigger for the fet to open up the gate for battery voltage to the siren?)
This is my results from the threads command. Which are pretty encouraging. Idle thread is at 61.2% so there should be plenty time for the balance app to run. I will try to implement sleeps they way you recommended and report back. However the time of the BMI160 thread really stands out at 30%, it actually starts off low 1% and then steadily increases over time, Ive seen it up to abut 40%. I tested the lsm6ds3 and it does the same thing. I don't understand whats going on there.
addr stack prio refs state name motor time
20001bd8 20000f54 64 1 SLEEPING main 1 189 (0.0 %)
20001c28 20001d34 1 1 READY idle 1 801432 (61.2 %)
2000d580 2000da6c 64 1 SLEEPING mcif timer 1 16265 (1.2 %)
2000d1e0 2000d494 63 1 WTOREVT SampleSender 1 0 (0.0 %)
2000cb58 2000cdfc 124 1 WTOREVT Fault Stop 1 0 (0.0 %)
2000e3a8 2000e84c 64 1 SLEEPING foc timer 1 1939 (0.1 %)
2000db28 2000dfd4 64 1 SLEEPING foc hfi 1 719 (0.1 %)
20008a40 2000901c 64 1 CURRENT comm_block 1 360 (0.0 %)
20001f80 200020ec 126 1 SUSPENDED usb_lld_pump 1 3400 (0.3 %)
200050f0 200052bc 64 1 QUEUED USB read 1 2096 (0.2 %)
20003f58 20005074 64 1 WTOREVT USB process 1 17810 (1.4 %)
20018a90 2001930c 64 1 SLEEPING UAVCAN 1 7 (0.0 %)
2000aeb0 2000b15c 65 1 WTOREVT CAN read 1 0 (0.0 %)
2000b248 2000b4dc 64 1 QUEUED CAN status 1 253 (0.0 %)
20009d18 2000adc4 64 1 WTOREVT CAN process 1 0 (0.0 %)
20014408 200154dc 64 1 READY uartcomm proc 1 2546 (0.2 %)
20002cf0 200031d4 64 1 SLEEPING Main periodic 1 239 (0.0 %)
20002a58 20002c54 2 1 READY Flash check 1 2346 (0.2 %)
20009960 20009c3c 64 1 SLEEPING Timeout 1 196 (0.0 %)
20019918 2001a0f4 64 1 READY BMI Sampling 1 412671 (31.5 %)
20016648 20016f14 64 1 SLEEPING APP_BALANCE 1 17571 (1.3 %)
The reason that the IMU-thread takes so much is that I2C runs in software, and uses a busy-wait loop for the bit timing (using a hardware timer, so the speed is not that load dependent). This means that it will spend as much time in that thread as the communication takes. This adds up when sampling the IMU at a high rate as you do for balancing. The 30 - 40% will probably not increase much as the rest of the system load increases, because the busy-wait loop uses a timer to not sleep longer than needed. It will increase and decrease with the IMU sample rate though. I don't know why it starts at such a low value, maybe because it takes some time before the IMU-thread is started during which the idle thread will run and increase its total percentage (the load value is based on time spent in each thread since system start compared to total time, meaning that it is an average since boot).
I gave the new field weakening a go just now. Hardware used was a200s v2 and a 6374. Only tested on the bench at low speed and power with current mode. It worked well and the gradual ramp down of d axis current kept the winding voltages in check during braking or sudden release of throttle as expected. Nice work!
I just tried beta21 on a Cheap FOCer2 based Funwheel with Fungineers hub and 12s2p battery. When reusing my existing settings (still worked fine in beta17) I now get a clunk noise when balancing at low speeds. I didn't dare go on an actual ride. Is it unreasonable to expect that old configurations should continue to work? Is there any particular setting I should go adjust or do I need to go through the full calibration process again?
I just built the latest dev branch also on a cfoc2 and ran a fresh calibration and noticed current spikes, here is a graph. The black is motor current, and the red is what the balance app is setting the current to. You can see around the 0 point there are large black spikes while the red is flat. (Some of the black spikes also have red spikes, i think these are reactionary to jitters/cogs getting the IMU out of whack?)
Previous betas didn't have spikes like this. Here is a graph from beta 19, its harder to get any spikes, but if i do get some spikes they're much smaller.
*I should point out, it took effort to capture the small spike on beta 19, where as the curren't code i just grabbed a random sample, not even the worst of it.
**Edit: My same setup randomly worked fine on a more recent test, so i guess there is some intermittency to this issue.
I was able to confirm that beta20 also works fine for me. The problem appears to get introduce either by "Merge pull request #282 from powerdesigns/ipm_bemf_decoupling " or by "Merge pull request #283 from powerdesigns/speed_pid_loop_antiwindup " or by both - I can't quite pinpoint it (I tried commit by commit, I installed about 15 versions of the firmware today).
In addition to the clunky noise when balancing near zero speed, I also get such noise after I get off the board and the board is not moving, after about 30 seconds (I have brake current = 7A configured)
I think I know what the problem could be. When the set current is around 0 the motor will alter between being driven and undriven. Before that was done in sync with the current command, but now it is done using a timer as field weakening has to be taken into account. Can you try to making sure that the output of the PID-controller always is greater than cc_min_current?
It is probably best to keep the motor driven even at 0 current in an application like that without having to introduce a discontinuity around 0. I can add some command for that in the next update.
> Can you try to making sure that the output of the PID-controller always is greater than cc_min_current?
Any suggestion as to how I can best accomplish that?
I can confirm that the balance app calls "set_current" with values < cc_min_current all the time when riding, regardless of speed - whenever the board is "balanced" the output current can go down to 0 I guess...
I just tried forcing the set_current value to always be >= cc_min_current (I have a beeper alerting me whenever that happens, which is very frequently on a balance vehicle) but that made no difference unfortunately...
I just added mcpwm_foc_set_current_off_delay() so that you can delay switching off the modulation for 0 current. Can you try to use it just before setting the balance current?
Let me see if I understand. According to your commit the delay defaults to 1s, right? How many seconds should I set it to? The balance app sets the current 1000 times a second, do you really want me to call this function each time?
Or did you mean to say "before setting the brake current?" so when starting to idle?
There is no default value, you have to set a delay. As long as it is longer than your control loop cycle time it is fine (e.g. 0.1s). The function is not heavy, so you call it in every iteration.
Today I was playing around with settings and clicked write config while the motor was running a few times by accident. It caused the motor to almost instantly stop from 40% duty, after doing this a few times it blew one of the low side mosfets. I thought it was supposed to turn off the modulation when motor settings are changed so this doesn't happen?
That is probably because the modulation is not stopped instantly anymore in case field weakening is active, and writing to flash stops the CPU entirely. I will make a workaround in the next days.
Here some more observations. I did add the call as you suggested, but didn't really notice an improvement. Still quite clunky when rocking back and forth and minimum speed. I also discovered that the weird noises when resting only occur during a firmware upload (which is slow via bluetooth). When I had the board on the ground it started making small movements on its own during the firmware upload process. What's odd though, is that when using a fresh motor configuration by running the newest wizard, I don't get the noises and self movement during firmware updates anymore, but I still get the occasional loud "clunk" when going back and forth at low speed... Sorry if I'm not making things clearer...
I could attach a diff between my 5.2 motor config and the new (better) motor config I got out of the wizard in 5.3 beta 21 if you'd like.
Firmware uploads while the motor is running is a bad idea, as every time flash is written the CPU is completely halted. I'm surprised that it works at all. I will see if I can lock mc_interface properly during firmware updates.