VESC-Tool 2.04: FW 5 >> A BIG STEP FORWARD

[Titoxd1000]

@Deodand I updated my friends board to the newest firmware (5.1 i think)… on the first real pull he got launched, loss of power I believe (maytech esc, hes okay thankfully) I’m trying to rule out bad battery… So I’m wondering would a battery that can’t supply enough amps, would that throw out a fault because we didn’t get any faults at all. Or does vesc firmware have any sort of protection against that kind of instant power loss

[stratoglide]

I’ve also had this experience with HFI. To make things even weirder I’ve had it work flawlessly for 30km of riding then proceed to fuck itself up and consistently try to turn my toeside motor in reverse.

I really wanna love it, I love the sound but there’s definitely some work that needs to be done to make it flawless.

[BenjaminF]

If the battery is discharging through a BMS, then the BMS can cut power like this and the VESC would not throw a fault.

[ducktaperules]

If the battery cannot deliver enough power then one of 2 things can happen.

1. The battery will sag and the battery voltage will drop until the vesc begins to limit the power due to the low voltage protection limits. This will result in a gradual reduction in power but will continue to operate.
2. The BMS will cut all power from the battery. In this case the VESC is shut down and there is nothing it can do.

It might help to describe his current setup. what battery is he using? what BMS is fitted? is it being used in discharge or bypass?

[ducktaperules]

Thanks for this explanation. upon re-examining it seems like this is exactly whats happening.

i dont think this is clear or inline with the way other parameters on the vesc are configured. It would make much more sense to be able to configure the acceleration and regeneration start and end temps individually. We have different motor current settings for accel and regen, same for battery current, why not have the same for thermal throttle values. That way the user is able to set clear limits for both without having to do lots of math to work out the limits they are setting.

[taz]

@fessyfoo made a handy calculator

Archived: the OG noob question thread!

So I don’t think I fully groked “acceleration temperature decrase” Decrease the motor and MOSFET temperature limits by this amount during acceleration. This is useful to still have braking torque left when the components get warm. A decrease of 0 % means that the acceleration temperature limits are the same as the braking temperature limits, and a decrease of 100 % meanse that the acceleration temperature limits are at 25 °C. I think that means acceleration starts throttling before you hit …

[ducktaperules]

thanks, that is a useful visualisation of a feature that is needlessly complicated.

[Titoxd1000]

The BMS is bypassed. One of the P groups was recently replaced. Prior to replacing that P group he experienced less power than normal going up hills. He says hes still having the same issue after. So my concern is the the battery could be compromised. I’ll ask him to check if they get out of balance… It’s a belt setup, dual 6374 with pnuematics. (100 motor, 80 bat) 12s8p 30q pack… The board did not turn off he just got a cutout with no faults

[taz]

I like the way it is implemented but would prefer an actual temperature differential instead of the percentage.

[hans_maier]

Bricking the VESCs for example is pretty easy … I managed to do it at least once

[malJohann]

@malJohann

any idea why the behaviour of HFI changes when I set only the Sensorless ERPM HFI lower? Surely it shouldn’t change how it behaves, just when it stops functioning?

e.g. With my Sensorless ERPM HFI set to 1000 it works perfectly on flat or slope, lower it to 750 and it starts with a bit of a jolt and trying to start on a slope has it freaking out, lower it to 500 and I’m stuck rocking in place going nowhere even on flat ground.

Also, I have to really crank up the Battery Current Max for it to work. On the Stormcores 60A isn’t enough, but on 100A HFI works well.

@Deodand do you maybe have any ideas on this?

[bwahl602]

Oh haven’t looked for it yet. Is push to start enabled for unity and does anyone have it functioning okay?
I remember there being some issues with remote repairing or something

[Deodand]

Push to start is enabled. Sometimes the VX1 reciever doesn’t boot cleanly for some reason.

@malJohann Probably a certain amount of noise in the RPM measurement (we use a special faster/noisier one that what is displayed) at startup could make it exceed the limit? I’m not 100% sure but that is my best guess. I would keep it at 1000 as that is still really low.

[Jc06505n]

