VESC HD, a credit card sized twin motor controller

No space for a big fat C. We dropped two micros on. Personallly I never connect via USB anyway. NRF 52840 is the bridge to use.

3 Likes

The NRF is included in that size package.

2 Likes

My bad, what is the “VESC dongle connect” ?

That is an external NRF module for the VESC 6 or any other VESC we offer. Depending on the motor controller or its location you might need an external dongle. Some guys place these units inside a battle bot for example. Not good for reception…

2 Likes

Chime in here and let him know

Right now it looks like it’s not desired by anyone except me.

8 Likes

We considre to ask you a question in the wizard. Is your application skateboarding? When yes, we drop it to 85%

5 Likes

Why not have done an outing with just one take?
Where do you sell the adapter?

1 Like

just an FYI, it seems like these defaults can be changed for each hardware build. Interestingly it looks like @Deodand already changed this default to a safe value of 90% for the storm-core builds.

#define MCCONF_L_DUTY_START 0.9 // Start limiting current at this duty cycle

its found in " hwconf/hw_stormcore_100d.h" submitted 21 july as part of commit 7e212b58d414027cf090dc56f5a5cf6ca8f50e4b

This value overrides the dangerous default value for all Stormcore builds. you can still change it as required, it just starts at something more sensible.

I guess any other hardware variant could be set to do the same.

3 Likes

We have two separate power stages in the HD, which allows you to fix things if one channel blows up. Also we don’t want to run 200A over one PCB, so the power is split into two inputs. Adaptor PCBs will be dropped on the website soon. I will also design some different versions with fuses on.

1 Like

It is better to do a proper fix where it belongs. Most applications demand fro full power till max ERPM.
So the Wizard asking for your application is the best place.

1 Like

dont think anyone disagrees with this, but its the fact that it instantly switches to 0% power when it hits that rpm that is causing the problems. This never used to happen with the old implementation.

12 Likes

^ what Q said, + the actual bug that when the duty cycle current limit start is equal to the max duty cycle, the motors don’t just “lose power”, they come to a full halt instantly (and don’t spin back up unless you let go of the throttle). Can’t imagine that being a good thing for any VESC use case.

4 Likes

Nope, it just delivers full power till full ERPM. It feels a bit strange when the acceleration stops. The old implementation didn’t allow full torque at full ERPM but that got improved.

Max duty cycle limits should not be set. If you want to limit the top speed, please use the profiles.

Are those even in the desktop VESC Tool?

Top speed limiting — especially bottom speed limiting (aka fastest in reverse) — are a chronic deficiency of the VESC software features imho

“speed”, not “duty cycle”

Setting minimum erpm Motor Settings > General > RPM > Max ERPM Reverse cuts out your brakes above (below) that speed, but otherwise works in FOC (it’s extremely jerky in BLDC) :crazy_face:

1 Like

This might be what is supposed to happen but im not sure that is what actually does happen.

Im not an expert, jsut posting my understanding but Im 90% sure the problems people are seeing are coming from code in this commit :https://github.com/vedderb/bldc/commit/57c5d04214ea0665e385d0e79818f50924cf3572

It says :

if (duty_now_abs < conf->l_duty_start) {
		lo_max_duty = l_current_max_tmp;
	} else {
		lo_max_duty = utils_map(duty_now_abs, conf->l_duty_start, conf->l_max_duty, l_current_max_tmp, 0.0);
	}

Its hard to read but as i understand it the code is saying :

if current duty cycle is less than the new "duty cycle current limit start"  {
		then current limit is the max current;
	} otherwise (if current duty is more than the limit) {
		then current limit is scaled from the max current to 0, depending on where the current duty cycle value is between the  "duty cycle current limit start" and the "maximum duty cycle".
	}

So here is my thinking,

Previously it seems like this code pays no attention to duty cycle, it always delivers full current irrelevant of duty cycle. It Seems like somewhere else the Software, the power is reduced to observe the 95% duty cycle limit.

As you hit the 95 % limit you just get limited power due to physics, but limited power != 0 amps. Its suddenly less amps but still some amps.

With the new code it actually fades you out to 0 amps.

HOWEVER the closer the “duty cycle current limit start” is to the “maximum duty cycle” the quicker this will happen.

so what happens if you have this new current limit set to 95%? This fade suddenly becomes a binary switch. at 94% you have full power. and as soon as you pass the limit all current is instantly cut to 0 Amps, probably causing you to slow down. As soon as you slow under 95% duty you get full power back again. This could easily show the behavior users are seeing.

Furthermore this calculation happens independent for both motors possibly causing the power cuts to be out of sync for both sides.

Additionally the default setting is 100% so in the rare case you reach 100% duty you will drop into the else condition and cause some sort of weird values to be put into the mapping function where the max value is smaller than the min value. no idea how well that map function would handle that situation.

Again this is my understanding and it may be incorrect, If anyone has better understanding of whats going in here it would be good to try and fully work it out. i don’t think these issues are a fault of the feature, just something unexpected happening due to its implementation.

Maybe there is a simple fix to ensure the default setting of 100% keeps the old behavior, eg.

 if (l_duty_start = 1) {                                # if set to 100%
     lo_max_duty = l_current_max_tmp;   # use old behavior
 }  else {
    #do new behaviour
 }

Anyways . . . i realize that is is getting a bit of topic so if your not happy with this here we could always get it moved to somewhere more relevant for this discussion to continue.

13 Likes

It is best moved to Bens Git. He reads it and considerers the input for the next release.

2 Likes

@Trampa do you know if development on HFI is going to stop now that new Trampa hardware is focusing on ASS?

5 Likes

@MrDrunkenMobster

40 Likes

@trampa What are the dimensions of the mounting holes? Hopefully it somehow fits the community heatsink :man_shrugging:

1 Like

And hopefully its accurate this time

9 Likes