If we are agreed the STM32 is the first MCU to go after then I think we may need to start in there.
Is there a way to force _SOFTWARE_6PWM to be selected when we choose BrakingBLDCMotor? From what I can see this would be the way to individually control the 6 FETs? Then we would need to implement the individual control as currently everything is always in pairs.
A suggestion is to overload the writeDutyCycle6PWM to accept 6 duty cycles instead of 3. We can raise an error if we are configured as _HARDWARE_6PWM. Else we can control each pin individually.
You get software 6-PWM automatically by choosing the right pins
Choose pins attached to TIM1 or TIM8 but donāt use any negated outputs. When Iām back at my laptop Iāll do a quick check which those would be on the Nucleo 446RE.
I will get to work on the API for setting the FETs later today, if I can.
I think we will want to make an API that ensures users canāt create shoot-through, or there will be a lot of burnt hardware
So I donāt like the idea of just allowing individual control over all 6 FETs
I wanted to go back to the video I watched which show cased the various control methods SimpleFOC can offer.
I mentioned above that the pure FOC algorithm in voltage mode in essence would provide us with a level of regeneration. This is because we would essentially be able to reverse the direction of the motor to give a braking torque. I also shared a report that showed how this would provide regeneration.
Going further on this I have looked again at the torque control code and I donāt see why this wouldnāt be working exactly the same (just provide a negative torque request). @runger is this not right?
This means we can (in theory) seamlessly move from driving the motor, into coasting, into regenerative braking and through into plugging.
Obviously we will still need to implement monitoring of the bus voltage and methods for protecting the power supply, but I do think the capability may already be there.
Someone please correct me in case I am going mad. I really need the parts to arrive!!!
So you can use PA8, PA9, PA10, PA11, which are all on TIM1, as well as PC6, PC7, PC8, PC9, which are all on TIM3 (and TIM8). I suspect the code will select TIM3, but it should not matter.
Make sure the high and low sides of a half-bridge are always controlled by the same timer.
Problem will be that you can only do 2 phases on the same timer, and the third phase will have to be on a different timer. Unfortunately the code does not align the timers well at the moment.
This means that low-side current sensing wonāt work well at the moment.
So I guess aligning the timers is another todo. This is somewhat tricky to do on STM32, but should be possible.
I checked it on STM32CubeIDE, and TIM1 and TIM8 have 6 channels on STM32G4, but channels 5 & 6 arenāt connected to output pins. STM32F446 only supports 4 channels per timer, all with outputs.
So it looks like we wonāt get around properly aligning the timers if we want this functionality.
Another thing to check is making it work with hardware 6-PWM modeā¦ again, this is probably possible, but tricky to do.
Iām afraid I have to defer this question to someone more knowledgable in the motor physics.
My understanding is that coasting is essentially disconnecting the power (closing all the FETs) and letting the motor rotate freely until it stops, while braking actively stops the motorās motion by using the magnets to oppose the motion.
In this sense we support active braking in all our modes, as the current algorithm will always try to track the target you set. So by setting the target to 0 or in a direction opposite to the motorās movement, you will actively brake the motor by using battery energy to oppose it.
You can test this quite easily by setting the target value to 0 in velocity or position mode, and then trying to move it by hand. Youāll feel the motor working against you.
But I donāt think that is actually regeneration.
Fair enough.
I am just thinking that based on the two papers I have shared, regeneration can be achieved with various methods. One of which is with FOC and negative iqā¦ I believe this is possible.
Again coastingā¦ what are you afterā¦ in my view you are trying to feel no motor input as if there was no motor. To do this you match the BEMF.
Trouble is, I am also not a motor physics expertā¦ I am an IC powertrain engineer
Hi everyone interested in the regenerative braking topic!
Some progress on this:
I have implemented a first version of the code that allows control of the FETs in the ways discussed.
Iāve implemented it into the API, and into the hardware drivers for STM32 and RP2040 so far. Other MCU types will gradually follow once we confirm it works as expected.
Note that on STM32 this works with Software 6-PWM, and not with HW 6-PWM. So you have to avoid using the negated PWM channels.
On RP2040 there is only SW 6-PWM and it works with this.
You can find the branch containing these changes here:
Usage instructions to follow once I have a chance to put together a test setup and actually try it outā¦ but in the meantime anyone interested could take a look, give feedback, and perhaps even test it out with their setups.
The same implementation on the PWM side will also enable us to do Hi-Z mode in block commutation, enabling BEMF voltage measurements on the phases. This in turn opens the door to āsensorlessā commutation based on BEMF readings.
So thatās another avenue to explore at some point
And in further good news, my driver board from AliExpress āhas arrived in my country or regionā Lets see how long it now takes to get to me!
I joined just to say that VESC, which is an open source speed controller, has regenerative braking implemented.
It doesnāt require additional special hardware at all, although phase voltage sensing is standard on their hardware for sensorless operation.
There are several open hardware board designs available as well, with gerbers and what not.
Important to note that regenerative braking works at any speed, from maximum nominal (motor kV * Vbus) down to near zero rpm. The maximum negative current can be controlled and also limited.
VESC is indeed a very cool project, and I agree that anyone interested in BLDC driver design should take a look at their schematics, which are generously provided under a CC license.
In terms of the hardware, it also seems very high quality, but I think is on the expensive side for many of our users. The somewhat dubious clones of the older versions you can find on AliExpress are a bit cheaper, and I believe there has even been some success by our users in getting SimpleFOC to run on VESC hardware (search these forums for VESC).
In terms of the software, the VESC code is very well structured and clear, but very STM32 specific and optimised, and therefore not so easy to understand, at least without getting more deeply into it, and quite a bit of background knowledge about the MCU. So while it is great that It is provided open source on GitHub, I think it may be a bit complex for many of our members who are new to the world of motor control or embedded development.
SimpleFOC has a different approach - weāre try to make motor control accessible (and less expensive) by providing an Arduino library that runs on many MCU types, and a āsimpleā code base. Weāre not really a finished product, like VESC, and so weāre perhaps not the best choice for some users and some applications. But other users are looking for something that isnāt so finished, and they can integrate into their projects in a flexible way. And by being based on Arduino framework, weāre very accessible to newer users also.
That said, regeneration and braking are things weāre looking into, and taking a look at the VESC code, among others, will be a good source of information. But weāll certainly develop our own version, and gradually extend it to the different MCU types we support. The work has already begun
I fully agree that the codebase is specific for stm32, being actually tailored for the F4 series specifically.
I also agree that the code is not very user friendly, as itās the result of years and years of implementations and PRs.
I just threw it on the table as ODrive was as well.
Both are designed around the same MCU, albeit VESC is still open source.
I am a VESC user, so maybe biased.
However for the topic in hand, regenerative braking, the theory is the same regardless of MCU. And I appreciate the efforts to develop it on SimpleFOC.
Regarding hardware, it can be designed cheap depending on the application.
I just received 5 assembled PCBs designed following the same principles of VESC 4 (low side shunts on 2 phases with op-amps, voltage sense on all phases, Vbus sensing, temperature sensing) but compatible with ESP32 and meant to be used with SimpleFOC (hence why Iām here ), for gymbal motors up to 2A. It cost me 10 euro each, but could be made cheaper in quantity.
Board is to be used with single cell li-ion and has charge/discharge protection, on a 50mm diameter 4 layer PCB.
I know phase sensing is still not implemented on SimpleFOC, but I had spare ADCs
Iām not so sure about that. The concept is the same. The theory and implementations are as different as there are people doing it. Ask two people and you will get four different answers.
Regen on a gimbal is it a thing? How much can you recover? I understand regen on a 100A/10kW high power systems where you realize some savings (10 to 20% best real-world use case scenarios). What use case you got in mind where a single li-ion battery on a 1A slow-moving gimbal motor regen would be applicable?
The stars is that I have implemented the needed functionality of setting the phase state individually per FET for the high and low side, and Iāve done it for RP2040, STM32, and Renesas MCUs, and another user has kindly implemented it for ESP32 MCUs.
This is one of the basic building blocks needed.
Another one is voltage sensing for the VBUS, presumably in combination with current sensing. So far I think only ESP32 or RP2040 MCUs would allow the combination of both, the other MCU types wonāt let you do voltage sensing if SimpleFOC is using the ADC for current sensing.
So the next step is to implement more general ADC APIs to allow to use the ADC also for other needs as well as current sensing.
As actually implementing Regenerative braking is very hardware dependent, we will probably provide some code examples on top of the PWM and ADC functionality, and leave it there.
I assumed ADC sampling other than current sampling also works on STM32F1 because you used injected adc ?
After I am done with current sensing on gd32 I thought I would check if analogread is still working with regular channels, so I am worried now
Hi,
assuming we talk about regen-braking with a LiPo battery, we would need a classic CC-CV scheme.
But only if we find a way to boost the generator voltage above no_load voltage of the battery with the motor-driver hardware.
In other cases, we would need a separate buck-boost-converter, which will handle current- and voltage limit on itās own.
The usecase Iām interested in will need a dump-load and a motor brake if the battery is full or the wind is to strong.
" Phase advance/Field weakening can help operate the motor at higher than rated speed, but it also consumes a lot more current as itās less efficient, and can trigger the overvoltage protection of your BMS when braking.
"
Reading between the lines, it sounds like negative torque vector (used for braking) and phase advance can lead to the boost-voltage we are looking for?
IDK how it could be controlled, just wanted to mentionā¦
Lets see how long it now takes to get to me!
And by being based on Arduino framework, weāre very accessible to newer users also.
