Hi, I'm new to VESC. I am thinking of using VESC in my robotics application. Up to this point in time, I've been building smaller robots (~3 to 5 lbs; ~1.6 to 2.4kg). I've been using BLHeli32 ESCs which (as most here already know) were developed foremost for the quad-copter community. I now want to build larger robots and need sturdier/larger ESCs and motors. In my application, I have a need to update the ESCs at a very high rate. The BLHeli32 ESCs have a protocol, dShot1200, which I've been using, and this protocol can support update rates as high as 32kHz. The motors I've been using do demonstrate torque/RPM changes in less the 1 millisecond, the high update rate is about making the change occur at the desired time.
Does anyone know what type of refresh rate the VESC firmware can support, and what type of response times the firmware can provide? The BLHELI32 was designed expressly for high update rates. My concern is that the VESC firmware never had response time and refresh rate as part of its design goals and behaves at a lower order of magnitude.
I've started reading through the firmware code, and examples provided by numerous people, but have not found much discussion around these metrics.
You are correct that such update rates are not of interest to most users. Update rates in hundreds of Hz are plenty for a light vehicle moving a human around.
32 kHz update rate for communication to the ESC is really fast!
I don't need 32kHz... I have found that 8kHz is fast enough. Has anyone ever measured or spoken about the processing loop times of the firmware? With BLHeli, it is discussed due to the processing loop time's inherent importance with the firmware making the adjustments as the motor turns. This processing loop time establishes a real world constraint on what adjustments the firmware can make to the motors via the MOSFETs. Certain firmware configurations and demands of those configurations can place overhead on the processing loop time, and thereby constrain what the firmware can realistically do... depending on the firmware and its implementation, it can even explain why certain settings work well and others don't at certain speeds.
I mention all that to explain what I am looking for... with BLHeli, the developers have written about how certain settings constrain other settings, and their impacts on update rates. It seems the the firmware developer(s) of VESC must have thought about these same issues and constraints. I was hoping that some of this discussion was accessible.
In my application, I can deal with a slow response time, as long as it is consistent (the total pipeline response time between issuing speed command change and motor response time can be anticipated) and dealt with in my application's software. However, I have learned that the larger the pipeline delay is, the "sloppier" the overall system behaves.
Jim Kazmer
Here is some data I created based on my prior robot's test bench... I'm a few weeks from doing anything like this with VESC...
As the graphs show, the 1050kV motor with a 3S battery and BLHELI-32 ESC can change the motor power 10% in about 100ms. 66% of the incremental change is completed in the first 20ms.
The data points seen are calculated from the eRPMS as reported by the ESC. As you can see, they tend to jump around, but the trend lines reflect reality (they were generated using a 3rd order polynomial). These are no-Load response times. I plan to do this same analysis with a 1.5 pound weight on the motor (to simulate it being attached to a 3 pound battle-bot).
Acceleration Response Times:
Deceleration Response Times:
Jim Kazmer