VESC-Tool 2.0 and Firmware 4.0 - The beginning of a new era - (SERIOUS)

[Trampa]

VESC-Tool 2.0 and Firmware 4.0 - The beginning of a new era

The year 2020 started with a super intense coding session in Nottingham. Miserable weather, tons of perfect mud in the Colwick Woods, hardly any chance to go for a proper ride… Our special guests Jeffrey Friesen and Benjamin Vedder decided not to get bored while waiting for ridable conditions. The outcome was a new exiting feature called High Frequency Injection, also known as signal injection.

HFI:
HFI sounds very technical and doesn’t immediately give you an idea what it does.

Basically it does give you high torque startup without cogging, even if your motor has no sensors.
A lot of motors don’t come with sensors and a lot of sensored motors get sensor issues over time.
HFI is a nice fall back strategy for broken sensors and an excellent way forward for sensorless motors.
At this stage you will hear a bit of a high frequency noise for a second, before the Back EMFs kick in and signal injection is switched off. Sensorless startup will work best on three shunt designs as far as I understood.

@Deodand will probably tell you more about it all in this thread.

What else is new in VESC-Tool 2.x

Support for old firmware:
VESC-Tool is now supporting older firmware. If your system is running fine and you are happy, things can stay as they are. You will get a message like this:

The connected VESC has old, but mostly compatible firmware. It is recommended to update it for the latest features and best compatibility.

VESC-Tool will not force you to update the FW, while allowing you to run the latest software tool. The support for really old firmware is not given at this stage, but at least 3.55 onwards will see support. If your firmware has a bug, you will see a WARNING and a brief description of the bug (e.g. FW 3.63 and 3.64). In such a case, please update even if you haven’t experienced issues so far!

Dynamic User Interface:
New features often come with new user interface entries and options to choose from. If you use old firmware, you will not see options that are only available with later firmware versions. The user interface will adapt to your firmware. This feature was needed to make old firmware work in combination with a newer VESC-Tool software.

Back up of your entire configuration (ConfBackup):
One thing that was a bit annoying in the past was the need to re-run the setup wizards each time you do a firmware update. This is now solved via configuration backups, which are assigned to the UUID of the ESC. You can save the entire configuration prior to a firmware update and then restore it after the FW update finished. Everything stays exactly as it was before the update, for all VESCs in an array. VESC-Tool 2.0 had a little glitch with this feature. This is now resolved with the 2.01 version.

An outlook for 2020:
Jeffrey and Benjamin will try interact a lot more in future. We will probably see support for ESC designs using a shared processors for two ESCs. If you own a Unity for example, support for it is probably happening in a overlookable time frame. This way such devices get a future and do not suffer from lack of software updates, making them obsolete sooner than later. The integration of single processor support also allows new and potentially interesting HW designs. Please note that the amount of work to make this happen is not little. Give it some time!

There are also plans to make something happen for the Apple users. More to be announced once more thought is put into it. There are several options on the table to go forward on this matter…

Here are two videos with tons of more information:

Please consider a donation to Vedder to keep him motivated and to allow further software development.

VESC-Tool 2.x can be downloaded here:

https://vesc-project.com/vesc_tool

play.google.com

VESC Tool – Apps bei Google Play

This is the mobile version of VESC Tool, which can be used to configure VESC-based hardware over BLE. It can also be used to stream live data, update the firmware and many other things. For details, visit https://vesc-project.com For VESC Original hardware, see http://www.trampaboards.com/vesc--c-1434.html To connect to a VESC over BLE, a compatible BLE module is required. They can be purchased here: http://www.trampaboards.com/vesc-connect-nrf-wireless-dongle-p-26767.html you can also build ...

1,99 $

[moon]

HFI looks good

[Brenternet]

TLDR;

Nos for skateboards

[Trampa]

HIFI for Skateboards

[Brenternet]

On a serious note. Good to see collaboration and the possibility for continued support for those of us enjoying our unity’s. Thank you for making the effort Ben and Jeff.

[ducktaperules]

looks like interesting development and its good to see the 2 branches unifying. This makes sense to improve feature sharing and cross comparability.

[Gamer43]

HFI only works effectively on SALIENT pole PMSM.

Most BLDC motors do not have iron surrounding the magnets and thus are not salient pole PMSM.

This is actually a technique implemented by Texas Instrument’s Insta-Spin FOC.

