In foc openloop I was trying to put a load on my motor of 40A at 10,000 erpm to approximate real running
conditions. I found that at 5 & 20A I could only increase the erpm to 4-4,500 before the motor
would not start & shook so violently that the 4 nuts on my motor holding jig unwound.
Not a nice situation. Could a soft start be added here to stop this happening.
Thanks, regards Alan
please consider adding a setting to ramp down "deceleration jerk" - when you are at power and you let go of the throttle on the remote and it snaps back to neutral. It would be nice if a rolloff rate or time could be put in there to smooth that out.
Similarly, could we have a setting for Idle % above zero? I would like when I release the throttle to neutral for the board to seem like there is no motor drag - to roll like a regular push board. So I could set it at 1% or 2.4% depending on how much drag my motors create.
Thank you,
Hi There,
I'm working on a project where I would need to know the exact location of the motor based on the encoder position (number of ticks detected). I'm using the ros nodes built by MIT for their Racecar project but I've noticed the tachometer UART output is not always accurate and seems to change position even with the encoder unplugged. I was wondering if there was an easy fix for outputting the encoder position (raw?) as detected by the firmware without being fused with any other data?
Many thanks,
Nathan
I know this might be a ludicrous request or might have been discussed some where already (looked and searched around but couldn't find anything. apologies if so be).
But a vast majority of battery types being sold are 5S, and insane projects having even something between 8S-12S batteries.
I am trying to get a better understanding of when watt-hour data gets rezeroed on the VESC and on the app (ESC Monitor). I know that every time the VESC is power cycled, the displayed DISTANCE and WATT-HOUR data on the app are rezeroed. However, I noticed that the estimated remaining RANGE seems to use WATT-HOUR data that is not rezeroed when board is power cycled. This is a good thing, because obviously you may turn off your board mid-ride and not want to lose that data.
So my questions:
The duty cycle limit (95%) is present to:
The capacitor anyway get charged at least once for each electric revolution even at 100% duty cycle and max over-modulation. So the duty cycle limit should only be needed at low RPM. This raises the question: How often does the high side capacitor need to be charged? (What is "low RPM"?)
I was wondering why it's not possible to modify the minimum ERPM in FOC mode like for BLDC mode. It seems that the value is set to 1500 ERPM by default. Some E-Skaters that run a low gear reduction have the issue that motor locks up at fairly high speeds, sometimes enough to throw the rider off:
An low battery / prolonging battery / skate feature request! The Mellow Boards Endless mode is quite nice. It would be great to have this option available. Take a look at their official YouTube-channel that introduces the mode: https://www.youtube.com/watch?v=AWWLP7TwsDU
So how I understand the feature is that as long as the throttle or brake is not activated, the ESC listens to the RPM. In my simple mind without knowing much about the bldc-code, I thought the following logic:
1. Throttle protection (for safety reasons)
I have noticed if regeneration is applied at the same time with the throttle and regeneration is released you get instant drive from throttle if it is not in zero position. In my opinion if throttle is applied during regeneration (in most times by accident) and after releasing regeneration throttle should have no response until you set it to zero.
2. Faults saving to EEPROM
Have you ever considered making a lightweight portable version of the FOC code to speed up development and aid in adapting it to different projects? The VESC works great for a user friendly adaptable motor controller but the enormous scope of the firmware and features make heavy customization extremely difficult. Porting the entire firmware to any other MCU is also extreme in its current form, chibiOS rarely gets ported to much and even with full chibiOS ports the VESC firmware itself contains considerable STM32F4 specific code.