Hey @Deodand, hoping you can answer this question, does the Official VESC FW have Cruise Control? I I’m thinking of implementing a Push Assists Mode based on a modified version of cruise control, but it seems that it’s only limited to the VESC Wand Ackmaniac firmware, and remotes?

[ducktaperules]

“Cruise control” is basically PID control and it is implemented in some of the control apps. Specifically if your using the “nunchuk” app then cruse control is supported by pressing the c button. the nunchuck app is whats used by the wand and other uart remotes with CC functions. this should work on all recent and current firmware’s.

Code for how this works is found at https://github.com/vedderb/bldc/blob/dev_fw_5_02/applications/app_nunchuk.c line 294 and onward.

Are you planning to add push assist that is activated by the remote or a true “endless ride” style where no remote is necessary?

[Jc06505n]

@ducktaperules

“Cruise control” is basically PID control and it is implemented in some of the control apps. Specifically if your using the “nunchuk” app then cruse control is supported by pressing the c button. the nunchuck app is whats used by the wand and other uart remotes with CC functions. this should work on all recent and current firmware’s.

Code for how this works is found at https://github.com/vedderb/bldc/blob/dev_fw_5_02/applications/app_nunchuk.c line 294 and onward.

I see awesome! Thank you so much! I’ve taken a look and learned a lot from it.

@ducktaperules

Are you planning to add push assist that is activated by the remote or a true “endless ride” style where no remote is necessary?

I’m more so planning more closer to Mellow’s implementation: a “Timed-Cruised Control”. My idea is having it as a Control Type where there user can set a MAX ERPM, MAX ERPM Holding Time, and Normal ERPM Holding time. The Remote’s only function is: to be on so that the mode will function and allow breaking. With the VESC Tool App, it should be a matter of selecting a profile to switch back to another Control Type Right?

I don’t see a way of doing endless ride without a remote since breaking is a needed feature. Adding sensors at that point it seems more like a solution in search for a problem that’s already solved.

[ducktaperules]

I think you would have to make “endless mode” a control option that sits alongside the other options eg “current”, “current no reverse”, “smart reverse”. you have to add this new control mode to each different type of remote that you want to support. At a minimum that is probably the PPM app and the Nunchuk app.

IMO the current remote configuration and control type of the vesc is less than ideal right now. Ideally the input type (eg ppm, nunchuk, adc) should be decoupled from the scaling/calibration/expo which should also be decoupled from the type of control that is being used. This way new control modes could easily be added which would be supported by all input types. Likewise new remote types would instantly support every control type. It would also mean that many setting like throttle expo would be found in a single place in the vesc tool rather than in multiple tabs depending on remote type.

/rant

[Jc06505n]

@ducktaperules

I think you would have to make “endless mode” a control option that sits alongside the other options eg “current”, “current no reverse”, “smart reverse”. you have to add this new control mode to each different type of remote that you want to support. At a minimum that is probably the PPM app and the Nunchuk app.

Yup Exactly my plan. Since Trademark could be a hassle I plan on naming the Control Type: “Push Assist” instead of Endless Mode.

@ducktaperules

IMO the current remote configuration and control type of the vesc is less than ideal right now. Ideally the input type (eg ppm, nunchuk, adc) should be decoupled from the scaling/calibration/expo which should also be decoupled from the type of control that is being used. This way new control modes could easily be added which would be supported by all input types. Likewise new remote types would instantly support every control type. It would also mean that many setting like throttle expo would be found in a single place in the vesc tool rather than in multiple tabs depending on remote type.

Yeah when looking at the tool and the gihub, I didn’t like how it was all inter-looped. But I can manage. Thank you so much man.

One further question, how does PID and Cruise Control work on going down hills? Does the Current FW have it where the board will try to retain the set speed and be successful or will it speed up and once you’re off the hill it retains the speed it achieved from the descent?

[ducktaperules]

Never tried it but from looking at the code I would assume it tries to maintain the current set speed regardless of if it’s up hill or down hill. I don’t see anywhere that it ajusts the set speed based on over or undershoot of the target.

[Jc06505n]

Perfect , Thank you so much!