It works by measuring changes in phase inductance as a result of different rotor position, which requires a salient pole rotor to be meaningful.

[Zach]

Awesome stuff Frank! Please pass the word on to Vedder that his work is much appreciated by all! Really cool to see those two working together, and im hopeful for what this means for the VESC project. Progress is always welcomed!

[rusins]

Basically it does give you high torque startup without cogging, even if your motor has no sensors.

Does this work only when first turning the board on (motor isn’t saturated yet), or does it work basically every time you stop during a ride? Super cool either way! Can’t wait to test it on my friend’s Haya in a couple of days

Edit: oh wait, Focbox is vesc 4 based (2shunt design), doh

[tipsy]

Explain without the sciency lingo

[Deodand]

Saturation is a near instantaneous effect so it won’t matter how long you are riding.

Most BLDC motors do not have iron surrounding the magnets and thus are not salient pole PMSM.

All motors exhibit some degree of saliency due to imperfect symmetry in the rotor. Some motors are designed to maximize saliency for various reasons, but we don’t need much to detect position because the algorithm is pretty robust to noise. Watch the video for more information and try the latest update to measure the saliency of different motors yourself.

You will see in the video vedder mentions he tests motors he has lying around and the only ones from this limited set that didn’t work were 2 pole inrunner motors.

[Gamer43]

All motors exhibit some degree of saliency due to imperfect symmetry in the rotor. Some motors are designed to maximize saliency for various reasons, but we don’t need much to detect position because the algorithm is pretty robust to noise. Watch the video for more information and try the latest update to measure the saliency of different motors yourself.

You will see in the video vedder mentions he tests motors he has lying around and the only ones from this limited set that didn’t work were 2 pole inrunner motors.

What I am skeptical about is the torque generation efficiency. Considering the VESC’s actual sensorless algorithm doesn’t achieve optimal torque generation until around 40% duty cycle (for whatever reason), I do not think this method will be would be worth the additional software overhead, considering most skateboards get a kickstart and ride on flat ground. While BLDC motors used here do have some saliency, I am skeptical that a (relatively) low bandwidth controller such as this can accurately lock onto the (relatively) weak signal in such a noisy environment.

Quadrature encoders are super cheap now, you can get a 8192 PPR encoder for under $24 from CUI devices. Personally, I’d rather invest resources into designing an easy mounting solution for these encoders. For most belt drives, this is simply a pulley cover with the appropriate holes with a motor that has a sufficiently long shaft.

[Deodand]

Considering the VESC’s actual sensorless algorithm doesn’t achieve optimal torque generation until around 40% duty cycle

You always make these really negative claims about the VESC software with very little data shown to back it up. I’d love to see where you got this result from and also it should be said that this can only apply to whatever setup you gathered the data from and not generalized.

Personally, I’d rather invest resources into designing an easy mounting solution for these encoders.

The less wires I have running external to an enclosure the better. Reliability is king and if an additional sensor isn’t needed for efficient operation it shouldn’t be there. Try testing out the algorithm before writing it off as useless. In some applications an encoder will be best, this approach offers some interesting trade-offs for different applications.

[Gamer43]

You always make these really negative claims about the VESC software with very little data shown to back it up. I’d love to see where you got this result from and also it should be said that this can only apply to whatever setup you gathered the data from and not generalized.

I’m not the only one who’s experienced this phenomenon. @Pedrodemio has also experienced this on his ebike build. I’ve used motors sized from 5065 to 63100 with KV ranging from 130 to 270 and experienced this. I wish I had the data to prove this, but I don’t have a dynamo setup. I will try asking someone I know who does have a dynamo if they can try testing this.

Just a by the way, my TRAMPA VESC 6 mk3 says my maytech 6374 motor has a phase resistance of 16mOhm and inductance of 9.98uH.

I know for a fact by using a power supply and RCL meter that the phase resistance is actually 19.25 mOhm and phase inductance (at 30kHz) is 35uH.

I suspect this discrepancy in the measurement is what contributes to the less efficient torque generation at lower speeds, because the different resistance measurement causes a ratio of the phase current to show up in the estimated BEMF.

[agentdev]

The backup feature rocks… this has been a must-have if the goal is to keep users up to date.

Great work as always Benjamin.

[DEEIF]

@Deodand Does the hfi work on OG Focboxes?

