Quad Copter Progress Log

Recent entries are at the top. Click on the date heading to show / hide an entry, or use the following buttons show all / hide all

October 2013

13rd October 2013

So... I've looked into filtering, and come up with the following sallen-key / low pass / schmitt combination.

This gives a fantastic improvement over the previous filtering - the comparator was previoulsy working with a few-hundred milivolts, whereas now there is a good ~6v signal! Here, blue is the BEMF signal (Vin), yellow is the positive input of the schmitt trigger (V3), and red is the output of the schmitt trigger (Vout).

As you can see, we have a wonderful output with ~50% duty cycle!

I really hope that this works - I'm nervous that the square wave output will change as the motor speeds up and slows down... and that it won't 'lead' the speed to a settling point... There's only one way to find out!

July 2013

21st July 2013

I spent my most recent ½ hour turning the waveform upside down. This should improve things when I move onto a FET driver that doesn't have a charge-pump built in. I ran the ESC again to the same speed as before, capturing the loaded and unloaded traces.



Looking good! Now to filter the coil, and re-create the BEMF commutation!

17th July 2013

I've been thinking about the coil's waveform a lot recently, trying to decide how I might best determine the commutation point. I decided to run the motor up manually adjusting the PWM duty cycle and commutation rate. I ran it once without a load, and again with a load - a large propeller.



Here, the Yellow trace shows the direct (ish) waveform of a coil, while the Green trace shows an average point. As you can see, the traces have an interesting difference - that part of the trace that looks like it's been strung up between two poles!

May 2013

26th May 2013

Despite the lack of updates here, I've not actually completely forgotten about my ESC. Over the last month or two I've been playing with switching schemas, and I also took a look at the waveforms of a 'real' ESC.

The 'real' ESC's waveforms look like the screenshot below. It's interesting to note that the switched coils are pulled low, then high, then left floating. This is in order to re-charge the capacitor allowing the top N-FETs to be saturated correctly.

After seeing this I decided to update my schema. Until this point I had been using my original approach of 'apply PWM to top and bottom FETs'. Changing this to PWM one FET while the other is held high/low has significantly increased the power and efficiency of the ESC. The screenshot below shows my updated schema:

What you actually see here is as follows:

  • Yellow: A coil of the motor
  • Green: The coil's signal, through a gentle low-pass filter (to remove the PWM)
  • Blue: The coil's signal, through a harsher low-pass filter (to provide a 'zero' reference)
  • Digital 1 (PB2): The output of the comparator (based on +ve Green and -ve Yellow inputs)
  • Digital 0 (PD2): This trace is high only during commutation phase 0 (there are 6 phases)
  • Red: The power supply (monitored for noise and droop)
My development setup isn't powered by a battery, but instead a 25 Amp power supply that I've borrowed from a friend, which might explain some of the noise you see.

