# Firmware 5.03

189 posts / 0 new
benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487
Firmware 5.03

Firmware 5.03 is under development, and this thread is for beta testers. This firmware has some major changes in the FOC code which can significantly improve low-speed performance and fix some old problems (such as when the motor starts "screaming"). Due to the amount of changes there are most likely some regressions, so I would appreciate some testing and feedback. Here is a link to the beta build:

http://home.vedder.se/tmp2/vesc_tool_test_2022-01-12.zip

The release is now done!

VESC Tool also has a major new feature, which is a scripting page. I will make a video about that, but it you want to start testing it now there are some example scripts included that show how it can be used.

Firmware changelog:

• Fixed inductance measurement bug.
• Speed tracker windup protection.
• Phase filter support.
• Phase voltage offset calibration.
• Better current offset calibration.
• Synchronize observer state when running in open loop.
• Force oberver state magnitude above 50% of flux linkage. This prevents the motor from getting stuck and 'screaming'.
• Observer global convergence update. Helps tracking the motor through 0 speed.
• Added HFI start sensor mode.
• Major UAVCAN update. See: https://github.com/vedderb/bldc/pull/269
• Avoid numerical instability when mapping is done over a narrow range. See: https://github.com/vedderb/bldc/issues/262
• Added servo_out_enable appconf option, so that the PPM port can be used to control servos with the default firmware.

• Better current controller windup protection.

• Field weakening support (experimental, be careful and use at your own risk).

• Limit hall sensor angle rate of change based on ERPM.

• Low pass filter input voltage.

• Dual hardware CAN-scan fix.

• Use fast speed tracker for current controller.

• Disable motor for 5 seconds after flash operations.

• Added process derivative term to position controller.

• Added position PID-controller angle offset.

• Configurable PID controller rate.

• Added several AUX port modes.

• Added configurable safe start modes.

• Added constant torque PAS mode.

• Correct scaling for resistance and inductance.

• Fixed inductance measurement bug with f_sw > 30k.

• Corrected inductance measurement algorithm.

• Fixed max power loss calculation.

• Better input current estimation.

• Added raw sampled data mode.

• Compensate inductance for motor saliency in observer.

• Added MTPA mode based on measured current.

• Faster overvoltage protection.

VESC Tool Changelog:

• Fixed simultaneous CAN FW upload when other devices (such as BMS) are on the CAN-bus.
• Fixed configuration backup and restore over CAN-bus.
• Syntax highlighting (needs some work).
• Recent files.
• Example files.
• Auto-completion tree (needs some work).
• Run in widget, window or full screen.
• Debug print output.
• Toggle line comment.
• Auto-indentation of line or block.
• Search, highlight and replace text.
• Only capture esc key for stopping the motor when connected.
• Fixed FOC detect all no can when connected over CAN.
• Added FOC wizard, setup data and profiles from mobile UI to desktop UI.
• Added usage page to FOC wizard.
• Dark theme.
• Mobile UI refactoring.
• Configurable data polling rates.
• Better DPI scaling.
• Configurable plot line thickness.
• Mobile:
• New CAN forwarding bar.
• Setting to disable screen rotation.
• New RT Data page and gauges.

Some tips for testing the phase filters:

• Make sure that all offsets are calibrated with the voltage you are using. This can be done on Motor Settings -> FOC -> Offsets. Make sure to calibrate the offsets before running detection.
• For motors with temperature sensors, make sure that temperature compensation is activated and that base temperature is set to what the motor had when detection was done. The compensation and base temp is found under Motor Settings -> FOC -> Sensorless. This should be done automatically when using the FOC-wizards.
• The phase filters can be enabled and disabled for comparing their impact.

shaman
Offline
Last seen: 1 month 3 weeks ago
Joined: 2018-12-09 15:59
Posts: 60

This is great to see the continued progress and improvement of the VESC project!

Is there some data/info on exactly how the phase voltage filter is improving motor control? What is the expected impact of using them? Do the phase voltage filters need to have a certain RC constant in order for it to properly function with the firmware? Do some types of motors, say low-inductance, benefit more than others? Would hardware with low-side current sensing still benefit from having these phase voltage sensors?

Are there any details anywhere on what A.S.S. is doing from a technical standpoint? I know I can dissect the code and figure it out eventually. Just asking for convenience sake.

okashira
Offline
Last seen: 8 months 3 weeks ago
Joined: 2018-03-07 03:16
Posts: 6

Is the switchable phase/current measurement filters used for HFI / "ASS"?

Or only detection? (ie, are the filters needed to be dynamically disabled for HFI / "ASS" operation?)

I ansered my question - current filters are disabled for HFI (but seems like you keep voltage filter on ;)

tipsy
Offline
Last seen: 5 months 2 weeks ago
Joined: 2019-10-18 18:14
Posts: 2

That vesctool version refuses to install on android 11.

Is the issue on my end?

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

