Syncronizing 2 R/C airplane motors

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello everyone,

I want to brainstorm about synchronizing two BLDC motors intended for R/C airplanes (although I am not using them for R/C). The controllers would presumably use the PWM protocol that servos use.

I am thinking that I would designate one of the motors as the 'master' and sync the other to it. I would also need some way to count RPM.

I am wondering if there is an easy way to sense one of the motor phases turning on and off to get RPM. Or am I'm better off with an optical or hall sensor looking at the rotor.

It seems straightforward to vary the speed of the motors using the servo-type PWM, though I wonder if it gives enough control.

The application involves using the motors with offset weights for vibration. They need to counter-rotate to cancel torque effects and obviously if they are not synchronized, the vibration will be weird.

As I write this, I am looking at how many timers I would need. I want to use an ATtiny26 or ATtiny261. The 261 has input capture whereas the 26 does not. I am not familiar enough to know the real advantage of this, but I suspect wanting two PWM outputs and two RPM timers may require the input capture.

Thoughts...?

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd suggest that using gears would be much simpler. Not only do you need to match rpm but also angle.
I'm not sure what amount of 'slip' ( electrical vs mechanical angle) bldcs use and this may vary with load. Since your load is eccentric, the load changes by angle. Encoders might be necessary. Gearing on the other hand is simple!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As with any problem, there is an all hw or all sw or half and half solution. Since its a brushless dc motor, every phase is driven by a computer. Just tell both computers to go 10000 rpm and they will be synced. By definition.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I want to use an ATtiny26 or ATtiny261.

You could do that.

But it might be better to start with a larger uC, like a Mega168.

When you have a working system then decide if you can port it to a smaller micro, and if it is worth the effort to do so.

It is often incredibly more effective and efficient to start with a larger than anticipated need micro and move downwards in size once the project works, than it is to get stuck with a memory or peripheral module limited micro and move up.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This might use a software phase-locked loop. The master would be the "reference" input to the phase detector. Even better, a phase/frequency detector. The slave would be the equivalent to the VCO in the PLL.

You would modulate the master RPM and the slave would simply track.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can certainly tap off of one of the motor leads to get an RPM reading; but, as Kartman says, it will give you frequency synchronization but not angle synchronization. Just attach a voltage divider in addition to a filter capacitor ( and, potentially, a schmitt trigger ) to create a digital signal at the right levels.

BLDC startup is typically open-loop and, as such, it is unlikely that angular synchronization will be possible in the absence of some angular measurement of the offset weights.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Run both motors from the same controller.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason you can't sync is that you are dealing with two free wheeling pieces of mechanics that almost never operate the same. It's always been one ESC per BLDC motor and ever more will it remain so.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I'd suggest that using gears would be much simpler.
At this point, gears have been deemed too noisy. :?
bobgardner wrote:
Just tell both computers to go 10000 rpm and they will be synced. By definition.
Yes, that is the ultimate goal. For a prototype, inexpensive off-the-shelf controllers will be used. Access to the micros is difficult. :shock: Speed control is achieved with the PWM of R/C servos.
DocJC wrote:
it might be better to start with a larger uC, like a Mega168.
That just may happen. :wink: Part of my query it to determine if the tiny has enough capability. I am confident it has the smarts, but its peripherals may be inadequate. :cry:
ka7ehk wrote:
This might use a software phase-locked loop. The master would be the "reference" input to the phase detector. Even better, a phase/frequency detector. The slave would be the equivalent to the VCO in the PLL.
I think that is what I'm imagining, but I don't know how to implement....
mckeemj wrote:
BLDC startup is typically open-loop and, as such, it is unlikely that angular synchronization will be possible in the absence of some angular measurement of the offset weights.
OOPS! :shock: I forgot that the phase detection didn't guarantee position.... I'm thinking an opto-interrupter or hall sensor for position once per rev.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You said "speed control is achieved with the pwm of rc servos". If you mean pwm controls the motor speed, this is incorrect. If you mean pwm controls the width of the 1 to 2 ms pulse that the computer measures to calc desired speed, you are correct. A bldc motor is a stepper motor, sequencing the abc phase sequence at a rate calculated on a digital computer counting clock pulses.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
A bldc motor is a stepper motor, sequencing the abc phase sequence at a rate calculated on a digital computer counting clock pulses.
Are you sure? It is my understanding that they are sensorless BLDC motors. The method you suggest would be less efficient and reduce run time. Sensorless BLDC commutate using some kind of inductance sensing. the main challenge is when starting and the controller has no way to sense direction.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I just thought of a way to time each motor.