Based on this image, it should be feasible to base the commutation timing off the output of the comparator (at least that's what I was doing before!).

Unfortunately this doesn't work yet - I think I'm doing something wrong...

March 2013

18th March 2013

I spent some time looking into, and have now managed to fix the time discrepancy between the measured phases and the timed phases. It turns out that I was using the incorrect timer setting ('Phase Correct PWM' vs. 'Normal' - I have no idea why), and this issue has now been almost completely resolved. In actual fact, where previously the timed phases were fairly precisely twice the length of the measured phases, now the timed phases are slightly shorter - perhaps 90%. I have a feeling that there is a latency issue in the interrupts that I need to take into consideration.

This fix has now sorted out the shape of the BEMF waveform, and as a result I have managed to spin the motor up to over 10,000 rpm without a load! With a load (a 12x4.5 prop) I have achieved roughly 4,000 rpm, and the ESC is drawing about 2 A. At this speed there is a considerable amount of air moving in the room - the light is swinging and the curtains are rustling. I even had to remove items from near the propeller as they were starting to get sucked in.

I have to admit there was a considerable amount of adrenaline running through my body... At this speed I wouldn't be surprised if it could break a finger, let alone draw blood. The next thing to worry about is the propeller pulling itself apart due to centripetal force, and getting a bit of it stuck in my flesh / expensive equipment.

16th March 2013

Today, with the borrowed power supply, I have worked towards running the motor faster. Previously this has been and issue - as the PWM duty cycle increased, the speed increased. To a point. At this point, the motor lost a lot of speed, and made a nasty noise. Having done some investigation, I noticed that when I was probing one the low-pass filtered sense lines, the motor ran faster! As soon as I removed the probe the issue returned. Unfortunately, in reality, this problem-speed was just pushed up instead of being resolved, as when I ran the motor even faster the issue returned.

I think that this is caused by the probe's capacitance, so perhaps I need to add a capacitor (creating a low-pass filter on the voltage divider - the point that I was probing).

I also noticed, that as the PWM duty cycle increased, it sounded like the motor was starting to trip up. Then, all of a sudden the motor stopped dead. What does this mean? And why is that happening?!

Before I investigated these points however, I wanted to profile the motor. I've heard that not all brushless motors want to be fed a sine wave. To test this theory, and to see what mine wanted I connected the spindles of two motors, and attached a probe to one of the slave's coils.

While holding the top motor stationary, I ran up the bottom motor. The result of this was pretty much what I expected - a sine wave. Perhaps I should aim to generate a more sinusoidal input to the motor?

In the capture below, the digital trace is for synchronisation and triggering, the yellow trace is one of the phases of the motor, and the pink trace is the output from a coil of the driven motor.

The interesting thing that this shows, is the difference in driving vs. driven frequency. The driving motor is running (electrically speaking) at 476Hz, while the driven motor is running 6.1Hz faster, at 482.1Hz. As the driven motor should be showing precisely what it wants, we can tell that there is some inefficiency in the ESC-BLDCM system. I know that there is a discrepancy between the length of each commutation phase, so perhaps this is caused by that?

15th March 2013

Having blown the regulator the other day, I needed to replace it (and as it turns out the AVR too). I whipped out the hot-air gun, removed the dead bits, and put in their replacements. While I was at it I decided to fix the 'safe' control to the FET driver that has been bothering me for a while - I wouldn't be too surprised if these were related.

The safe pin was previously controlled by a PNP transistor, and a pull down resistor to GND. I'm not sure why I made this decision, I think possibly because less power would be dissipated in the 'run' state than using an NPN transistor. Either way, it was a bad decision in hindsight. One of the reasons that this was a bad plan, is that the 5v rail that the SAFE line should default to doesn't come up with the VIN rail... It's a little way behind. This causes an issue as the FET control lines aren't tied anywhere, and the AVR can't have started up yet (it sits on the 5v rail).

My revised approach uses a NPN transistor and a pull up resistor to VIN. By default the transistor is 'off', and the SAFE line is pulled high. When the AVR has woken up, and decides to start the motor, the transistor turns 'on' and the SAFE line is pulled low. There is a little more power dissipated when the in the 'run' state, though it's worth it for the improvement.

A couple of nice things about this change are that there is no need to change the control logic, and I managed to rework my PCB without any hassle!

13rd March 2013

A friend has lent me a nice bench supply - upto 25A at 13.8v which is a fantastic improvement over the PC supply I was using before. It appears to output more like 14.8 - 15v, but that still falls within my design spec of 16v max. Unfortunately the first time I powered my ESC up, the 5v regulator blew (smoke, a warm glow and everything!). I'm not really sure what went wrong, but that was the end of the evening.

To distract myself from this unfortunate occurrence, I decided to put nice banana plugs on the input and output my ESC - check them out!

3rd March 2013

How is it March already?!

I've spent some more time preparing the PCB for v0.4 of my ESC. The most notable change is that I have added a differential signal transceiver that will hopefully give the communications a better chance in the noisy environment. I've also changed to a 10-pin side mounted connector, and added a large 'can' style capacitor to the regulated 5v domain. ESC v0.3 tried to make do with small 'chip' capacitors, but in hindsight I think that was a bit of a mistake.

February 2013

2nd February 2013

I've just spent some time with a decent scope and have managed to get Back EMF feedback working correctly with v0.3 of my ESC! This really made me happy - it's incredible the difference that having enough channels to see everything makes. Initially I adapted the previous firmware so that it would spin up, get stable, lower the PWM duty cycle to something more appropriate for the motor's speed and then turn on the BEMF feedback. This first video shows the first of the 6 commutation phases being adjusted by the BEMF feedback. It also shows me loading the motor with my fingers (to slow it down) which would previously have caused the motor to stall. In this state the motor is reasonably resilient to stalling, though this resilience will increase when the other commutation phases are also adjusted correctly.

The next step was to implement full BEMF feedback, where all commutation phases are adjusted by the physical speed of the motor. While testing this, I found that it was actually possible to completely stall the motor, give it a little shove, and it would continue without any issue!

Once that was complete, I worked on improving the startup. Until now it has been following my old, proven and disgusting startup profile. The motor is aligned (badly), and is then forced to turn at a set speed. The speed is ramped up, and the PWM duty cycle is tweaked along the way, until it is spinning at a reasonable 'idle' speed. At this point the PWM is adjusted slightly to prevent over or under commutation, and it is given a brief period to settle.

Now, the alignment is a teeny bit better (though it could still use some work) and as soon as the motor is turning fast enough, the BEMF feedback is enabled. Take a look at the result:

January 2013

18th January 2013

December 2012

31st December 2012
1st December 2012

October 2012

22nd October 2012
19th October 2012
18th October 2012
16th October 2012
15th October 2012
14th October 2012
6th October 2012
5th October 2012
1st October 2012

September 2012

27th September 2012
7th September 2012

August 2012

31st August 2012

July 2012

10th July 2012

June 2012

30th June 2012
19th June 2012
10th June 2012
7th June 2012
1st June 2012

May 2012

sometime in May 2012