I just tried the APK, it should work. If you have VESC Tool installed from the play store you probably have to uninstall it first to use the apk.

In a nutshell, the phase filters help tracking the motor at lower speed.

As the motor speed decreases, the magnitude of the back emf gets lower and lower. At some point it will be so low that noise, offsets and parameter errors will become so significant that the back emf no longer can be tracked. One of the issues at low BEMF levels is dead-time distortion. This comes from the fact that the motor phase voltages while the motor is driven are calculated from multiplying the input voltage with the modulation of each phase. The problem with that is that there is a short period between when the high-side FET and the low-side FET is on to prevent cross conduction; the so called dead-time. On low modulation the dead time has a significant impact on the voltage estimation, which makes it hard to track a low BEMF. The phase filter help this issue by measuring and low-pass filtering the phase voltages directly, which gives the actual voltage including the dead-time distortion rather than the estimated voltage. Feeding these voltages to the observer helps track the motor at lower speeds.

This sounds simple, but there are a lot of other issues with this approach, such as the introduced phase delay from the filters. As the signal levels get so low other effects also become important, such as the current measurement offsets and the ADC offsets where the phase filter measurements are sampled. Component value tolerances for the filters also get more impact at these low signal levels. The firmware now tries to deal with all of these problems at the same time so that the motor can be tracked at much lower speeds. This also required some updates to the observer.

So far my test results are promising. When all offsets are measured, just the tiniest movement is enough to track the motor, and tracking through 0 speed works really well. The problem is when starting the first time or when staying in 0 for too long, which starts the observer in a state that produces much less torque, which can't turn the motor to get some BEMF for starting to track it. To deal with that I have added a HFI Start "sensor mode" that will start by making a brief HFI pulse when the motor state is unknown, and then start tracking the motor normally. It will also do the same in situations where it otherwise would to to open loop. That seems to work really well on my mountainboard.

For hardware without phase filters, the updated observer and offset calibration updates should also help a bit, and the HFI start mode can be used then too.

Let me know how things work, and if there are any regressions. There are a lot of changes in the code.

Another update from todays release: The FOC-wizard is improved quite a bit. It should set better parameters by default than before when running detection.

NuRxG
Offline
Last seen: 1 week 11 hours ago
Joined: 2018-09-05 09:53
Posts: 17

I tried the latest dev branch (Commit 89c4d712e8ab6ac22c89e0c982d6b4426f8483ea, Mar 13 2020) and its performing pretty poorly on my setup. Running a 16" hub motor from a Solowheel Original EUC with a Cheap FOCer v2 ESC.

Startup performs similar to sensorless at startup maybe even a little worse, even tho I'm using sensors, and its very rough sounding and noisy all the way up until near max RPM. As a sanity check i tried 2 different ESCs and it was no different, however swapping back to the master branch made it run smooth as butter.

Not sure what all info/logs i can provide to help.

*EDIT* Just tried the same motor with a stormcore 100s ESC and it seems to work fine, so its something to do with the Cheap FOCer v2.

P.S. I really love this new wizard stuff, much cleaner and easier to use. Also the work of having to implement everything twice was very demotivational.

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

Thanks for giving it s try!

I just tried it on the old VESC 6 without phase filters, as well as on the unity and the stormcore 100D both sensorless and with hall sensors. Works fine as far as I can tell.

Are you sure that you had the firmware from that commit? It should say BETA 11 on firmware status in VESC Tool and not BETA10. The commit earlier the same day and a few commits before that probably had an issue with the hall sensors, which would make the motor sort of go to open loop even when using hall sensors.

Yeah, having the same wizard both in desktop and mobile is nice, and makes development easier. Did you also give the scripting page a try? I have used it a bit for some of my projects here, it is really useful. Soon I want to make it so that external hardware can upload a compressed QML-file to VESC Tool after connecting and provide a custom interface page. This is useful for LED-boards, loggers etc. to give them a custom interface without making the code go into the VESC Tool code base. Developing these QML-files is nice with the scripting page as they will have access to the same things. Changing and testing things is also super fast this way.

NuRxG
Offline
Last seen: 1 week 11 hours ago
Joined: 2018-09-05 09:53
Posts: 17

Ok, i double checked everything, the zip file in the first post is giving me BETA 10 for Cheap FOCer2, it has the issue, so i also tried compiling the latest code and got BETA 11 and still have the issue.

*edit* Got another user to try it and they described the exact same issue.

I just looked through the scripting page, and it looks like it can majorly cut my development time when working in QML, I'm for sure going to try it next time I mess with that stuff, which is on my todo list. As far as 3rd party hardware control, my master plan for can accessories was to write a bluetooth app that talks over uart with the esc, and has it can forward whatever I want to my can bus accessory so i could essentially make any can bus accessory bluetooth enabled so long as the esc has bluetooth. I could use that for my Balance Buddy.

