Currently it's not possible to get RPM data in regular non-brushless mode. I'll try to have a go at it myself, so hopefully I'll be able to close my own ticket ;)

Hi Benjamin,

While implementing re-synchronization of the protocol in case of CRC errors, we see that stop byte is recognized as start byte during re-synchronization.

Following that, if len in try_decode_packet is very large (because of an erroneous byte) - it will put a large value in bytes_left, and packet_process_byte will not call it until that many bytes have been read. If no further bytes are sent for a while, the pending messages will remain, unread, in the buffer. When bytes_left bytes are finally read, the old messages will be parsed and sent off for handling.

So this causes problematically large delays. I'll try to sketch an alternative protocol that mitigates this.

This is the current protocol:
[1B start byte] [1/2/4B length][xB payload][2B CRC][1B stop byte]

Lets say we do this:
[1B start byte] [1/2/4B length][1/2B header CRC][xB payload][2B CRC]

we drop the stop byte, and instead add CRC (can be either 8 or 16 bit) of the header only (start byte+length). For some backward compatibility, start bytes can be different for those messages, lets say 5,6 and 7. For this format, validity of the length can be checked before awaiting additional bytes to arrive.

What do you think ?

P.S. If I would be designing this, I would add an extra start byte and use 16bit CRC, but your approach seem to be more stingy with message length than mine :)

Starting in 17f9776, when this firmware is configured for hard 4.12, the board simply reboots on bootup in a loop.

While investigating what "cycles running" means, I found that mcpwm has a "cycles_running" variable that is only ever written, but never used. There is now a version in mc_interface....

Here is a patch.
http://prive.bitwizard.nl/cr.patch
"It compiles ship it".. I just deleted the variable, and reversed a test (because the "IF" part of the if-then was removed, the ELSE part now resides in the IF and the test was reversed)..

https://github.com/vedderb/bldc/blob/master/servo.c#L153

Servo pin is on GPIOB, enabled in hw_?.c.

Is this intentional?

I see your hw_75 config file and am excited.
Finally had to ditch the drv for some higher voltage gate drivers I see.

In your phase filter setter (lines 42-42 in hw_75_300.h)
#define PHASE_FILTER_ON() palSetPad(GPIOC, 11)
#define PHASE_FILTER_OFF() palClearPad(GPIOB, 11)
I believe one of them is using the wrong port.

On this note, a cursourly look through and it appears HW_HAS_PHASE_FILTERS is not used. As I am currently 90% of the way through designing my own similar hw derivative (100v max, 250a phase) and now looking at adjusting code / defines. Just curious, what is the hw implementation of your filters? Fets tying capacitors to gnd?

I made a small (big) mistake today. I forgot to hook up the current sense wires on my vesc-software-compatible hardware.

Commanding like 5A of 150A of allowable current caused BANG! an explosion.The evidence suggests that the current increased to the point that one of the mosfets failed (short) and that then the other side started conducting (commanded) and a very large current started flowing. A solid CM of leg-of-the-FET has gone missing....

I'm thinking: Could this have been prevented in software? I think so. At boot, the current sense offset is calibrated by comanding zero current and observing the value of the analog current sense signals. Those should normally end up being say between 40 and 60% of full-scale of the ADC. When things are outside of that range, a fault could be triggered.