If I have a once-per-rev sensor on each motor 180* out of phase, I measure the time between motor1 & motor2, then the time from motor2 & motor1. I then adjust the PWM to make the two times equal.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The combination of a single "home-position" sensor on each motor should ( in theory ) be enough as long as some seek time to find the correct "locked" position is possible. If the system must start up in a locked state, it becomes more difficult -- even a handful of position sensors may be insufficient. In that state, some sort of absolute encoder would be preferable. The difficulty then becomes finding one that works up to the 10000RPM.

One of the biggest problems with something like the AtTiny ( many of the AVRs, in fact ) is that it only has a single input capture peripheral. That peripheral can have two inputs ( ICP and Analog Compare ) but they are not both usable at the same time. Synchronizing two motors is going to require, ideally, two inputs -- it would work reasonably well with your 180 degree out-of-phase system if they are close to sync though. The other option, of course, is to use an external interrupt or pin change interrupt to store a free-running timer programmatically. The disadvantage being that the ISR servicing will introduce some jitter to the reading. It may be good enough, however.

Another option is to buy hobby ESCs that are compatible with open-source firmware ( SimonK is one famous one ). The advantage there is that you might be able to simply hack the code and hardware in such a way that the slave reads the "home" signal of the master and changes its speed to try to sync its own "home" signal.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mckeemj wrote:
The combination of a single "home-position" sensor on each motor should ( in theory ) be enough as long as some seek time to find the correct "locked" position is possible.
Yes, thanks for pointing that out. There should be plenty of time in this application.
mckeemj wrote:
use an external interrupt or pin change interrupt to store a free-running timer programmatically. The disadvantage being that the ISR servicing will introduce some jitter to the reading. It may be good enough, however.
I understand. I think it might be. :wink:
mckeemj wrote:
Another option is to buy hobby ESCs that are compatible with open-source firmware ( SimonK is one famous one )
Thanks Martin! I'll look into this. :wink:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I measure the time between motor1 & motor2, then the time from motor2 & motor1.

Why?

If you have a single sensor on each blade, you then know both when that blade passes the "home" position, and the time for each rotation, (giving the RPM).

180* out of phase means that Motor #2's sensor trips its "home" position at Motor #1's rotation time / 2, using Motor #1's home position as the timing reference.

Motor #2 trips too early, you need to slow it down.

Motor #2 trips too late, you need to speed it up.

The delta time from the exact 180* time, divided by the rotation time, x 360 degrees, gives you the phase lead or lag in degrees, if you wanted to display that on an LCD, (with the RPM), during testing.