[Kalitapaws]

Possibility of ports of this to iOS hopefully soon too?

[Pedrodemio]

@Pedrodemio has also experienced this on his ebike build. I’ve used motors sized from 5065 to 63100 with KV ranging from 130 to 270 and experienced this. I wish I had the data to prove this, but I don’t have a dynamo setup. I will try asking someone I know who does have a dynamo if they can try testing this.

That is also one of the goals I want a dyno, teste between sensorless, hall sensors, encoder and now HFI

Before I say anything, this is just an edge case, VESC and VESC derivatives is still the best we have, and is really few scenarios that this is an issue

That the VESC has lower torque at really low speeds is a fact that anyone can test. Find the steepest hill that you can climb at speed, it has to be on the edge of what your board is capable, or lower the motor current until it’s just enough for you to climb it at speed

Now try to climb at walking pace or slower, it won’t be capable, while in theory it should since torque is directly proportional to current, and the current your are applying is the same

Or it’s due the hall sensors due to it’s nature not being capable of reporting exact position and so the maximum torque isn’t being produced, if that is the case a encoder will solve, or is something deeper

@Deodand and @Gamer43 am I right in saying that the new HFI offer better angular estimation than hall sensors? And if that’s the case should low speed performance be better with it?

Genuinely asking, I haven’t had time to update anything to 4.0

Amazing work guys, hope to see this trend continue on the future

Also since you are here, @Deodand what do you have to say about the temperature measurement using motor resistance? Is it feasible now the the whole project is more mature? It would be in line with your thinking of less wires = more reliable

Getting motor winding temp without sensors

How accurate is the ohm meter on the vesc tool? Could get an overall winding temp by doing the bldc test and figuring the temp from increased resistance. Is that possible easily these days from a phone app? And said the wire could have roughly 15c hotter hot spots on a typical winding With increased heat it’s increased inefficiency and the eventual enamel failure

[mattsdominion]

Not to go OT, but just updated to firmware version 4 and now my vesc tool 2.01 (android) and metr do not work. I can only connect to the VESC (flipsky 6.6 dual 200a) with a usb connection and the vesc tool from my cellphone.

Any troubleshooting steps that I should be taking right now, or should I attempt to roll back to 3.64 (last working firmware)

[Deodand]

That the VESC has lower torque at really low speeds is a fact that anyone can test. Find the steepest hill that you can climb at speed, it has to be on the edge of what your board is capable, or lower the motor current until it’s just enough for you to climb it at speed

I don’t know if I’ve noticed this or not, but I’ll try and focus on it during my next ride. I always kind of thought it was a perception thing as accelerating at higher speed always feels more intense to me than lower speed. I’ve never had a problem accelerating up hills on any of my boards in the absence of some other issue like thermal throttling.

If you had a very even hill and set amps quite low then maxed throttle and logged RPMs you could back out a noisey torque estimate… or better yet I think the vesc 6 logs inclination angle so you could crunch the data of that as well.

Or it’s due the hall sensors due to it’s nature not being capable of reporting exact position and so the maximum torque isn’t being produced, if that is the case a encoder will solve, or is something deeper

Either way on hall sensors with 6 updates per rev you’re looking at an error of ± 30 degrees worst case which would cost you ~ 13% torque from standstill, as you get going a phase locked loop tracks speed and interpolates so you do a bit better even at very low speed.

@Deodand and @Gamer43 am I right in saying that the new HFI offer better angular estimation than hall sensors? And if that’s the case should low speed performance be better with it?

It definitely offers a higher resolution/update rate as compared to hall sensors (~ 500hz is the rate at which the DFT is computed) but as to the accuracy it is hard to say, testing on the bench it appears very accurate when you overlay plots from encoder but that might get skewed at higher currents.

Also since you are here, @Deodand what do you have to say about the temperature measurement using motor resistance? Is it feasible now the the whole project is more mature? It would be in line with your thinking of less wires = more reliable

I’ve been working on this. It’s a simple SISO system and I think a basic Kalman filter with a first order thermal model and scaling measurement update should do the trick. I think the secret will be to scale the measurement update weighting with the motor amps and speed, at low speed and high amps you can get a very accurate and clean estimate of the winding resistance. You can get the high frequency thermal behavior from system dynamics and then the slow dynamics can be taken care of by a heavily averaged resistance estimate.