Pedrodemio
Offline
Last seen: 10 months 3 days ago
Joined: 2017-08-02 00:38
Posts: 11

Just tried it on a FlipSky 4.20 MINI, after doing the detection, I can't get the motor to spin, it just jerks for both sides. Running sensorless. I know this hardware has pretty poor phase current measumerent a bit of DC current offset on the readings, maybe this i interfering with the new sensorless startup

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

Sounds like there could be problems with some hardware versions. I will see if I can find a 4.12-pcb in my box and try it there.

What offsets did you get on the offset-tab under FOC?

CTSchorsch
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-07-13 09:55
Posts: 101

I like the scripting page :) thanks benjamin !

short test, works fine

NuRxG
Offline
Last seen: 1 week 11 hours ago
Joined: 2018-09-05 09:53
Posts: 17

My offsets are

2056.10
2058.77
2038.57

0.0000 V
0.0000 V
0.0000 V

-0.0006 V
0.0000 V
0.0006 V

I think its fair to say my problem is similar to Pedrodemio's my motor mostly just cogs in both directions unless i crank up the current or give it a push.

CTSchorsch
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-07-13 09:55
Posts: 101

One problem:

i updated from 5.02 to dev_5_03 and started the test version from vesc-tool:

Error: "Could not deserialize motor configuration. You probably need to update the VESC firmware, as a new iteration of the test version has been made."

Now i can not read or write the motor configuration

Georg

EDIT: ah, there is a new version behind the link above :) working now

shaman
Offline
Last seen: 1 month 3 weeks ago
Joined: 2018-12-09 15:59
Posts: 60

I think there are some factors that affect how other hardware handles some of these changes

• low-side current sensing
• slower MOSFET switching rise/fall times
• lack of current/phase filters
• higher voltage operation

A lot of the hardware I've developed matches these things and I've noticed how much they affect smooth control. Ben, are any of these factors known to affect the quality of motor control or ASS?

CTSchorsch
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-07-13 09:55
Posts: 101

Phase filters are not working on my hardware, which is based on the VESC 75/300

Motor detection and running is smooth with disabled phase filter.

With phase filter enabled, motor detection just cogs in both direction

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

I did some testing with an old V4, and it seems to work. Only problem is that it by default uses BLDC, meaning that the offsets don't get sampled when changing mode to FOC. One workaround for now is to switch to FOC, write config, sample offsets and then run detection. I will try to fix this for the next update.

So far it seems to work on all hardware I have tested (2x low side, 3x low side, 3x phase shunts, 2x low side dual, 3x low side dual), with the exception of dual motor hardware with phase filters as I don't have any. Only problem so far was with the v4, but the workaround above works (although it also worked with the default offsets, just not as good).

Something that I don't have access to but that would cause problems for sure is hardware that has phase filters in the hwconf file (#define HW_HAS_PHASE_FILTERS), but has a problem with the implementation. If the hwconf file has no #define HW_HAS_PHASE_FILTERS the the config option is vesc tool should have no effect.

Another thing that will impact the performance is if the offsets are sampled with an input voltage that is significantly different from the voltage that is used with the motor.

@CTSchorsch

Can you show me what your phase filter implementation looks like and which hwconf file you are using?

CTSchorsch
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-07-13 09:55
Posts: 101

Hi Benjamin,

thanks. First, without phase filters the new detection runs much better than in older versions.

the phase filters are the same as in your design, just change the analog switch to one which is available on jlc

my hwconf/hw_gesc.h

/*

This file is part of the VESC firmware.

The VESC firmware is free software: you can redistribute it and/or modify
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

The VESC firmware is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

#ifndef HW_GSVESC_H_
#define HW_GSVESC_H_

#define HW_NAME					"GESC"

// HW properties
#define HW_HAS_3_SHUNTS
#define HW_HAS_PHASE_SHUNTS
#define HW_HAS_PHASE_FILTERS
#define INVERTED_SHUNT_POLARITY
#define HW_HAS_NO_CAN
#define HW_HAS_RFM95W

// Macros
#define LED_GREEN_GPIO			GPIOB
#define LED_GREEN_PIN			0
#define LED_RED_GPIO			GPIOB
#define LED_RED_PIN				1

#define PHASE_FILTER_GPIO		GPIOC
#define PHASE_FILTER_PIN		9

#define AUX_GPIO				GPIOC
#define AUX_PIN					12

/*
*
* 0  (1):	IN0		SENS1
* 1  (2):	IN1		SENS2
* 2  (3):	IN2		SENS3
* 3  (1):	IN10	CURR1
* 4  (2):	IN11	CURR2
* 5  (3):	IN12	CURR3
* 8  (3):	IN3		TEMP_MOS
* 9  (1):	IN14	TEMP_MOTOR
* 10 (2):	IN15
* 11 (3):	IN13	AN_IN
* 12 (1):	Vrefint
*/

