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
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 ssaturated 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)
- Yellow: 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)
Based on this image, it should be feasable 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
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.
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?
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!
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!
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
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
I've reached an almost final schematic and PCB layout for v0.4 of my ESC. I just need to review it and consider any worst-case points.
December 2012
I've now started working on the schematic for the next version of the PCB. The next PCB will have a CPLD dedicated to the commutation control and timing (mainly because I want to play with a CPLD), so I've also started transcribing from diagrams in my notebook to VHDL. I will still be using an AVR to govern the CPLD and interface with the flight computer, though hopefully once the motor is running the AVR's only major duty will be providing the PWM control signal which can be done in hardware using a timer.
Having spent hardly any time on this for ages, I have finally got back to it. Last time I sat down to do some work within minutes I managed to fry the FET driver, and in a micro-rage I proceeded to remove myself from my desk. My bench power supply has 3x settings - 5v / 12v / 15v. Much to my dismay, when the knob is set to the teeny bit between each setting, it outputs 32v! This of course was a little too much for the FET driver that is rated at 16v MAXIMUM... The thing that is even more annoying, is that I knew that this was a possibility, and switched it from 5v -> 12v while it was on anyway. Oh well!
So today I sat down, removed the dud FET driver with hot-air, and put in a replacement - and it works! I then got to work, with scope in hand, and got something resembling Back-EMF feedback working! Check out this video:
October 2012
The original component order that I placed had some Op-Amps that weren't spec'd appropriately (they weren't rail-to-rail). Of course I realised this a while ago, but I forgot to place the order for the correct Op-Amps. As a result, this weekend came, I borrowed the scope from work, but I couldn't actually do most of what I intended to do (BEMF sensing). Sure I got some pretty pictures that looked the way I was hoping, but that was it. Today my replacement Op-Amps arrived! So I borrowed the scope again and I got things moving!
The first thing to mention is that the Op-Amp was sitting on the battery rail (~8v in the test setup), and there was no capacitor physically close to it on the board. This was a big mistake, any noise on the input is amplified, but also any noise on the supply rails is amplified. To rectify this I put a capacitor physically on-top of the Op-Amp, and used some wire off-cuts to connect it up. I won't put the pictures inline, but if you're interested they are here: before and after (looking at Ch1 / Dark Blue) - much better, but it's still a bit fluffy.
Moving on to the exciting bit! My design uses the AVR's comparator, and the inputs are the wave seen above, and a wave that is much more smoothed (it's flat). The theory behind this is that the flat wave will fall in the center of the BEMF traces, and I can then use this crossing point to generate the timing information. The image below shows phase C (it's the one that is filtered) on Ch1, and the resulting trigger points being output on Ch2.
A quick explanation of what you see; when phase C is let float Ch2 rises, when the BEMF crosses the flattened BEMF signal it falls. Unforunately this scope only has two inputs, It would be really nice to see the filtered BEMF signal and possibly the flat signal for reference. Due to the fact that I'm using a basic RC filter, there is a slight phase shift on the BEMF signal. I'm currently unsure if that is the reason that the trigger is around 85% of the way through the floating period, I was hoping for it to be closer to the mid point - 50%-60%. An interesting point to note is the fall time on Ch2 - I wonder what's causing that... Capacitance of the trace?
The really exciting thing to mention is that I got it running off Back EMF! There is a slight damper on this bit of news though - it's far from perfect. In fact it's 'under turning' the motor, meaning that commutations occur too late, and as a result there is barely any torque before the motor stalls. I need to put my maths hat on and do some playing to figure out a decent formula to use here... And there is also an amount of jitter on the trigger (it moves back and forth), so I might need to look at implementing a filter to smooth it out in software.
Following on from the 'shorting' issue, I've discovered the cause. When disabling the 'safe' input to the FET driver, it seems that if any of the 6x control lines are driven (either high or low), then there is a brief point when both High- and Low-side FETs are activated. This causes a short (shoot-through), and the PSU cuts out. The solution for now is to set the 6x control lines to Hi-Z, wait about 150µs, and then disable the 'safe' input. Hmm...
Having sorted that out, and on a lighter note - I've taken a video of the motor almost starting unattended (it can, but it's all about timing/luck), and running at speed. It's not currently fast enough to provide anything more than a gentle breeze.
I also borrowed the a digital scope from work and have manged to have a look at the waveform on each phase. I think things are looking pretty good. The trace below shows phase A on Ch1 (dark blue), and the sync pulse on Ch2 (light blue).
The sync pulse lasts for one of the six commutation steps - so in the image above, 360° lasts from rising edge to rising edge on Ch2. The steps are ordered like so:
- A high, B low, C float
- C high, B low, A float
- C high, A low, B float
- B high, A low, C float
- B high, C low, A float
- A high, C low, B float
One last thing to mention is the commutation timing. Currently I'm driving the motor with forced commutation. This means that the steps (above) are advanced at a specific rate and that no consideration is given for whether the motor is ready, or in place for the commutation to occur. The previous trace looks almost ideal, and you can see this when looking at the following trace.
Here, the 'nose' in step #2 is part of the way through the floating period. This means that the commutation is occurring early, and that if you try to commutate faster without providing more voltage or current, then the motor will stall. In the previous trace, the nose looks to be just outside to the left of the floating period. In that case, the commutation has occurred late, and there is too much voltage or current.When I have connected my Back EMF circuitry, the signal during the floating period will be used to determine the commutation timing, and the speed will be controlled by the PWM duty-cycle (effectively the voltage).
The nose that I have pointed out here can be seen to swing back and forth when the motor is running jerkily, like at the beginning of the video.
Well... I'm quite excited. Today I managed to get things moving - It turns out that the 'shorting' I noticed before is actually just an undesired side effect of turning off the 'Safe' input to the FET driver (possibly even classifiable as a silicon bug, but I'm going to investigate this further before making such a bold claim). Having realised this, I managed to modify my code so that the 'safe' input is turned off right at the beginning, and not turned on again. This then causes the potential for brown outs and other fun things once, and allows me to output the commutation phases as I want! Check out the video below. Here you can see the same LED test harness that I used in the video on 19th June poked into the ESC.
I even carried on a little further and managed to get a motor turning! Sorry for the lack of video... It's quite boring at the moment. Before going too far however, I want to sort out this shorting problem. As an initial step to help the high freeze-on-init rate I enabled the AVR's internal Brown Out Detection and set it to 4.5v. This has the undesired (but not unexpected) effect of never allowing the program to get very far. I'm going to borrow a digital scope from work this weekend and I have some ideas to try, so hopefully I'll have a fully operational ESC (maybe even with BEMF sensing) by the end of the weekend!
This evening I decided to go back and read the datasheets, check my schematic and try to figure out why it's shorting out. By the end of this stint, I came to the conclusion that actually it was the components hanging off the 5v rail that were causing the regulator's over current / short protection to kick in. I think this may take a little while to figure out... *sad face*
In the meantime, I have a nice photo of the mostly populated PCB! There are a few components on the back, and it's currently missing a chunky capacitor and the BEMF circuitry. The 5x2 pin header at the top is for the interlink - between speed controller and flight computer. The far right 3x2 block of pins double up as an ISP header, and that rainbow ribbon cable runs off to my BusPirate.
Following on from yesterday's progress, I mounted up the HIP4086, FETs and all related circuitry. I gave it a quick spin, only to find that either my code is broken or there is something deeper at play. When tuning off the 'safety' pin, the system shorts out... The board is pretty much completely populated now - it's just missing the BEMF circuitry. Pictures and more news to come!
Today I sat down with my new 0.2 mm Ø solder and a shiny new 0.8 mm soldering iron tip! With the help of these items, and a blob of Blu-Tack I managed to hand solder that pesky TQFP-32 ATMega328p - without any solder or flux issues (see the previous post). During this sitting I also noticed (and cottoned on to) the massively frustrating effect that ground planes and large trace pours have with regard to heat - they suck it all away.
I successfully got the AVR running from the crystal, at the target speed of 20 MHz. This made me happy, as now I know that my PCB layout for the crystal isn't pants. Also, the new 'Ultra-Bright' LEDs that I have are... um... FREAKING BRIGHT!
Those issues I was having yesterday may well be to do with this - watch the pins on the close side of the IC.
That's right, some of the GND and VCC pins are arcing (such fun!). I noticed this after hearing odd (quiet) fizzing noises, and noticing failed communications with the processor, stalled processor... There is a via underneath the processor which could have helped collect some flux, I gave it a blast with hot air, it gave a wiff of (presumably vaporised flux) and seems to be much happier now.
Here is a picture of the possibly suspect via (I should probably try to avoid such layouts in the future)
I'm having some big issues with the boards. Initially I was thinking that perhaps my crystal layout was poor, but I've just lost communication with an AVR running on its internal oscillator... Hmm... This is really frustrating.
Started populating PCB v0.3, and performed my first successful reflow! (note the blinking LED).
September 2012
The new v0.3 PCBs are here! Ready to be populated (please excuse the low-quality photos).
Submitted ESC PCB v0.3 for fabrication. Two minutes later realised that the 'safe' signal defaults to off... C'est la vie... There will be a little bit of re-work necessary for each board.
August 2012
Started work on v0.3 board.
July 2012
Tweaked v0.2 design to fix some issues that were noticed, named it v0.2+. Design issues include: missing smoothing capacitor on the 5v rail, no default/idle state for FETs, missing ISP header / pads, and a lack of any useful silk screen. I also tried my hand at using SMT components.
June 2012
After spending some time playing with the code, I decided to bump the ATTiny's clock upto 8 MHz (from the stock 1 MHz). I also redesigned my initial firmware to use interrupts. I even went so far as to compile my C code into Assembley, and make tweaks from there - I managed to get some of the interrupts to be tiny... literally a couple of clock cycles. I'm also starting to feel foolish for not putting a programming header on the board... or any helpful silk screen. Duh. Note the wires to the left that run off to my BusPirate (I soldered snipped resistor leg to the ATTiny's legs/pads).
During this session I managed to get the motor running as well as can be expected (considering the major lack of BEMF for commutation timing). Check it out!
I received the v0.2 PCBs and components, and started population and developing firmware. In this sitting I got a very basic test of the FETs running. I was nervous to turn it on the first time, perhaps it was my spidey senses... When I powered the board, the LED test harness that I built was lit very dimly, and the FETs were getting really warm. It turns out that I was a numpty and had wired the MOSFETs upside down (N-FET on the top, P-FET on the bottom) - oops! To rectify this, I had to swap the position of two of the FET's legs (you can clearly see it in the video below). Once I had done this, everything went much more smoothly.
The video below shows the LED test harness that I built being driven. This basically emulates the motor, each coil is represented by two LEDs that are wired against each other. The effect of this is that one LED will light during the first portion of the phase, and the second will light during the later portion.
Finised working on v0.2 of the PCB design, and prepared it for fabrication. While designing it, I was a bit unsure of what trace width would be appropriate. Hopefully it'll do the job, and as its an 'early alpha' I doubt that it'll ever get to run at full power.
Made the first commit in my research repository - there is already a lot of stuff in there!
Completed v0.1 of the PCB design. It's very basic, and I want to check it over and have a think before doing anything else.
May 2012
Started work on the ESC, researching, and figuring out Eagle PCB. I spent lots of time reading articles and trying to get to grips with the theory behind driving Brushless DC Motors. One of the most useful resources that I found is the Microchip Application Note #857. I'm using the schematic from AN857 as a starting point, but I'm fairly sure that it can be done better... We'll just have to see!