I'm currently working on firmware version 5 for the VESC, and the major new feature is dual motor support. This means that the focbox unity should work with this release, as well as other dual motor controllers that will come in the future. In some upcoming projects I'm going to work more closely with Jeffrey who made the unity, so the other controllers he makes should be based on the main VESC code base soon. Jeff and me collaborating should be good news for the community, and I look really look forward to seeing what we can do.
Here is a test build of VESC Tool with the new experimental firmware for Linux, Android and Windows:
http://home.vedder.se/tmp2/vesc_tool_test_2020-04-26.zip The release is now done!
It would be great if you can help me test this carefully on your setups. Please be very careful, as I haven't done much testing myself yet. Use RPM limits, wear protection and take your time.
I would appreciate feedback on:
- Dual setups with the focbox unity
- Singe setups (as a lot of the code is restructured)
- Setups with CAN-bus, including both unitys and single controllers if possible (3+ motors)
- Observer gain calculation and working parameters
- Use calculated value from old firmware vs new firmware
- Vary the input voltage and see if the observer tracks well
How does dual motor support work?
Essentially, the second motor pretends to be another VESC on the CAN-bus with the CAN-ID + 1. This means that you treat it just as a regular combinations of two VESCs on CAN. The unity will thus also get two CAN-IDs on the CAN-bus, so it should integrate well with other projects that used can.
Each motor has a unique motor configuration, and the only dependence between them is that they must have the same switching frequency as the timers must run in sync. So when the switching frequency is changed on one, the other one will be set to the same value. At the moment around 27 kHz is the highest supported switching frequency, which is not enforced, so don't set it higher than that as you might need an SWD programmer to recover. There is only one app configuration, and it runs on motor 1. Motor 1 will always see CAN status messages from motor 2, so activating multiple VESCs over CAN should run both motors for the apps. Traction control in apps also works this way.
VESC Code
If you are into coding and the VESC code, please also look into the code in the dev branch:
https://github.com/vedderb/bldc/tree/dev_fw_5_00
I will make more frequent updates to the dev branch than I used to do to master, so you can hopefully follow what is happening easier. There is a dev branch for VESC Tool too, but there are barely any changes as the firmware is backwards compatible.
Thank you, Mr. Vedder. Very interesting. Is this an extension of the existing functionality when you can connect multiple controllers via CAN and have them run in sync or it is something completely new?
I am particularly intrigued by a motor acting as a controller.
NextGen FOC High voltage 144v/34s, 30kw (https://vesc-project.com/node/1477)
This is really a new era in the VESC Project !
Thank you for involving more and more people. This is quite exciting !
Thanks! I hope that some volunteers will help out with the testing, it has been a big burden for me with that many setups around.
I just uploaded a new version. It has some fixes for the unity, but more importantly improved parameter detection and observer gain scaling. If someone had problems with high erpm motors or large motors on the 75/300, it is worth trying this build. Just be careful.
Hi all, how do I connect this to my Unity to upgrade FW to 5.0? I've got it installed to Windows 10, and downloaded and installed the STM Virtual drivers too, but nothing seems to work. Please help!
FWIW after trying the FW update again this morning, it works now, only difference is my laptop is plugged into its charger.
Uploaded FW 5.0 to my Unity, running HFI on default settings works a charm mostly. Worthwhile to note that I had to connect to two different VESC ID's manually to set up HFI on each motor.
Also, when trying to configure HFI when clinking on the Brake icon to test settings the motor only made a momentary "tick" sound, instead of the continuous "whine" on Jeff's video until you click Stop. Hence I couldn't get a graph to fine tune HFI.
During operation I kept my throttle input moderate, but got up to normal max speed which is 40km/h around 90% duty cycle. Once while braking at around 10km/h HFI kicked in for a split second, which didn't happen again.
Notably the new FW / HFI / FOC motor settings may be chewing through battery a little quicker, although hard to quantify without metr Pro stats.
My setup is Unity on an MTB with Trampa trucks and 165mm pneumatics, being driven through dual e-toxx 1:4 Mini GDs by Turnigy SK3 6374 192kV motors at 8S with two Turnigy 4S 6Ah Graphene LiPos wired in series.
Good to hear that it works, and that even HFI works on the unity. To be honest, I haven't tested HFI at all on the unity until now. I gave the plot a quick try, and for me it seems to work. Keep in mind that you must unplug the remote when making that test, otherwise it will switch off the motor just after you press the button in VESC Tool.
I just uploaded a new build, with the following changes:
If someone want to give this a try with a motor that has been difficult before, it would be great to get some feedback on that. I know that some people had problems on larger motors with the 75/300, and this is quite likely to help.
Awesome! Is the new FW the same link as the 1st post in this thread?
Also, when you say unplug the remote, do you mean unplug the Rx, or just switch the remote off? I have a Hoyt Puck, so PPM remote.
Never mind the download link, I see the one above changed to last night's date.
I've been running a 3kg outrunner with the a200s. On previous firmwares, when coasting at low speed, applying a bit of throttle will result in regen. Playing around with observer gain and observer gain at min duty mostly fixed this.
I haven't experienced this issue on this new firmware with the observer gain changes.
After flashing latest FW, I followed your instructions unplugging the Rx to get a custom HFI setup.
The HFI works perfectly, but outright performance on dual 6374s sucks. A budget hub board would outrun me.
Figured it out, friggen Hoyt Puck was in mode 1, applying expo to the PPM output.
Hi Ben,
In order to involve more people into testing, I created a thread on esk8.news : https://forum.esk8.news/t/vesc-fw-5-0-beta-testers-wanted/23342?u=pimousse
Some people start to try the FW 5.00 and report back.
Fixed two cold solder joints in my phase lead connectors which sorted out the random micro braking events, but still getting some cogging during HFI pull offs. Settings are 12V, 4V and 6V for HFI.
Would changing that to 20V, 4V and 10V help at all or am I just too careful, not piling on the throttle enough during pull off?
Finally the testing branch! Very nice! I will test it as soon as I finish my 4WD mountainboard(4 vescs based on HW6, CAN bus, AS5047)
What's in the latest update? http://home.vedder.se/tmp2/vesc_tool_test_2020-03-29.zip
Hey, I initially tried the fw5.0 for Unity as linked in your original post but for some reason the vesc over can couldn't calibrate te motor (but full brake was working). After that I installed the fw again from the following bin: https://github.com/vedderb/bldc/tree/dev_fw_5_00/build_all/UNITY but now the vesc-tool does not recognize the fw so I can't connect to it anymore. Any Idea how I can fix this again? Kinda stuck now.
I had the same problem this morning mate, flashed 5.0 FW from the 29th on my Unity but it wouldn't detect the second motor, reverted to the 5.0 FW from the 22nd, redid detection and PPM calibration and everything is fine again.
So the problem is with the latest 5.0 FW. Try this one from the 22nd instead: https://drive.google.com/file/d/1wMx5QOoYuS7rr5tV61_UHO2jXG3QXwYm/view?usp=sharing
The latest tool seems to be missing a bunch of pages for motor and app config.
Unbricked it.
Now when I try to install fw5.0 I get the following message just before finishing installing:
2020-04-01 16:30:45: Status: Serial port error: The I/O operation has been aborted because of either a thread exit or an application request.
I have to restart the Unity to connect it with vesc tool again and I see that no fw update occurred
Are we going to have one branch for bugfixes and polishing (like an RC "release candidate" branch) and then another branch for new features (like a dev branch)?
I am wondering, because adding big new features to a branch resets much of the testing and polishing that needs to be done to get the code accepted into master.
So if, for example, 5.0.0 includes dual motor support, then if a new feature should ship in 5.1.0 then that is typically another branch while 5.0.0 is being tested. Adding new features to a branch while folks are testing it could become counter-productive.
The previous update had a bug for the unity that is fixed now. Also, the reason that some pages are missing is that only the pages for the currently selected motor type and app are shown now; I was hoping this makes things less confusing, but maybe it that is not the case.
There is only going to be one dev branch in addition to the master branch for now, and the testing will be done as in this thread in the dev branch. In my experience small changes can cause as many problems as big changes, so any change at all needs sufficient testing. The plan is to do the testing like this, and when that is done merge it back to master.
There have been many changes since I started this thread, but that is because the dual motor support is a radical change that affects almost every single part of the firmware significantly (I have been up late working on it every evening for a month now, really looking forwards to getting it done). As this becomes more stable, there will be fewer and fewer changes, and in the end I will just leave this thread open for a week or so without changing anything so that the last iteration has proper testing by me and volunteers before merging back into master and making it the next stable release.
One of the balance users found a slight issue with one of my recent additions. I added a holding current feature where it turns on the current brake when you are not riding, for skateboard style vehicles where you sort of do the jump start mount this is very helpful to keep the wheel steady during mounting, especially on hills. However it seems to be disabling the power button, my guess is that the power button only works when there is no power being output. I thought of a few possible solutions, perhaps having the power button can feed info into apps and let them stop them selves (or maybe even use it as a button), or perhaps allow shutoffs at 0/low erpm even if breaks are being applied. I dont have any hardware with a power switch so I'm mostly guessing here.
*edit* i should add the braking feature is toggleable so for now it can be turned off if using a power switch.
Yes, the push to start feature feeds a bit of current to the enable pin of the logic voltage regulator from one of the phases, so I'm pretty sure the hardware will prevent shutdown if the motor is driven. Could have the power off sequence over-ride the motor drive but that seems a bit scary in some scenarios.
Jeff
I've been testing my Little FOCer (84V controller) and Cheap FOCer 2 (low-cost VESC 6 variant) on the bench with this new FW. Bench test setup is 2 20uH 30mOhm 150kV outrunners coupled at the shaft. One is acting as a variable load and the other is driven normally. I'm still gathering data at the moment. I'll also be putting this in my ebike after bench testing. It's single motor, low-kV, has 46 poles, and will use a 20S battery.
I ran hall analyze a bunch of times at 10 amps on my EUC hub motor, and got pretty different results each time.
Installed latest FW dated 2020-04-04 last night and set it up. Had a fair amount more cogging on HFI this morning with the same voltage settings.
It was basically not much help and the slightest incline would see my motor just rocking back and forth.
The last good experience I've had with HFI was based on the FW labeled 2020-03-22-v2 that I had installed until last night.
Just noticed, I can't connect to the second VESC ID on Unity, whether CAN is green or not, it either gives an error, or just connects to the first VESC ID.
It detected both motors just fine last night though.
Hi, I´m testing 2.04 Beta fw5 on dual fsesc 4.12 working with 2 locked rotors (acting as one) with dual hoverboard wheels balancing board.
For me, foc detection works better in this version than 2.03, and can_bus connections works perfect, i started making it work on the previous version,and not had no issue when migrated to 2.04.
And balancing app works great, it does exactly what´s meant to be done.
Great Job!!!!!!!!
Thank you a lot!!!
After a few days of pulling my hair, torturing fellow VESC users about my agonies, exchanging motors, using different FOCboxes I finally think I have my Hoverboard motors running smoothly on FW5. The solution was just 1 button; read default motor configuration.
Not sure if this is a bug, not sure what made the difference. I had initially downloaded Beta 1 from 2020-04-04, yesterday I have downloaded Beta 4 from 2020-0416. The firmware updater says it erases all settings. I have tried loading working motor configuration files from other users with Hoverboard motors. Nothing worked. Motor would spool up assisted with hall sensors, but only in sensored range. Unsensored didn't work. Also spinup was very violant and ERPM about 10x higher than normal for my motor. Freespin was wel over 12K on a 16.5kV motor (27N30P) with 12S.
This makes me wonder if the VESC motor driver uses settings that are not store in the motor configuration file?
Anyways glad that I have it running now. Next step is assembling motors inside the hub again so I can test the balance app code from Mitch :).
Great to see you working together with Jeff now, Benjamin. Definitely a great step to have Unitys and upcoming Stormcores running the "official" VESC code and not a fork that doesn't receive great updates like the balancing stuff Mitch is contributing for an example.
I tested a bit with latest FW5 Beta 4 on HW4.12 and motors on a bench setup. One thing I noticed when testing HFI is that the "Sensorless ERPM HFI" setting is not matching its real ERPM when switching over from HFI to sensorless. I left this setting on the default 2000,0 ERPM, but it looks like the real switch from HFI to sensorless is done in the range of about 3000-3100 ERPM. When sending the traget ERPM of 3000 to the VESC with a lowered P value from the Speed Controller PID the 3000 ERPM overshoots a bit and the HFI whining noise goes away being in sensorless mode. When the target ERPM is close to being reached it looks like it is switching back to HFI which is noticeable because of the whining noise coming back. And that's not happening at 2000 ERPM like expected but at 3000.
Yes, it is really nice to work together with Jeff!
The HFI will start before the result of it is used, so what you hear is expected. At 3000 ERPM HFI will be running, but the position from the observer is still used. The reason is that it takes some time to fill the buffer and for the filters to change, so it is good to start it before starting to use the angle.
Great to hear that!
Ok, thanks for letting me know that it is expected like this, makes sense to me now. I will report back if I find something else testing the FW5 beta.
Hey guys! wonderful work off you all.
Just noticed on the VESCTOOL from this last 2 updates, if you have 2 or more CANBUS devices connected, you can’t “read motor” or “read app” when you have “CAN” forward communication on.
If you click on “read motor” it simple don’t to anything. You might just have a look. Thanks
EDIT: After try older version and reflash firmware, looks like it solved the issue. Not sure what caused it 1st tima, as I was able to connect and identify the correct ID for each one.
EDIT 2: It looks like it happens everytime you do "APP to use: No App", then you can't get data from that vesc.
I updated today from Vesc Tool 2.03 / Firmware 4.2 to latest firmware 2020-04-18 to my Vesc 75/300 via PC and had some issues. I am using the hw_no_limits firmware.
1.After updating firmware it said that it could not be connected to the Vesc. I clicked on the right bar on "Reconnect last connection" because I was used to it. But that was wrong because it connected to another com port so it did not connect to the Vesc. After using the "Autoconnect" button it worked. Connection via bluetooth on my smartphone worked always.
2."Setup Motors FOC" did not work. There was an error like " detection failed". The motor did not run in this detection. Then I remembered that I had this issue before. On default the temperature sensor used is NTC, but I have an PTC sensor. So I had to write PTC sensor in General -> Advanced tab before doing the motor wizard. Then the wizard worked. Because my motor has a reduction via belt, the hall sensor detection in the Setup Motor FOC Wizard did not work. It ended saying its a sensorless motor and Temp Comp was in all detections "False", which is weird. The current was not high enough to turn the motor while doing the hall sensor detection because of the resistance of the beltdrive. Doing the hall sensor detection in the FOC -> Hall Sensor Detection with 20A worked fine then. In this case it would not be practical to always remove the belt for the detection.
3.The values I had in the 4 motor detections I did had all about the same values. Compared to what I ride at the moment in my bike with fw 4.2 they are different. Motor inductance is half of my value, resistance and flux linkage is slightly lower thhan my values. I had no chance today to try out the new measured values in detection but I will try the next days.
Question: Is there a difference to use higher "Max Power Loss" values to make the motor use higher currents in the wizard instead of changing the current limits afterwards in the settings after the detection?
Oliver
Link to forum post: VESC help offered for private persons and companies
Website: www.electricfox.de
I just tried it, and it should work. If you change the CAN mode from the VESC mode it will stop working though.
For now this is always disabled as it gave some problems on inconsistent temperature sensors for some people. You can enable it manually and experiment with it to see if it helps - you should notice it the most when starting the motor sensorless when it is warm. If you have hall sensors it should not make any difference, as the speed where the motor becomes sensorless is high enough for the resistance change to not matter.
Max power loss is used to set the current limits, as well as the current used for the other parts of the detection, so the resistance and inductance measurement can change slightly. You can also set the current limits manually and then use the detection panel in the FOC page, which will use currents based on the limits you set. Then there are the terminal commands to have complete control over how the detection is done. In most cases it should not matter too much though, as the results will be similar enough to not matter.
I used the hall_analyze command to prove a unicycle motor was faulty, and get a replacement motor and control board from a manufacturer!
This manufacturers boards have no detection and require the phases in a specific order, it'll detect no hall sensor at all, but in this case it was 2 phases of hall sensor and blew itself up. It was a replacement motor that took out a working board, so now they replace both, because we showed them a graph of the hall sensor
Looking forward to higher voltage VESCs to replace their boards altogether
I tested today the new firmware 2020-04-18 and have to say that my bike runs much better! I logged the ride and reached at a not fully charged 16s battery 14,5KW peak, with the old firmware I only reached 11,8KW. The only thing I had to do was doubling Current KP and some small adjustments like switching frequency to 60Khz and raising Sensorless RPM a bit not to get ABS Over Current faults. I raised Motor Amps to 440A from the 360A it suggested. The Power is now higher in higher RPMs and the brake is smoother in lower RPMs. Congrats Benjamin and thanks a lot!
Link to forum post: VESC help offered for private persons and companies
Website: www.electricfox.de
Thanks for all the feedback! The FW5 branch is now merged into master, and the release is building. This is a major update, and really moves the firmware to the next level. I also want to thank Jeff who helped out a lot with this release, which you can see it the commit history! Jeff also did a lot of testing on the hardware he has at home and helped people on the esk8 forums with testing, which really helped making sure that everything works.
This test period showed how amazing is turning the VESC Project !
Thanks to both of you and all the testers (couldn't offer my help on it due to lockdown...).
However, Ben, it could have been nice to let more time for testing your last commit Allow throttle in opposite direction even after passing speed limit.
It appears that users are facing PPM issues with it...
Also, I would have loved to hear about the COMM_SET_MCCONF_TEMP making VESC crashes ( https://github.com/vedderb/bldc/issues/160#issuecomment-619832700 ) before the release.
Saw the problem, building a fixed version now. This is annoying me as crazy now and is extremely disappointing after all work the past months. One of my worst days ever...
This has low priority right now, as it requires a lot of careful assumptions and involves many corner cases. If you generate packets with valid checksums and valid packet IDs, but containing random bytes other than that (which is essentially what you are doing when not serializing numbers correctly) there are probably millions of ways to cause dangerous behavior. Maybe some fraction of those cases can be avoided, but if the cost for that is bloating commands with hudreds of different sanity checks that may or may not help I'm not sure it is worth it. Adding complexity to the code always makes it harder to deal with, and it might not even be worth that tradeoff as anything can happen when sending packets that have a valid checksum and random content. In any case, I will think more about that for some later release.
I see your point.
This reminds me a ticket or thread of someone who had the idea of bulletproofing UART commands (even allow access to only some of them) because we don't know what can hook up with.
Anyway, do you plan to open another branch on Github to accept new PR ?
I'd like to publish the changes discussed in this issue as my tests are now ok.
I plan on taking a brake for the next week or two from the firmware if possible (not sure it is, I get an email, message, issue, pm or pr every couple of hours, and a lot of people get upset if I don't answer them). This release has cost me every single minute of every evening and weekend I had for the past months, and the last thing that happened feels extremely annoying. Not too happy about this stuff right now...
How to proceed after the brake I'm not sure about. I want to make some major changes for BMS and external hardware integration, as well as some significant convenience improvements for logging and log result sharing to pull people away from the closed source metr stuff that goes completely against what I believe is right (the closed-ness of it, which is something that I care about greatly), but at the same time I don't want to block myself from making smaller updates to the current firmware. With FW5 I saw more and more things I wanted to get fixed for FW4, especially detection on the 75/300 and other high power hardware. Every week or so someone burned their 75/300 because the detection did not work well and they got impatient and tried adjusting more and more parameters until they hit a combination that killed the hardware. The detection was significantly improved in FW5, which would have prevented essentially all failures I was aware of, but I was blocked from making an update until everything was done. The past three weeks I wanted to make the release, but people asked about more small things every day, and tweaking and testing them felt like an endless cycle. The last tweak was that acceleration did not work when rolling backwards faster than the speed limit, although braking worked normally. The fix seemed super simple and worked for me, Frank and Jeff (although we only had ble remotes and I tested PPM on my bench only where it seemed to work), so I decided to just push the update before even more low priority stuff is found, the release is delayed more and my dead 75/300 pile keeps growing. In all this was quite frustrating and stressful, and the last thing that happened with the ppm thing was the final slap in the face.
What I'm considering for the next cycle is having one branch with FW6, while still making smaller FW5.x releases when important things are found. I'm quite comfortable with git merging things between branches now, but how to make the rest I'm not sure about. Maybe one forum thread for FW6 and one for 5.02, with beta builds in both? That solves the problem of being blocked from pushing updates back until the new release is done, but starts to become a pain to manage. My build scripts don't support that too well now either, so it will be easy to make mistakes when jumping between branches and making builds to post on the corresponding forum thread. Having the repositories twice on my computer with different branches active might help, but I'm not sure how to best organize it yet. The only thing I'm sure about is that this release was not working as well as I was hoping. That being said, FW5 was not an easy release. Dual motor support was a huge refactoring and rewriting of almost every file, and getting the math right everywhere, updating all detection routines and writing a motor simulator for checking everything to make detection rock solid was not easy either. This release probably has the most changes under the hood of any release so far, and that made it inherently challenging and difficult.
A lot of unorganized writing there, but I hope it shows the current picture. Even if it maybe didn't sound like it, I really like the interaction and feedback I get from other developers and users, and I plan on making it easy to contribute to the project for everyone who wants to and has the ability. At the same time, I want to have a process that makes it possible to test the functionality and compatibility of all improvements before making it to end users, so that the releases are safe. This is very challenging, especially when working a normal full time job in addition to doing the VESC stuff, but I'm really excited to get it there.
I can't emphasize more what I already told you at Paris event : don't forget yourself (and your loved oned) in this VESC journey.
This FW5 beta test period has been a HUGE improvement into the VESC project in matter of organization, users and dev involvement.
I didn't end the best way for sure, but anyway, it can't be counted as a fail. I think that everyone is happy in the move you did by creating the dev branch.
You achieved, with the help of others an anmzing work that deserves all the rest time you wish.
About the future ?
Maybe more branches can be created to work in parallel on different topic. FW6 and FW5.02 branches completely make sense !
In any case, I think that's important to let at least a dev branch open so that people can fearless contribute (e.g my changes are ready and tested but I wouldn't PR it to the branch "master"...).
For sure, there are always people who will complain to not being merged in the next seconds. But one angry guy amongst tons of people fully happy with your philosophy... Focus on them
Finally, about logging, a new module appears theses last days. It looks like Metr module and the dev seems agree to open the sources in a near future.
That would be awesome to join your taskforces, so many talented on the same project may release you some times to your family and other things (like riding).
Take care dear Benjamin.
Tack så mycket.
Hi, great work! I just came back from the test ride and got 2 weird drv errors. FW 5.01
DRV8301_FAULTS : No DRV8301 faults.
What does it mean? Is it possible that SPI comm. between MCU and DRV don't work? Can I test it with some command?
Also I noticed that in terminal help there is no hall_analyze between listed commands.
Thank you everyone who have put so much work into developing this firmware. I have used it successfully in my latest open source controller in an ebike. I have also used it with my 84V controller that achieved a top speed of 40mph. Most of everything went smooth. However, there is one issue I would like to address.
The motor detection process seems to rely on the really fast MOSFET rise/fall times of the original VESC hardware. Slower rise/fall times such as in more traditional power stage design techniques (like the Axiom) seem to cause issues in the accuracy of motor detection. An engineer from Axiom team has noticed this and I have as well in my own hardware that I have been designing. Many more hardware developers across this forum and others forums seem to have experienced similar issues. There are advantages to switching slower such as reduced issues from high dI/dt in high-current applications.
It is believed that accommodating slower rise/fall times for accurate motor detection could be solved in the firmware. Has anyone else noticed this issue? Do you think that this issue could be given some attention? I wish I knew enough about the detection code to try and fix it myself but unfortunately I am limited in that regard.
Respectfully,
Lucas
Where is the matching VESC Tool can be found for fw 5.2? All links above seem to be broken.
NextGen FOC High voltage 144v/34s, 30kw (https://vesc-project.com/node/1477)
In your purchased files, it's stable now
I tested 5.1 yesterday on my hardware at 90v. It seems to be working fine. Inductance detection is still hit and miss at hight frequencies but dropping it to 5kHz makes it more consistent.
NextGen FOC High voltage 144v/34s, 30kw (https://vesc-project.com/node/1477)
Sometimes, after connecting the VESC Tool, when controlling with the left or right arrow keys, it may perform a different action than the brake. It happens the moment released the arrow keys. At this time, the motor does not rotate, but the motor makes a noise that increases in frequency.The same thing happens with FW 5.01.It also often appears when controlling in PPM mode.
Pages