// Component parameters (can be overridden)
#ifndef V_REG
#define V_REG					3.3
#endif
#ifndef VIN_R1
#define VIN_R1					56000.0
#endif
#ifndef VIN_R2
#define VIN_R2					2700.0
#endif
#ifndef CURRENT_AMP_GAIN
#define CURRENT_AMP_GAIN		20.0
#endif
#ifndef CURRENT_SHUNT_RES
#define CURRENT_SHUNT_RES		0.001
#endif

// Input voltage
#define GET_INPUT_VOLTAGE()		((V_REG / 4095.0) * (float)ADC_Value[ADC_IND_VIN_SENS] * ((VIN_R1 + VIN_R2) / VIN_R2))

// NTC Termistors
#define NTC_VALUE_MOTOR         10000.0
#define NTC_RES_MOTOR(adc_val)	(NTC_VALUE_MOTOR / ((4095.0 / (float)adc_val) - 1.0)) // Motor temp sensor on low side
#define NTC_TEMP_MOTOR(beta)	(1.0 / ((logf(NTC_RES_MOTOR(ADC_Value[ADC_IND_TEMP_MOTOR]) / NTC_VALUE_MOTOR) / beta) + (1.0 / 298.15)) - 273.15)

// Double samples in beginning and end for positive current measurement.
// Useful when the shunt sense traces have noise that causes offset.
#ifndef CURR1_DOUBLE_SAMPLE
#define CURR1_DOUBLE_SAMPLE		0
#endif
#ifndef CURR2_DOUBLE_SAMPLE
#define CURR2_DOUBLE_SAMPLE		0
#endif
#ifndef CURR3_DOUBLE_SAMPLE
#define CURR3_DOUBLE_SAMPLE		0
#endif

// UART Peripheral
#define HW_UART_DEV				SD3
#define HW_UART_GPIO_AF			GPIO_AF_USART3
#define HW_UART_TX_PORT			GPIOB
#define HW_UART_TX_PIN			10
#define HW_UART_RX_PORT			GPIOB
#define HW_UART_RX_PIN			11

#define HW_UART_P_BAUD			115200
#define HW_UART_P_DEV			SD4
#define HW_UART_P_GPIO_AF		GPIO_AF_UART4
#define HW_UART_P_TX_PORT		GPIOC
#define HW_UART_P_TX_PIN		10
#define HW_UART_P_RX_PORT		GPIOC
#define HW_UART_P_RX_PIN		11

// ICU Peripheral for servo decoding
#define HW_USE_SERVO_TIM4
#define HW_ICU_TIMER			TIM4
#define HW_ICU_TIM_CLK_EN()		RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM4, ENABLE)
#define HW_ICU_DEV				ICUD4
#define HW_ICU_CHANNEL			ICU_CHANNEL_2
#define HW_ICU_GPIO_AF			GPIO_AF_TIM4
#define HW_ICU_GPIO				GPIOB
#define HW_ICU_PIN				7

// I2C Peripheral
#define HW_USE_I2CD1
#define HW_I2C_DEV				I2CD1
#define HW_I2C_GPIO_AF			GPIO_AF_I2C1
#define HW_I2C_SCL_PORT			GPIOB
#define HW_I2C_SCL_PIN			8
#define HW_I2C_SDA_PORT			GPIOB
#define HW_I2C_SDA_PIN			9

// Hall/encoder pins
#define HW_HALL_ENC_GPIO1		GPIOC
#define HW_HALL_ENC_PIN1		6
#define HW_HALL_ENC_GPIO2		GPIOC
#define HW_HALL_ENC_PIN2		7
#define HW_HALL_ENC_GPIO3		GPIOC
#define HW_HALL_ENC_PIN3		8
#define HW_ENC_TIM				TIM3
#define HW_ENC_TIM_AF			GPIO_AF_TIM3
#define HW_ENC_TIM_CLK_EN()		RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM3, ENABLE)
#define HW_ENC_EXTI_PORTSRC		EXTI_PortSourceGPIOC
#define HW_ENC_EXTI_PINSRC		EXTI_PinSource8
#define HW_ENC_EXTI_CH			EXTI9_5_IRQn
#define HW_ENC_EXTI_LINE		EXTI_Line8
#define HW_ENC_EXTI_ISR_VEC		EXTI9_5_IRQHandler
#define HW_ENC_TIM_ISR_CH		TIM3_IRQn
#define HW_ENC_TIM_ISR_VEC		TIM3_IRQHandler