What RPM is this system going to run at? (I saw Uncle Bob's reference to 10K above.)

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aeroHAWK wrote:
mckeemj wrote:
The disadvantage being that the ISR servicing will introduce some jitter to the reading. It may be good enough, however.
I understand. I think it might be. :wink:
If it isn't there are a few techniques for eliminating jitter.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Quote:
I measure the time between motor1 & motor2, then the time from motor2 & motor1.
Why?
It accomplishes the same thing but it is simpler. With a single input capture in the ATtiny, this method doesn't require two of them.
DocJC wrote:
What RPM is this system going to run at? (I saw Uncle Bob's reference to 10K above.)
Bob's number was a hypothetical... the target is less than 5000.
joeymorin wrote:
there are a few techniques for eliminating jitter.
Thanks JJ. I'll cross that bridge....

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Noise? Synchronous timing belts.
Bldcs are similar to stepping motors albeit with large steps. And slip. Magic happens if i mention it a third time.
Ten minutes on Gate's web app and you'll have the required part numbers.

Otherwise you're building dc servo motors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Noise? Synchronous timing belts.
Belts are tricky to get counter-rotation. :wink:
Kartman wrote:

Bldcs are similar to stepping motors albeit with large steps.
I am very familiar with motors. I spent the first two years of Compumotor's existence designing and dyno testing stepper motors. The last decade I participated in developing motors for a brushless motor company.
Kartman wrote:
And slip.
This is a topic that will take far more than is available here. :wink: (I don't consider your comment accurate)
Kartman wrote:
Magic happens if i mention it a third time.
You lost me on this one.... :?

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Basically your only option is belt at this point. One thing is the same speed but you need them to be exactly the same position also. At all times. ALWAYS. Otherwise when accelerating/decelerating everything goes haywire and out of sync and you just self destruct your thingamabob.

all you need is a cross belt and a way you go.
http://content.myodesie.com/imag...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I assume you are familiar with www.rcgroups.com ? There's probably been more said there about dual motor, single ESC than you could read in a lifetime - but I would make a start by reading the popular threads about this.

Back in the day the aim to use a single ESC was driven by cost when an ESC was $100+ but you can buy a handful of ESC for that price now. Another concern might be weight and I suppose that remains the one reason for trying to do this?

I guess it would be possible to simply have one CPU implementing two ESC but each would still have their own MOSFETs and ABC wires.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this for a twin engined RC plane ? I often thought about that... There exists a similar scheme for I/C engines.... My thoughts were:-
Drive motor 1 using std servo/pwm from the Rx.
Detect speed difference between motor 1 & 2 with AVR.
Drive servo 2 from AVR to match motor 1....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How much speed diff is detectable? How much is allowed? How many speed steps does the transmitter and receiver use? 256? 512?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

similar scheme for I/C engines....

yeah but the servo in I/C control does not try to get feed back from the engine/prop to see how fast it is going. In a brushless DC motor the ESC is handling the commutation so needs feedback all the time as to where the stator is:

The ESC isn't just driving the outer coils in this but is reading back generated voltage from non-energized coils to work out how far round the thing has moved.

The diagram here is greatly simplified - real motors use three phase ABCABC.. with two out of three energised at any time and back EMF read from the third.

When two differently spinning motors (because of mechanical friction differences, prop wind resistance and so on mean that even if you had two motors and energised both in the same pattern their stators may not rotate to exactly the same position.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bloody-orc wrote:
Basically your only option is belt at this point.
WOW! my ONLY option! :shock: That seems pretty narrow minded to me. You know the old saying... "there's more than one way to skin a cat".
bloody-orc wrote:
all you need is a cross belt and a way you go.
Been there... done that. It doesn't work! Not for long anyway. The cogs on the belt get nasty with each other and they also make more noise.
clawson wrote:
it would be possible to simply have one CPU implementing two ESC but each would still have their own MOSFETs and ABC wires.
Yes, that is where it will ultimately end up. I'm working on a proof of concept prototype.
chartman wrote:
Is this for a twin engined RC plane?
No, see my original post, paragraph 5. :wink:
bobgardner wrote:
How many speed steps does the transmitter and receiver use? 256? 512?
There is no transmitter involved. This is NOT for R/C. See my first post. I get to pick whatever works. Since this is for offset weights, my guess is that it isn't real critical.
clawson wrote:
The diagram here is greatly simplified - real motors use three phase ABCABC.. with two out of three energised at any time and back EMF read from the third.
Thanks for the GREAT explanation Cliff. I hope this can help with the differences between BLDC and steppers. It also helps for understanding that there is no 'slip'. The phase switching frequency determines the RPM in both BLDC and Steppers. With AC induction motors, the frequency is CLOSE but the motor turns slower than the frequency would determine - therefore... SLIP.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Thanks for the GREAT explanation Cliff.

If you have researched BLDC use in planes at all I assume you've heard the name Ron van Sommeren? That graphic I embedded was simply taken from one of his posts on RcGroups:

http://www.rcgroups.com/forums/s...

If you want to learn about Brushless BLDC then simply read everything on the internet you can find that RvS has ever written - he is the total guru on this stuff!

Unfortunately that post of his is from 2004 (about when I started playing with BLDC motors) and many of the links are now dead. It's a real shame that some of the pictures from gobrushless.com have gone as it used to be a real "hub" for motor builders. I've bought most of the motor kits I've built myself from them but some of their tutorial articles seem to have been lost. Even their forum:

http://forum.gobrushless.com/for...

looks like it died in 2010.

I'm sure a bit of googling will hit some of this stuff - I remember seeing GIF animations at the time (10 years ago) that explained all about the ABCABCABC phasing and so on.

Actually this site looks interesting:

http://scolton.blogspot.de/2011/...
http://scolton.blogspot.de/2012_...
(and many other pages there)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am not sure if you are looking actually 'build' the ESCs or if you are looking to just sync the rotational speed between two ESC/BLDCs setups.

If you are not replacing the ESCs, then adding rotation hall ICs, you can do a delta of the incremental change of the two hall outputs and increased/decrease the PWM freq to the slave while always passing the input PWM (it is your reference) to the master ESC/BLDC motor combo).

PWM speed input -> MCU  --> ESC/BLDC/Hall Sensor ----/
                                 ^   ^  \-> ESC/BLDC/Hall Senor --/  /
                                 |    |-------------------------/  /
                                 |-----------------------------/                                             

In terms of replacing the ESC with a unified unit to control two BLDCs, using SVPWM and creating 2 sets of 3 PWM 'sin' waves is fairly straight forward. Sync'ing the rotational speed by adding two rotational 'hall' effect IC (I mounted the N35h magnets on the 'back side' of the motor's shaft using some 3d printed adapters as I lucky to have enough exposed shaft to do this) solved the problem by using the incremental output of the two ICs to produce a delta. This detail signal was used a phase modulator for the slave motor's SVPWM.

Using this method you can also include the yaw (well, any axis...) from a compass, gyro, or accel. to handle single sided slew (wheel slippage, wind gusts, single side load variation, etc..) as an additional modifier to the sync phase (in serial phase correction, not parallel).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
If you have researched BLDC use in planes at all I assume you've heard the name Ron van Sommeren?
My BLDC experience is with a brushless OEM that makes much larger motors (500 to 8000 watts).
clawson wrote:
If you want to learn about Brushless BLDC then simply read everything on the internet you can find that RvS has ever written - he is the total guru on this stuff!
Thanks for the links. My comments were referencing some comments that seemed to indicate some misinformation about BLDC motors. These references are valuable to clarify that. :wink:
SushiHangover wrote:
If you are not replacing the ESCs, then adding rotation hall ICs, you can do a delta of the incremental change of the two hall outputs and increased/decrease the PWM freq to the slave while always passing the input PWM (it is your reference) to the master ESC/BLDC motor combo).
Yes, exactly my plan. Thanks :wink:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
SushiHangover wrote:
If you are not replacing the ESCs, then adding rotation hall ICs, you can do a delta of the incremental change of the two hall outputs and increased/decrease the PWM freq to the slave while always passing the input PWM (it is your reference) to the master ESC/BLDC motor combo).
Yes, exactly my plan. Thanks Wink