(I /have/ had weird hardware where the current sense was centered around 2.5V. (with only 0.8V of travel posible). Waste of ADC range, but sometimes unavoidable. In that case the fault would be triggered erroneously. But in those cases the "normal" range needs to be adjusted. That's all in the game when making odd hardware...)

Hi, sorry to open ticket for my question , actually I intend to made modular ESC in way that controller + gate driver is separated from Mosfets pcb , hence I could increase module ampere by adding parallel Mosfet in the Mosfets pcb, I really appreciated to have your advise or if you know open HW/SW sources let me know

Why does the ESC brake when losing remote reception? That single feature has caused perhaps hundreds of scuffs, face plants and broken bones. Why not coast to a stop?

I understand PPM is taken from remote control cars. It is understandable they'd need to brake when signal is lost. But on a skateboard at 35km/h or 20mph, a sudden brake == potential maiming for life...

We are having some issues when people are getting ABS_OVER_CURRENT error and current values in fault report are not even close to the Absolute Current Limit. I think it has to do with fact that current reading is happening in a separate thread and after the fault was set it was already read new current value and so error report has wrong values.

that's why I would like to propose duplicating motor state variable and sending it with fault code to the method mc_interface_fault_stop:

It would be awesome to be able to switch the "primary" direction of the motor without having to rewire the motor connection (and re-detect its sensors in case of the sensorful operation). Can you advise me on the required code modifications? I'm afraid to burn the motor and VESC MOSFETs or do lots of extra work (even mcpwm.c looks quite complex, and it seems like I need modify much more than set_next_comm_step()).

Steps to reproduce this error:

1. run BLDC tool, select "realtime data" tab, check "activate sampling"
2. send some kind of "high duty" command to the motor (e.g. duty 0.5, rpm 4000, current 3.0A, etc.)
3. then press "brake" / "full brake" button (or send duty 0.0)
4. now move motor shaft by hand
5. repeat from point 2)

You may notice after repeating this several times, some of them tachometer don't change with manual shaft movement, it remains "frozen" until you quit brake state.

Hi @vedderb,

Setting up the Wand (nice work by the way !), the neutral position of the thumb wheel leads to -2,3% on the Nunchuk app.
I see no way to fine tune it to 0%.

Would be an center offset interesting to add as a parameter or do you have a calibration routine in the Wand for correcting this drift ?

Thanks a lot !
Best Regards,

Clément

It would be convenient if the git tag feature would be used to tag the changesets for each of the released versions. That makes it a little easier to grab the source for a specific version.

I see most of the source code has GPLv3 in the headers, but nothing about overall license is mentioned in the readme.

Could you ensure that all files in the project comply with one license and add a notice about the overall license to the readme?

New in FW3.50 - motor overheats during encoder detection. Works fine on the same setup in FW3.40.

Data shows very small current (less than 5%) but large duty cycle (~50%)

Hello @vedderb,

I observe that you've implemented support for some CAN bus protocol. Have you ever considered to support UAVCAN in this project? You can learn more here: http://uavcan.org.

Here's some information about PX4ESC - UAVCAN-powered, open source ESC:

• https://pixhawk.org/modules/px4esc
• https://github.com/PX4/px4esc

It would be beneficial for your project to stick to the standard that is already supported (or soon to be supported) by other vendors.

Hi @vedderb (and others),

If I understood your post from #63 well, changing configuration with COMM_SET_MCCONF_TEMP shouldn't stop the motor (unless I set the store flag) - see exact quote at the bottom.