#define HW_HALL_TRIGGER_GPIO            GPIOC
#define HW_HALL_TRIGGER_PIN             13
#define HW_HALL_ROTARY_A_GPIO           GPIOC
#define HW_HALL_ROTARY_A_PIN            14
#define HW_HALL_ROTARY_B_GPIO           GPIOC
#define HW_HALL_ROTARY_B_PIN            15
#define HW_HALL_ROTARY_A_EXTI_PORTSRC   EXTI_PortSourceGPIOC
#define HW_HALL_ROTARY_A_EXTI_PINSRC    EXTI_PinSource14
#define HW_HALL_ROTARY_A_EXTI_CH        EXTI15_10_IRQn
#define HW_HALL_ROTARY_A_EXTI_LINE      EXTI_Line14
#define HW_HALL_ROTARY_A_EXTI_ISR_VEC   EXTI15_10_IRQHandler

// SPI pins
#define HW_SPI_DEV				SPID1
#define HW_SPI_GPIO_AF			GPIO_AF_SPI1
#define HW_SPI_PORT_NSS			GPIOA
#define HW_SPI_PIN_NSS			4
#define HW_SPI_PORT_SCK			GPIOA
#define HW_SPI_PIN_SCK			5
#define HW_SPI_PORT_MOSI		GPIOA
#define HW_SPI_PIN_MOSI			7
#define HW_SPI_PORT_MISO		GPIOA
#define HW_SPI_PIN_MISO			6

#ifdef HW_HAS_RFM95W
#define HW_RFM95W_SPI_DEV				SPID1
#define HW_RFM95W_SPI_GPIO_AF			GPIO_AF_SPI1
#define HW_RFM95W_SPI_PORT_NSS			GPIOA
#define HW_RFM95W_SPI_PIN_NSS			4
#define HW_RFM95W_SPI_PORT_SCK			GPIOA
#define HW_RFM95W_SPI_PIN_SCK			5
#define HW_RFM95W_SPI_PORT_MOSI		    GPIOA
#define HW_RFM95W_SPI_PIN_MOSI			7
#define HW_RFM95W_SPI_PORT_MISO		    GPIOA
#define HW_RFM95W_SPI_PIN_MISO			6
#define HW_RFM95W_SPI_PORT_DIO0         GPIOC
#define HW_RFM95W_SPI_PIN_DIO0          5
#define HW_RFM95W_SPI_PORT_RESET        GPIOB
#define HW_RFM95W_SPI_PIN_RESET         2
#endif

// Measurement macros

// Macros

// Override dead time. See the stm32f4 reference manual for calculating this value.

// Default setting overrides
#ifndef MCCONF_L_MIN_VOLTAGE
#define MCCONF_L_MIN_VOLTAGE			12.0		// Minimum input voltage
#endif
#ifndef MCCONF_L_MAX_VOLTAGE
#define MCCONF_L_MAX_VOLTAGE			50.0	// Maximum input voltage
#endif
#ifndef MCCONF_DEFAULT_MOTOR_TYPE
#define MCCONF_DEFAULT_MOTOR_TYPE		MOTOR_TYPE_FOC
#endif
#ifndef MCCONF_FOC_F_SW
#define MCCONF_FOC_F_SW					30000.0
#endif
#ifndef MCCONF_L_MAX_ABS_CURRENT
#define MCCONF_L_MAX_ABS_CURRENT		120.0	// The maximum absolute current above which a fault is generated
#endif
#ifndef MCCONF_FOC_SAMPLE_V0_V7
#define MCCONF_FOC_SAMPLE_V0_V7			false	// Run control loop in both v0 and v7 (requires phase shunts)
#endif
#ifndef MCCONF_L_IN_CURRENT_MAX
#define MCCONF_L_IN_CURRENT_MAX			60.0	// Input current limit in Amperes (Upper)
#endif
#ifndef MCCONF_L_IN_CURRENT_MIN
#define MCCONF_L_IN_CURRENT_MIN			-60.0	// Input current limit in Amperes (Lower)
#endif

// Setting limits
#define HW_LIM_CURRENT			-120.0, 120.0
#define HW_LIM_CURRENT_IN		-120.0, 120.0
#define HW_LIM_CURRENT_ABS		0.0, 160.0
#define HW_LIM_VIN				12.0, 50.0
#define HW_LIM_ERPM				-200e3, 200e3
#define HW_LIM_DUTY_MIN			0.0, 0.1
#define HW_LIM_DUTY_MAX			0.0, 0.99
#define HW_LIM_TEMP_FET			-40.0, 110.0

// HW-specific functions
int gsvesc_get_angle(void);

#endif /* HW_GSVESC_H_ */

Maybe it is a problem with bad board design. I moved the switch near to the adc inputs, to have the capacitor as near as possible to the adc input. because i have a round design, the filter input voltage path is very long

Thanks

Georg

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

I don't think the layout is so sensitive that it would completely stop working. Having it near the ADC-pin is good too.

Can you make sure that the filter actually is connected to GPIOC 9 and that the pin is configured as an output in the source file for your hardware?

CTSchorsch
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-07-13 09:55
Posts: 101

yes, just checked again: schematic has GPIOC connected and inside my hw_gesc.c i use the default code

