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.
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
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.
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?