In reality, however, it does. It seems like the problem is in commands_process_packet() (https://github.com/vedderb/bldc/blob/master/commands.c#L790), where mc_interface_set_configuration() function is called that stops PWM via mcpwm_foc_set_configuration() (the same way of action as for any other change in configuration). The question is, is it a bug or a feature? Can I safely remove this call and just update the values on-the-go? Won't it interfere with how the motor is driven?

Best regards
Jakub

Your original post (for reference):

The good news with this update is that other new commands are coming to enable profile support, namely COMM_SET_MCCONF_TEMP and COMM_SET_MCCONF_TEMP_SETUP, where a short configuration with only current, power, erpm (or m/s) and duty limits can be sent. The setup command allows using m/s and can also be applied to all VESCs on the CAN-bus if a flag is set. These commands also have a flag to specify whether they should be applied temporarily until the next reboot, or permanently. The temporary version can be applied without stopping the motor, which can be useful for some applications.

Apologies if this is not the right place for this, but I would like to add support for Sine-Cosine encoders such as the KMZ60 to the VESC. (Files for my encoder are here.)

From what I can gather from a quick examination, I should add a new encoder type to encoder.c, give it its own init function, and return a float angle on encoder_read_deg(). Seems easy enough.

Where do I patch this in to the configuration UI? I've built that too. I suppose that's a different project however...

Anyway, I didn't see a good place to discuss this so perhaps this can serve as a discussion board.

I will be happy testing on my own, but feel free to advise if anyone is interested.

This is more of a question than a request.

I'm aware that commercial VESC board have a fixed current sensor gain because the sensor is integrated on-board, but here at powerdesigns our current sensors are external, attached to busbars and there are many options to choose from, sometimes you are forced to choose different sensors due to stock issues.

Now we have 2 paths to move forward:

1. Expose current sense gain as an user-configurable field within the Advanced tab. Downside is that in most controllers it presents the user a field that is not meant to be modified.
2. Under /build_all/ provide powerdesigns firmware with all our supported sensors. This means each commit with new firmwares will be several MB worth of binaries, which I hope can be avoided.

Or maybe use option 1, and configure tight limits on all the hardware versions, something like:

#define HW_LIM_CURRENT_SENSE_GAIN 19.98, 20.02

That way user's will only be able to tweak current sense gain +/- 1%

Should I go ahead and try making this change?
Thanks!

Hello,
I have flashed two vesc six with the servoout.bin image but no pwm signal is present on
the servo pin. In the event that the image included in the vesc_tool is wrong I have compiled my own binary with SERVO_OUT_ENABLE 1 and HW_VERSION 60 in conf_general.h but with no success.
Servo is set to "simple"

Hi Benjamin,

Since FW3.40, COMM_GET_VALUES full packet became 64 bytes long.
That breaks the compatibility with Arduino since the default buffer is 64 (SERIAL_RX_BUFFER_SIZE) and can store only 63 bytes (Ringbuffer).

A lot of projects use Arduino and without tweak it keeps them away from VESC-Project now.

Could we arrange to stay under the 63 bytes limit ?
Maybe by adding a specific command (COMM_GET_VALUES_SHORT) ?

Thank you for you support.

Best regards,

Clément

Hi,

Hardware is new VESC75/300 R2.
Software is Vesc-Tool 1.16, just updated the ESC to Firmware 3.58 (at first connection).

Motor Settings are set up by the wizard (FOC), as well as the App Settings (PPM-Remote).
Everything works like it should.

After that when I switch to to PPM-Tab, (only) change the Positive Ramping Time, Write App Config and Read it again I can see that the changes were written to the ESC (also can read them after power cycle and reconnect, they were definitely written to the ESC).
Still no matter which Control Mode I use (tried: Current no Reverse, Duty Cycle no Reverse and PID Speed Control no Reverse), when I push the trigger to max, the motor goes instantly to max RPM no matter if Positive Ramping Time was set to 0.1s or 100s (tried some values in between as well, no change in response).

Am I doing anything wrong, or is this feature not working (anymore)?

Best,
Chris

I have a suspicion that #63 is still a problem, but it's on the sending side, not the receiver - dumping out the raw bytes using an interrupt (so no buffers fill up on my side) the last 3 bytes are missing.

Assuming something in the firmware is limited to a ~ 64 byte buffer, this might indicate some internal corruption could be taking place too?

I recommend that COMM_GET_VALUES excludes some of the "less necessary" values (ie. set the default mask to something less than 0xFFFFFFFF ), so that the total packet length, including start+len and crc+end is 64 bytes or less. If anyone wants all the values, they can make 2 different calls to COMM_GET_VALUES_SELECTIVE

Alternatively - finding where big packets are getting corrupted might be useful - that's probably going to cause other problems elsewhere too.

My baud rate is 250000, not 115200, in case that's a clue/hint?

Hi Benjamin,

In this loop 1 (https://github.com/vedderb/bldc/blob/master/mcpwm_foc.c#L881) and this loop 2 (https://github.com/vedderb/bldc/blob/master/mcpwm_foc.c#L884)
the increment "i" is the same !!!

Afterwards in the loop 1 there is a condition on "i" (https://github.com/vedderb/bldc/blob/master/mcpwm_foc.c#L902)
It seems logic it corresponds to the "i" of the loop 1 but as it is after the loop 2 is finished I think the condition takes the loop 2 "i" (float) value.

Is this an error ?

I am using VESC-MINI4 on Ubuntu16.04 and vesc-tool.
My VESC-MINI4 works well at firmware 3.40.
Today, I updated my VESC-MINI4 to firmware 3.61.I set parameters and write to rom with vesc-tool, but all parameters reset after DC power off.
This problem happens with firmware 3.60 and 3.61 and 3.62, but won't happen with firmware 3.40.
Do you have a good idea?

I'm wondering how realistic it might be to add some code to VESC for basic fuel gauge estimation. It already accumulates Ah and Wh spent while in operation, so I think the missing pieces would be:

• Persisting the information through power-cycles, in some kind of flash-based circular buffer.
• Configurable logic to reset the state for when the battery is found to be full or empty based on voltage extremes.
• Using one of the ADC inputs to monitor the charge lines. This would require a bit of extra wiring so that the uC would be powered up when the charger was connected, but doing this extra wiring would still be easier and cheaper than integrating a separate gas gauge circuit.

The current functionality is pretty good if you always charge to full and do your own book-keeping as far as remembering how much you've used if you use your system multiple times on a single charge. However, it would be great to have the final pieces in place for this.

Thoughts on feasibility?

Upon a fault trip, it would be beneficial if the list of faults is stored in the flash memory for later inspection. This will allow for more accurate debugging of issues happening in the field.

Care must be taken to avoid corruptions in cases of extreme EMI or supply voltage sag, common under a fault condition.

I requested only 1 piece of data - the Vesc ID.
I get back this result (in base 10 bytes)

2 10 50 0 2 0 0 0 0 1 151 110 199 147 3

Those are:

2 = packet type
10 = number of bytes (correct)
50 = my request COMM_GET_VALUES_SELECTIVE (correct)
0 2 0 0 = the 32bit mask for what is being returned (just one single bit is set)
0 0 1 151 = spurious unknown data
110 = my vesc ID (correct)
199 147 = checksum
3 = terminator

The above breaks my CRC checking (because of the unexpected bytes).
If I ask for whatever that spurious thing is (set more bit masks), all is fine again, since it's getting and expecting that data.

My guess is that something in the compiler of the VESC firmware is choking on the bit-shifting of those masks inside commands.c

In DC mode, calculations relative to motor current are not consistent versus switching frequency

Here are 3 results when ordering 40amp current for different switching frequency values
Note that the value of the motor current is wrong in the 3 cases ...

m_dc_f_sw = 20kHz

m_dc_f_sw = 10kHz

m_dc_f_sw = 5kHz

Most automotive applications use Interior Permanent Magnet motors.

These motors have a permanent-magnet inside the rotor that generates magnetic saliency. This saliency
produces a reluctance torque from the difference between the direct-d axis inductance and the quadrature q-axis inductance. The maximum efficiency of the IPM motors can be achieved by proper selection of the current vector ratio between magnetic torque current and reluctance torque current in the total current.
Hence, a basic FOC control on an IPM machine could be losing as much as 30% of the available torque.

This control scheme is known as Maximum Torque Per Amp (MTPA)

And here is some implementation detail with control examples.
http://www.ti.com/lit/an/spracf3/spracf3.pdf

This is a placeholder so we don't forget to implement this feature. Benjamin, feel free to assign this issue to me or to powerdesigns organization.

reproduction:
choose PPM, enable safe start, duty cycle (for easier test on bench)
set the min pulse width and max pulse width a little bit so that the servo signal exceeds it
now exceed the 'max pulse width' by going full throttle, and then slowly release the throttle.

The signal stays full throttle, until returned to 'neutral' central position.

The workaround is to always make sure the servo never exceeds the min/max pulse width.
When disabling the 'safe start' this issue doesn't happen.

Shouldn't be sizeof(mc_configuration) (instead of app_configuration) in this line?

Eeprom read and write is working nice, although.

In nrf_driver.c the function nrf_driver_send_buffer will send a MOTE_PACKET_FILL_RX_BUFFER_LONG packet even when the data size is smaller than 255 bytes.

To show this in practice here is the output from my logging on the receiving side:

Sending request for mc_values.
Packet received, FILL_RX_BUFFER, position: 0, packet length: 25
Packet received, FILL_RX_BUFFER, position: 23, packet length: 25
Packet received, FILL_RX_BUFFER, position: 46, packet length: 12
Packet received, FILL_RX_BUFFER_LONG, position: 46, packet length: 13
Packet received, PROCESS_RX_BUFFER, buffer length: 56, packet length: 5

Thank you for all the hard work, your ESC is brilliant. If you don't have time to fix this please let me know and I will prepare a pull request.

It would be really great if the VESC firmware included an option for trajectory/position control, beyond the single rotation currently supported. At the ODrive they recently implemented a trajectory planner, and it would be really nice if VESC's supported this too. Maybe having the source code available also makes it easier to implement.

Would also be great if the position control could accept commands on encoder counts, same as the Odrive.

What do you guys think? Would it be possible to implement this features in the VESC FW?

The total range that can be read is 0 to 3.3 V.
But with a bidirectinal amplifier, I think the actual range should be half of that. How do you think?
If you think so, The macros below are likely to have to be modified this way.

#define FAC_CURRENT ((V_REG / 4095.0) / (CURRENT_SHUNT_RES * CURRENT_AMP_GAIN))

-->
#define FAC_CURRENT (((V_REG / 4095.0) / (CURRENT_SHUNT_RES * CURRENT_AMP_GAIN)) * 2)

So I'm not expecting a solution for this, it's more a warning to others who might try the same thing as I did:

If you disable optimizations (-O0) in the makefile so you can debug via GDB/OpenOCD, and have the firmware set to BLDC mode (or configure it for BLDC mode via the GUI), then the device will hang during intialization and no longer communicate with VESC Tool, effectively bricking it.

The only way to recover the firmware is by re-flashing firmware via STLink (which you'd presumably have if you were trying to debug anyway).

Eg. I changed the following in the Makefile to -O0 :

# Compiler options here.
ifeq ($(USE_OPT),)
  USE_OPT = -O2 -ggdb -fomit-frame-pointer -falign-functions=16 -std=gnu99 -D_GNU_SOURCE

And then uploaded the firmware via OpenOCD and attached GDB to debug it.

I found that the firmware was hanging at this line:

mcpwm_init(...) {
  ...
  utils_sys_unlock_cnt();

Which I determined was because this suddenly allows ISRs to execute, and mcpwm_adc_inj_int_handler() was running for too long too often and starving the main system task, preventing it from executing anything else.

Unfortunately this also blocks communications with the host, resulting in a brick because you cannot configure the device.

If you did want to fix this, I'd suggest finding a way to automatically detect that ISRs are starving the main thread and disable them, then put the device into a fallback mode that just has communications enabled.

The easier solution of course is to not disable optimizations 🙂

I face a strange behavior with status messages over canbus, selecting all 5 messages and frequency from app config I read over can only few and random status packet even setting high frequency, messages will increase as controller duty cycle increase, even if set point comes from canbus or from app command, at duty >80% i read on the bus all 5 messages but they stop if duty is set to 0.

As far as I understand #63 there should be some way to set the minimum and maximum wattage over the CAN bus interface

The good news with this update is that other new commands are coming to enable profile support, namely COMM_SET_MCCONF_TEMP and COMM_SET_MCCONF_TEMP_SETUP, where a short configuration with only current, power, erpm (or m/s) and duty limits can be sent. The setup command allows using m/s and can also be applied to all VESCs on the CAN-bus if a flag is set.

However, I am unable to find this functionality in comm_can.c. Am I missing something or is this functionality not implemented?
If that is the case, can we add
CAN_PACKET_CONF_POWER_LIMITS
CAN_PACKET_CONF_STORE_POWER_LIMITS
to the CAN bus interface?

I would be willing to try to put a pull request for this together if needed.

Also, are there any plans to extend the UAVCAN interface so it provides the same functionality as the "normal" CAN interface?

Hi there!

I am sorry for posting this in the firmware section. But I found no better way. We are building a force feedback controller as a demonstrator for a UX design agency in Berlin. When researching for suitable controllers, I found this project and I am really convinced of the quality and performance! I would like to use the hardware and software.

Questions:

• anyone happen to have 4 spare boards that we could buy? (timeline too tight to make them ourselves)
• is there an offical distributor for the board? (if not, I might help to find one)
• anyone interested to help us to set up the controller, the firmware and the communication between two controllers? This could be a freelancer job paid by the hour.

Looking forward to hearing from you. Please contact me on [email protected] or +49 30 9190 5511

Kind regards,
Felix

In the hw_setup_adc_channels(), ADC_Channel_3 is being configured twice, in lines 131 and 133. The comment says, 'ADC3 regular channels 2, 3, 12, 3'.

Is it correct, or should it be channels 2, 3, 12 and 13?

I think you need this patch for eeprom emulation in flash to properly transfer a page:

--- a/conf_general.c
+++ b/conf_general.c
@@ -42,7 +42,7 @@ void conf_general_init(void) {
    memset(VirtAddVarTab, 0, sizeof(VirtAddVarTab));

    int ind = 0;
-   for (unsigned int i = 0;i < (sizeof(app_configuration) / 2);i++) {
+   for (unsigned int i = 0;i < (sizeof(mc_configuration) / 2);i++) {
        VirtAddVarTab[ind++] = EEPROM_BASE_MCCONF + i;
    }

Also you should ensure that NB_OF_VAR has at least the size of:
((sizeof(mc_configuration)+1)/2 + (sizeof(app_configuration)+1)/2)

Hi vedderb, thank for sharing this good project.
with the pwm function, can you give some advice on how to change the pwm frequency without stopping the timer ?

Hello,
I am testing of github master bldc on 4.0 hardware. It seems that there is positive offset of about 400mA on both phase currents (resulting in ~ -800mA offset in third phase). When running small ~1A motor, this is major problem on startup.

Is this expected behavior? I'll look into it further, but maybe someone solved it before ..

Well, this is not strictly bldc but chibios issue. The makefile rt.mk contains this line that don't work in Windows:

ifeq ($(USE_SMART_BUILD),yes)
CHCONF := $(strip $(shell cat chconf.h | egrep -e "define"))

That forces to disable USE_SMART_BUILD in order to compile under Windows.

We need to provide firmware support for Field Weakening, which allows a motor to spin beyond its base speed at full power.

An implementation example:

Deep FW operation is not efficient in small BLDC motors, but for IPM motors (issue #73) it is mandatory to go beyond base speed for full utilization of the machine, even if power drops a bit due to Id current losses.

Note this feature is not safe for most hardware implementations because it requires the powerstage to be able to withstand high motor BEMF voltages and some special fault management has to take place.

curr_samp_volt = (1 << 0) || (1 << 1); // = 1 (true), not 3
curr_samp_volt = (1 << 0) | (1 << 1); // Fix

is this an error? maybe i read it wrong but i think the lo_max_rpm variable does not have any effect since it will always be overritten by that statement:

https://github.com/vedderb/bldc/blob/master/mc_interface.c#L1390

Hi,
I am trying to build with IAR embedded bench. Got struck with header file not found
Fatal Error[Pe1696]: cannot open source file "nil.h" .

Searched whole directory no where it is there, please help me
Santosh

Injecting signals into the control loop will help developing new algorithms and improve the coverage and test automation of the code on every commit.

• Being able to simulate a motor within vesc firmware allows developers and researchers to start from a known motor model and evaluate new algorithms by injecting current and voltages into the control loop.
  This is an example of an IPM motor model that could be used to approach issue #26
  http://cpp.sh/33vcz

• Light VESC users could easily simulate a motor by launching injection from the command line to learn to operate VESC_tool

• Most importantly, signal injection makes it possible to perform Processor-in-the-Loop testing, executing the code in the actual target and exercising all critical functions for a broader and automated code coverage test, including fault cases as well as normal operating conditions.