// Phase filters
PAL_MODE_OUTPUT_PUSHPULL |
PAL_STM32_OSPEED_HIGHEST);
PHASE_FILTER_OFF();

is the "PHASE_FILTER_OFF()" still correct ?

TechAUmNu
Offline
Last seen: 1 day 16 hours ago
Joined: 2017-09-22 01:27
Posts: 574

All working good on my A200S V3, which has 2x low side shunts and current + phase filters.

One thing I did a bit differently to your designs is my extra filter cap is connected to an open drain IO on the stm32. So I don't need the analogue switches. The pin is either floating or ground.

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

That seems correct. Can you plot the voltage signal while the motor is driven in the sampled plot?

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

I just made an update, seems to work better with the V4 now. The offset calibration is also updated so that the parts that don't need the motor to stand still are calibrated on every boot by default.

tipsy
Offline
Last seen: 5 months 2 weeks ago
Joined: 2019-10-18 18:14
Posts: 2

FOC wizard sets my battery cutoff start/end at 6v, despite selecting 10s on all of the 5.03 test versions.

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

You are right, I messed that up in the new wizard. Building a version now where that is fixed.

Edit: Done!

NuRxG
Offline
Last seen: 1 week 11 hours ago
Joined: 2018-09-05 09:53
Posts: 17

Tried the latest but it's still not working for me on the Cheap FOCer V2.

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

I checked a few things in the config, but I'm not sure where to start debugging the problem as I can't reproduce it. If someone can send me a unit that doesn't work I can have a look. You can also show me exactly how you are making the test, what the sampled and real-time data looks like etc. The more details the better.

CTSchorsch
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-07-13 09:55
Posts: 101

Hey Benamin,

here are two pictures of sampled data, triggerd with motor start.

the motor is configured with parameters from the wizzard without phase filters. sometimes the motor starts spinning after 2 or 3 seconds

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

Looks like not much is happening after 40 ms. Does it get a fault code? Does exactly the same test work with the old firmware? What are the current and voltage offsets?

CTSchorsch
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-07-13 09:55
Posts: 101

the same test (try 10% duty cycle) works fine with the same firmware, but disabled phase filtes in the FOC filters tab.

this is with disabled phase filters:

Offsets:

with enabled phase filters the pictures looks like in the post above and the motor does this:

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

Uploaded another version now that seems to work better on the cheap FOCer 2

CTSchorsch
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-07-13 09:55
Posts: 101

Still not running here, but its more or less a problem on my individual hardware :)

Detection ist not running. Either with HW_HAS_PHASE_SHUNT or without. in addtion the saved config is now not working when phase filters are disabeld...

NuRxG
Offline
Last seen: 1 week 11 hours ago
Joined: 2018-09-05 09:53
Posts: 17

I'm noticing on the latest builds that the balance app is struggling with the sleep function going longer than requested (1khz Balance, 1khz IMU). I think this problem has been creeping up for a while, as awesome features are constantly being added. But it seems like we might be hitting the limits of the CPU, tho tbh I'm not entirely sure how to measure CPU load or what the best way to go about reducing it is.

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

You can write threads in the terminal and see how much time is spent in the idle thread compared to the others, that is an indication on how many CPU resources are left for threads. This does not include the long motor control interrupt directly, but if little time is spent in the idle thread it means that CPU resources are running low. The CPU usage from the motor control interrupt is directly proportional to the switching frequency and the number of motors. For single motor hardware with f_sw at 30 kHz, more than 50% of the CPU resources should be unused.

When using the sleep function it does not include the time the thread itself takes to run, and if there is an interrupt in the middle that won't be included either. That means that the rate of the thread will always be a bit too low, and there will be some jitter on that. One way to improve that is sleeping based on absolutes times. Something like this should work:

systime_t time = chVTGetSystemTime();

for(;;) {

chThdSleepUntilWindowed(time, time + MS2ST(1));
time += MS2ST(1);
}

yoodog
Offline
Last seen: 6 months 2 weeks ago
Joined: 2021-03-30 00:20
Posts: 5

guys, I want to build an external alarm based on IMU+ESP32 (more complex than that but to keep it short we leave it for now)

- Idea is to add "Alarm mode" on VESC, which would execute those steps up on ADC3 line going from 0v to 1.5v with VESC powerd on:
1. put VESC to some sort of lowest power consumption mode
= VESC ready to act if alarm is triggered

- than if ADC3 goes to high (3.3v - alarm triggered):
1. wake up controller
2. Engage breaking to full power (ideally would be if there would be seperate paramter Alarm Breaking Force, so that it can be set higher than typical riding breaking / regen force)
3. go out of Alarm mode once voltage goes down to 0v on ADC3

