VESC FW 5.x - Beta Testers wanted [SERIOUS]

I’ve been trying to use larger EV motors with VESCs to no avail. I’d love to be able to provide data as I know that some vesc projects have turned up for EV use. Unfortunately I am unsure of how my testing setup needs to change to accommodate these larger motors but I would appreciate any features that are targeted towards this market as it is obviously a target for Benjamin. Anyone with guidance on this issue would be great

3 Likes

Can you share which motor and which VESC model you’ve been trying ? Which battery voltage ?

Bigger examples I know of are running higher voltage and pretty high amperage than off the shelf VESC6 and 4. However on principle, even a 10 and 12S setup should work :thinking:

I think it’s this.

A Toyota Pruis drivetrain and FSESC 6.6

2 Likes

Ok, here is a probable cause : very low Kv motor and too low voltage setup causing detection issues for the VESC classic current sensing scheme. Also it’s a big mass of motor, how much amps are needed to run detection?

FSESC6.6 is way underpowered for that thing.

Only official version I know able to drive at circa 450/500v this would be Axiom. Already runs in a CRX conversion.

4 Likes

While rated for 500V these things can most definitely be run lower than that. I’m not sure of how many amps would be needed to get it to spin up, and I didn’t want to up the amps and have a spectacular explosion. I don’t care that the vesc doesn’t work in this specific scenario but if there is a way to get it to run on a normal 12S battery for testing that would be awesome

2 Likes

I’m ready with my changes on app_ppm.
Tested on bench with all control types.
I added a last minute feature :

  • ADDED : Traction control auto-disabling in case of fault on master, re-enable only if no effect on motors will happen (avoid weird behaviour exiting fault state on master).

Unfortunately, I can’t do the same on slave as it doesn’t send the fault over CAN (Could be great to use half of the spare slot in CAN_PACKET_STATUS_5 for this, couldn’t be?)

However, looking at app_nunchuk (WAND) if I want to apply the same relative command strategy (sending % instead of absolute current value), it would require to change the way the ramping is done (currently, ramping is done directly on current output instead of relative setpoint (%) like in app_ppm).

So, I’m not sure I want to touch this as it may lead to affect the remote behaviour for users and change ramping pos/neg parameters units (and default values). :confused:

For app_adc, it’s already using relative current value. :man_shrugging:

5 Likes

I was looking at the spec sheet of the brand new 900 volt fets. Motor controllers are going to take a quantum leap.
tenor (11)

I was confused by this when I was comparing app_nunchuck’s Cruise control implementation and app_adc’s. Opened an issue to see what was up with the that

1 Like

My App PPM has been merged to the dev branch.
Please, keep in mind that, if you want to test the last version out, it could behave strangely !
I was able to test my work on the bench only as I was still missing some part to rebuild my board for a real ride.

I’m really curious to read your feedbacks !
Thanks testers !

7 Likes

@Pimousse thanks, I just flashed this to the stormcore and will let you know how it goes.

FYI, this new build also adds @NuRxG support for IMU on Stormcore and Unity.

i have tested on stormcore 100D and the IMU is showing up, going to try balance app tonight. i believe the 100S is also tested. The IMU on unity is not currently tested but should in theory work (@Flux)

4 Likes

Thanks buddy!! :grin:
my unity is not fully working well after some water encounter, so the IMU doesn’t show up, probably the ESC is faulty, I can’t confirm anything.

1 Like

I’ll give the beta FW a try on the unity I have on the bench and see if motor temps come back.

As far as the unity guys that are having issues. You don’t have to write your settings down.
Just connect, Scan the can, then proceed with writing your motor settings. Run foc detection and write.
Now, hit the CAN button and write the current motor settings. Viola, you copied everything. Now just overwrite the foc parameters when you do motor detection on that side and you’re don’t.

I almost never hit the “read” button because I’m always moving thay way. Write to one, write to the next and do the foc for that side. Then I don’t hit the motor parameters again.

1 Like

My focboxes spit out faults like it’s no ones business.

Does this mean if there is a slave fault, master keeps going… and a master fault slave keeps going? if so I may be loading this up tonight and giving it a go tomorrow.

Sorry for the late reply.

This is already the case with current FW

This is the purpose of my PPM app rework :+1:

Anyone could give the latest beta a try ?
Still no board rebuilt yet for trying IRL. :confused:

1 Like

Did you ever get the motor temp issue resolved?

This doesn’t work for me :confused:. When I click the can activate button, it reads the settings for that side and I have to change them again.

3 Likes

I’ve had this too with the flipsky vesc I have. I’ve found that it’s 100% based on the usb cable I’m using. Some will maintain the connection, some won’t. I’ve also found that they also require the setting that says something like “can message 1,2,3” which keeps the can active between the two and cable drop outs during setup happen less.

I tend to set up both sides individually though. I’ve never been able to use the setup wizards because of the inconsistent can connection and I’ve yet to find a usb cable that works consistently

1 Like

index

Hi dear testers !

The new VESC FW is about to be released (release date : 10th of January 2021).
Benjamin Vedder decided to stop adding any single line of code from now until the release date to allow a nice and clean testing phase. :+1:

Please, download the latest VESC Tool and update your VESC with the included FW :

For those who complain with the “Duty cycle current limit start” controversial stuff, it has been reworked and should be ok with this FW ! Try it !

Please post your feedbacks here.
If no negative feedbacks are given, this FW will be considered as STABLE and released to every user.

WARNING :
Keep in mind that this version is in TEST.
Wear your helmets and gear and keep in mind that shit may happen while you’re riding.

Changelog :

  • Bidirectional current mode for VESC Remotes.
  • Motor temperature measurement fix on unity and stormcore.
  • IMU calibration improvements.
  • VESC Tool does not allow uploading firmware to all VESCs on the CAN-bus if they have different hardware versions.
  • Added LSM6DS3 IMU support.
  • Added MTPA support. See See: https://github.com/vedderb/bldc/pull/179
  • App PPM rework. See https://github.com/vedderb/bldc/pull/192
  • SWDPROG (blackmagic probe) improvements
  • App Balance updates. See https://github.com/vedderb/bldc/pull/193
  • Motor current now based on magnitude of both axes.
  • Initial VESC BMS support.
  • Hall sensor interpolation improvement.
  • Made hall sensor filter configurable.
  • Added locking time and ramp up time parameters to sensorless startup.
  • Initial VESC IO-board support.
  • Added hall sensor interpolation ERPM config option.
  • Use fast speed estimator for RPM limit.
  • Avoid accumulated rounding error when using PID position angle division.
  • Added UAVCAN raw throttle drive mode (current or duty cycle control).
  • Added MT6816 encoder support. See https://github.com/vedderb/bldc/pull/238
  • Added modulation-based D axis current controller gain scaling. Addresses https://github.com/vedderb/bldc/pull/220
  • Added PAS app. See: https://github.com/vedderb/bldc/pull/243
  • Added 100k CAN-baudrate.
  • Added 100k NTC temperature sensor support.
16 Likes

I don’t know about you, but this sounds awfully like a COVID vaccination :smirk:

3 Likes

Well spotted.
TBH, some call me the “King of deadline & vaccination”.
:face_with_hand_over_mouth:

2 Likes

already running this update. will let you know if i encounter anything weird :+1:

4 Likes