Cool, I used AMS AS5040s and configured them for high speed incremental output (up to ~30k(?) RPM with this IC, ~10k with AS5045, etc...) and only used this output, forget which of the 3 output pins in this mode I used, but assuming it was a LSB one, and this output was a 'frequency' input to the MCU as the PWM and/or SPI outputs from this encoder IC (or any other) are way to slow and thus the sampling speed will cause missed output and you will NEVER get the slave in sync.

The AS5040 and others also have BLDC commutation modes but I never got into these features on those encoders.

BTW: I did this with NXP's LPC4300 mcu as (for me) it was a fast hack as they have a mode call SGPIO (serial gpio) that is controlled by Timer Modules and can provide up to 16(?) PWM output channels with almost CPU impact (zero bit banging here). Using a couple of GPIOs as 'freq' inputs from the rotational encoders, placing those into a comparator function and using that a delta to the input freq for the 3-channel SVPWM (x2) that I was creating, all this on the same mcu produced a really tight sync (+/-2 rpm in 'unchanging' stable load conditions as I was sampling a 96 micro seconds at 7000 rpm or less and the mcu was running at 200Mhz with that leaving over 5k of free clock cycles between samples to do other things...., BUT wild load conditions on the master had to be watched out for, as a complete stall on the master, or a ~2000 rpm delta or greater to the slave, would produce a 'reverse' SVPWM on the slave! Not just three half-bridges braking, but trying to reverse a BLDC, the noise was more frightening then the mosfet melt-downs. Never realized a stator/actuator could 'sing' like that... Neverless to say, I had to code in some error/fault patterns and do an orderly shutdown of the master/slave if needed. Looking back now this all could be done in a CLPD chip just a easy (and cheaper) as they are great for PWM logic circuits.