That would be amazing option in my opinion specially for bicycles and e-scooter at very least!
________________________
if you are interrested in Alarm side it would function someething like that:
1. Arm 1.5v / Disarm 0v output (by phone APP or RFID tag readerr or what ever you want)
2. MPU650 triggered alarm would set output to 3.3v to VESC ADC3, send 3.3v to the FET to open up main battery power to the Siren, Send notification via Blync app over 3G shield (gps shield would also send GPS data over Blync app wher one could track)
3. reset gyro/accelerometer home position every second and go back from triggered to Armed after 30sec without motion detection (output down to 1.5v, siren outout off)

____________

In theory basic alarm function could be implemented completely insidee VESC
- since it has Gyro/Accel on board
- has BT connection (so lock / unlock could be added to the phone App)
- Only not sure what connection could be used to trigger Siren activation (could ADC to be mapped as output - to send trigger for the fet to open up the gate for battery voltage to the siren?)

NuRxG
Offline
Last seen: 1 week 11 hours ago
Joined: 2018-09-05 09:53
Posts: 17

This is my results from the threads command. Which are pretty encouraging. Idle thread is at 61.2% so there should be plenty time for the balance app to run. I will try to implement sleeps they way you recommended and report back. However the time of the BMI160 thread really stands out at 30%, it actually starts off low 1% and then steadily increases over time, Ive seen it up to abut 40%. I tested the lsm6ds3 and it does the same thing. I don't understand whats going on there.

addr stack prio refs state name motor time
-------------------------------------------------------------------
20001bd8 20000f54 64 1 SLEEPING main 1 189 (0.0 %)
20001c28 20001d34 1 1 READY idle 1 801432 (61.2 %)
2000d580 2000da6c 64 1 SLEEPING mcif timer 1 16265 (1.2 %)
2000d1e0 2000d494 63 1 WTOREVT SampleSender 1 0 (0.0 %)
2000cb58 2000cdfc 124 1 WTOREVT Fault Stop 1 0 (0.0 %)
2000e3a8 2000e84c 64 1 SLEEPING foc timer 1 1939 (0.1 %)
2000db28 2000dfd4 64 1 SLEEPING foc hfi 1 719 (0.1 %)
20008a40 2000901c 64 1 CURRENT comm_block 1 360 (0.0 %)
20001f80 200020ec 126 1 SUSPENDED usb_lld_pump 1 3400 (0.3 %)
200050f0 200052bc 64 1 QUEUED USB read 1 2096 (0.2 %)
20003f58 20005074 64 1 WTOREVT USB process 1 17810 (1.4 %)
20018a90 2001930c 64 1 SLEEPING UAVCAN 1 7 (0.0 %)
2000aeb0 2000b15c 65 1 WTOREVT CAN read 1 0 (0.0 %)
2000b248 2000b4dc 64 1 QUEUED CAN status 1 253 (0.0 %)
20009d18 2000adc4 64 1 WTOREVT CAN process 1 0 (0.0 %)
20014408 200154dc 64 1 READY uartcomm proc 1 2546 (0.2 %)
20002cf0 200031d4 64 1 SLEEPING Main periodic 1 239 (0.0 %)
20002a58 20002c54 2 1 READY Flash check 1 2346 (0.2 %)
20009960 20009c3c 64 1 SLEEPING Timeout 1 196 (0.0 %)
20019918 2001a0f4 64 1 READY BMI Sampling 1 412671 (31.5 %)
20016648 20016f14 64 1 SLEEPING APP_BALANCE 1 17571 (1.3 %)

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

The reason that the IMU-thread takes so much is that I2C runs in software, and uses a busy-wait loop for the bit timing (using a hardware timer, so the speed is not that load dependent). This means that it will spend as much time in that thread as the communication takes. This adds up when sampling the IMU at a high rate as you do for balancing. The 30 - 40% will probably not increase much as the rest of the system load increases, because the busy-wait loop uses a timer to not sleep longer than needed. It will increase and decrease with the IMU sample rate though. I don't know why it starts at such a low value, maybe because it takes some time before the IMU-thread is started during which the idle thread will run and increase its total percentage (the load value is based on time spent in each thread since system start compared to total time, meaning that it is an average since boot).

district9prawn
Offline
Last seen: 2 months 3 weeks ago
Joined: 2018-04-26 12:18
Posts: 124

Hello,

I gave the new field weakening a go just now. Hardware used was a200s v2 and a 6374. Only tested on the bench at low speed and power with current mode. It worked well and the gradual ramp down of d axis current kept the winding voltages in check during braking or sudden release of throttle as expected. Nice work!

Offline
Last seen: 3 days 4 hours ago
Joined: 2020-09-07 15:09
Posts: 19

I just tried beta21 on a Cheap FOCer2 based Funwheel with Fungineers hub and 12s2p battery. When reusing my existing settings (still worked fine in beta17) I now get a clunk noise when balancing at low speeds. I didn't dare go on an actual ride. Is it unreasonable to expect that old configurations should continue to work? Is there any particular setting I should go adjust or do I need to go through the full calibration process again?

