Closed arturohernandez10 closed 2 years ago
Dear @arturohernandez10,
Thank you for this suggestion and this interesting question. It is the first time someone has asked us about more phases, I think.
I must admit I don't know that much about motors with more than 3 phases. I can imagine a "double-sided" motor with 2 sets of windings, i.e. 6 phases, but really this would just be 3 phases in a different configuration. I would expect the 2x3 phases to be aligned in such a way that it is actually 3 phases from the electrical point of view.
For a 5-phase motor, I find it hard to imagine. I'd have to read up more on this topic. Is it the case that the phases are then not 120° apart in terms of their commutation waveforms, but rather 360°/5 = 72°?
In terms of the library, there are several problems:
So while I think it might be possible, I also think it would be a bigger code change affecting very many parts of the library.
@runger1101001
Luckily for me I am using the TB6612FNG which already has dead time insertion. I don't know how many other drivers have it, but it is certainly candidate for a hardware solution.
Maybe a starting point would be 6 phases, where the windings are superimposed but staggered. To be more clear.
Say we have only 6 poles. And we have one winding for each pole, 1, 2, 3, 4, 5, 6. If we were to connect them for 6 phases the connection would be as follows.
1in - 3out, 3in - 5out, 5in - 1out plus: 2in - 4out, 4in - 6out, 6in - 2out.
Such that windings 1, 3 and 5 are connected between themselves, just like 2, 4 and 6. But not between those two groups. Perhaps the big difference here is that for 6 poles you would have 7 magnets instead of 8.
To drive them we just need 3 more signals overlapped on top of the first 3 offset by 60 degrees. I believe the library does support 2 motors. So I can't imagine how could there be an issue. Not that there isn't one.
Thanks so much, I'll update here once I have a result. Unless you see some other problem that I don't.
If the PWM values for the three new signals can be calculated directly from the values of the original three, then you could get by with hacking the driver. The problem is that unless great care is taken (in a hardware-specific way), the PWM outputs of different timers are not synchronised. And each timer only has a certain number of outputs, depending on the MCU type and model.
Many STM32 MCUs, for example, don't support more than 4 PWM outputs on their timers, some support 6 channels, but not all channels may have pins for PWM. it really depends on the MCU model.
I think RP2040 (Raspberry Pico) would be one MCU where you can do many synchronised PWM outputs. But this MCU only has 3 analog inputs, so not enough if you also wanted to measure the phase currents.
You could ignore the PWM mis-alignment, and just use different timers... not sure that would lead to efficient, quiet results though.
Ok, well, I do have a raspberry pico as well. Initially I am mostly interested in position feedback, so the current measure is not a big issue. And I suspect it would be easier to extrapolate the 3 missing current measures.
The one thing I realized after my previous comment, is that the number of magents suggests that it's not as simple as 2 motors.
Without knowing the details, it seems to me that I would need an extra parameter to the motor that would be used to account for the difference in magnet positions. Maybe motor A and B. Then extrapolate the current feedback of one into the second.
Of course that would need to be done in new call, or some other backward compatible way.
BTW, I got my design almost done in Fusion 360. And ordered all the parts.
I think I will have to somehow pass motor A and motor B for the moment. That could be wrapped into a different API call. Other than the docs on the repo, if you give me some criteria and you would like a contribution. I will gladly apply it.
Regards
After a few more tests (no code). When connected to a power supply, I believe steppers may be a better compromise. And I am willing to use a power cord. When using a battery, extra phases may still be an interesting proposition. This thread may help others for a bit of background, if they would like to attempt the same thing.
Thanks!!
Just wanted to add that my new RP2040 based board would be well suited for multi-phase design, as all six phase legs are laid out the same way (though four have current sensing and two do not). https://github.com/Twisted-Fields/rp2040-motor-controller
Also years ago I designed a brushless linear motor from scratch, and I found using FEMM for simulation that I could get less force ripple if I controlled each of the three phase coils independently (not tying one end of the coils together), so that required six phase drivers to work. But that was ten years ago and I ran in to some electronics design problems. With my new board I want to try this again, so multi-phase would be interesting. But I will prob just implement the drive code from scratch for testing.
As you must know gear/cable/belt reductions are commonplace in robotic arms and legs. I think a real alternative to high reductions, for the diy roboticist. Is to make a motor instead of a reduction.
The motor I have in mind is a slotless or air core motor. With about 80 mm radius, 5 phases, 20 or 25 poles on the stator. With a offset halbach array on both sides.
Between the air core and added phases there is less ripple and cogging. Which is important for a direct drive or smaller reduction.
The question I have is, how difficult would it be to add more phases to this library?
Overlapping 3 more phases, by treating the motor as two. May be possible without library changes.