NuRxG
Offline
Last seen: 1 week 11 hours ago
Joined: 2018-09-05 09:53
Posts: 17

I just built the latest dev branch also on a cfoc2 and ran a fresh calibration and noticed current spikes, here is a graph. The black is motor current, and the red is what the balance app is setting the current to. You can see around the 0 point there are large black spikes while the red is flat. (Some of the black spikes also have red spikes, i think these are reactionary to jitters/cogs getting the IMU out of whack?)

Previous betas didn't have spikes like this. Here is a graph from beta 19, its harder to get any spikes, but if i do get some spikes they're much smaller.

*I should point out, it took effort to capture the small spike on beta 19, where as the curren't code i just grabbed a random sample, not even the worst of it.

**Edit: My same setup randomly worked fine on a more recent test, so i guess there is some intermittency to this issue.

Offline
Last seen: 3 days 4 hours ago
Joined: 2020-09-07 15:09
Posts: 19

I was able to confirm that beta20 also works fine for me. The problem appears to get introduce either by "Merge pull request #282 from powerdesigns/ipm_bemf_decoupling " or by "Merge pull request #283 from powerdesigns/speed_pid_loop_antiwindup " or by both - I can't quite pinpoint it (I tried commit by commit, I installed about 15 versions of the firmware today).

In addition to the clunky noise when balancing near zero speed, I also get such noise after I get off the board and the board is not moving, after about 30 seconds (I have brake current = 7A configured)

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

I think I know what the problem could be. When the set current is around 0 the motor will alter between being driven and undriven. Before that was done in sync with the current command, but now it is done using a timer as field weakening has to be taken into account. Can you try to making sure that the output of the PID-controller always is greater than cc_min_current?

It is probably best to keep the motor driven even at 0 current in an application like that without having to introduce a discontinuity around 0. I can add some command for that in the next update.

Offline
Last seen: 3 days 4 hours ago
Joined: 2020-09-07 15:09
Posts: 19

> Can you try to making sure that the output of the PID-controller always is greater than cc_min_current?

Any suggestion as to how I can best accomplish that?

Offline
Last seen: 3 days 4 hours ago
Joined: 2020-09-07 15:09
Posts: 19

I can confirm that the balance app calls "set_current" with values < cc_min_current all the time when riding, regardless of speed - whenever the board is "balanced" the output current can go down to 0 I guess...

Offline
Last seen: 3 days 4 hours ago
Joined: 2020-09-07 15:09
Posts: 19

I just tried forcing the set_current value to always be >= cc_min_current (I have a beeper alerting me whenever that happens, which is very frequently on a balance vehicle) but that made no difference unfortunately...

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

I just added mcpwm_foc_set_current_off_delay() so that you can delay switching off the modulation for 0 current. Can you try to use it just before setting the balance current?

Offline
Last seen: 3 days 4 hours ago
Joined: 2020-09-07 15:09
Posts: 19

Let me see if I understand. According to your commit the delay defaults to 1s, right? How many seconds should I set it to? The balance app sets the current 1000 times a second, do you really want me to call this function each time?

Or did you mean to say "before setting the brake current?" so when starting to idle?

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

There is no default value, you have to set a delay. As long as it is longer than your control loop cycle time it is fine (e.g. 0.1s). The function is not heavy, so you call it in every iteration.

TechAUmNu
Offline
Last seen: 1 day 16 hours ago
Joined: 2017-09-22 01:27
Posts: 574

Today I was playing around with settings and clicked write config while the motor was running a few times by accident. It caused the motor to almost instantly stop from 40% duty, after doing this a few times it blew one of the low side mosfets. I thought it was supposed to turn off the modulation when motor settings are changed so this doesn't happen?

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

That is probably because the modulation is not stopped instantly anymore in case field weakening is active, and writing to flash stops the CPU entirely. I will make a workaround in the next days.

Offline
Last seen: 3 days 4 hours ago
Joined: 2020-09-07 15:09
Posts: 19

Here some more observations. I did add the call as you suggested, but didn't really notice an improvement. Still quite clunky when rocking back and forth and minimum speed. I also discovered that the weird noises when resting only occur during a firmware upload (which is slow via bluetooth). When I had the board on the ground it started making small movements on its own during the firmware upload process. What's odd though, is that when using a fresh motor configuration by running the newest wizard, I don't get the noises and self movement during firmware updates anymore, but I still get the occasional loud "clunk" when going back and forth at low speed... Sorry if I'm not making things clearer...

I could attach  a diff between my 5.2 motor config and the new (better) motor config I got out of the wizard in 5.3 beta 21 if you'd like.

benjamin
Offline
Last seen: 1 week 2 days ago
Joined: 2016-12-26 15:20
Posts: 487

Firmware uploads while the motor is running is a bad idea, as every time flash is written the CPU is completely halted. I'm surprised that it works at all. I will see if I can lock mc_interface properly during firmware updates.