After again a way too long time some new news! I finally implemented hardware based commutation detection and the associated closed loop controller.
That was quite a run because of a cascade of timing and timer problems. And a very nasty compiler bug. But now it works and very well on top of that. Woohoo o/ But see for yourself in the video.
The video also shows the new implementation of the startup routine. It uses now a separate software timer. It was made possible by using SysTick as timer base and implementing the timer in software. This way it is easy to add new timers that don’t need to be very time precise, as it is the case in startup, or ignite as I like to call it. 🙂 The old implementation was using timer overflows of the commutation timer that led to nasty speed jumps while starting up and made the startup unreliable.
Next step, put Open-BLDC on a plane! 🙂
As always you are welcome to drop by in #open-bldc channel on freenode if you have questions or just want to hang around to follow the cutting edge development. 🙂
As Tobi is learning about Open-BLDC to be able to help me with development I really felt the lack of documentation. So together with him we wrote down how the ignition system currently works. Also I added a getting started page describing how to build the firmware.
Last but not least (that took me most of yesterday) I finally managed to add doxygen generation to the firmware code. It is even being automatically generated out of the git repository and making it available on http://doc.open-bldc.org.
There is still a lot that can be told about the system, but I think we are on the right path. The documentation should grow now significantly when I am not the only person working on the code. 🙂
Just a short update so that you don’t think that I have disappeared completely. 🙂
Lately I am really busy so that is why my updates here are very rare. I have moved to California few months ago to work full time on Open-BLDC and Paparazzi. Although Open-BLDC got quite a bunch of attention there is still a lot to do, and this project is still not in a state where it is possible to put the controller on a vehicle and fly with it. 🙁
There is some good and bad news. I got the sampling based commutation detection running pretty good. There is an issue with it. Because you can sample the BEMF only once a PWM cycle the resolution prevents turning the motor very fast without adding some kind of an estimator or at least a PLL. So currently only 4000RPM with a 7pole pare motor are possible. 🙁
That is why I started working on Open-BLDC v0.3 hardware. It is assembled now and you can look at some pictures here. It has a comparator integrated into the power driver board to make commutation detection really easy and have something usable _NOW_. I also found out that using many small mosfet’s is much more efficient then using single big ones. The gate capacitance is lower, the heat dissipation is easier, the on resistance is tiny. The only question is if they will distribute the power evenly between the switches. That is still something that has to be tested. But the power stage board looks really pretty with all those tiny fets on it. There are many more other smaller and bigger improvements that would be too much for such a small post.
I am currently bringing up one subsystem after another. I had to change some of the connections to the STM32 which means that I have to change the low level drivers and it is always a pain to do.
Anyways, there is progress and Open-BLDC is not dead! I am working on it. And I am sorry for not keeping you guys more up to date. As always I will try to be better about that. 😉
Because I wanted to have a small JTAG adapter with additional UART port and a different (smaller) connector then what is available out there, I have decided to make a JTAG adapter. I chose the FT2232 USB adapter chip. This guy is pretty nice because it has a special engine inside that is supporting many different protocols. One of them is JTAG. I have released what I made as always on GitHub under the CC-BY-SA 3.0 license. There is no software needed on the adapter side so no software included. All you need is OpenOCD. It now even has a config file dedicated for Floss-JTAG. Calling for example:
will connect to Open-BLDC using the Floss-JTAG adapter.
Building Floss-JTAG I learned a nice lesson. Always check your footprints 10x before you send the gerber files to the manufacturer!!! I had to customize the footprint for the FT2232 chip and made a mistake. The pads were not long enough so the pins had only 0.1mm overlap area. It was a real pain to solder that. I assembled 3 of Floss-JTAG using this design. Sadly only two are working.
Because of that mistake I immediately corrected the board layout and sent it out. I got the boards today. I hope that there is no other mistake hidden somewhere. 🙂 Attached are the images of V0.1 assembly and of the V0.2 boards.
Finished Floss-JTAG V0.1 Back
Finished Floss-JTAG V0.1 Front
Floss-JTAG V0.1 After Reflow
Reflowing two more Floss-JTAG V0.1
Aligning parts on Floss-JTAG Before Reflow
Floss-JTAg V0.1 connected to Open-BLDC Logic Board
I finished soldering Open-BLDC V0.1 boards and took some pictures while doing so.
After connecting it to the power everything seems to work properly and nothing is burning. That is really good news.
One little thing that is bothering me. The board draws 60mA, what is a value that I expected. The 5V linear regulator gets really warm. I am not sure if that will be a problem or not. But I did not find any other problems or screwups yet, even the big MOSFETs can be soldered using a simple soldering iron. It takes some time though, because the board and the MOSFETs are monstrous heatsinks.
More news coming up as soon as I start playing around with the software.
I assembled the basic STM32 circuitry of Open-BLDC and it works. I also made a video showing the logic board and blinking around. I know it is a bit pointless but I love blinking LED’s! 😉 I wrote the software using libopenstm32.
Over the last two weeks many things happened. I found out that there is a really open-source and open-hardware quadrocopter project in the wild. It is called booz and is part of the paparazzi project. Code and schematics just as board layouts are under the GPLv2 or later license. That is really awesome news.
This project is intended for research and universities so the boards are using BGA parts that are difficult to solder for a mere mortal, and there is some lack in documentation. That is why some other people and me started a project called openmulticopter. The basic idea is to create and maintain a completely open-source quadrocopter/multicopter platform for everyone. As a multicopter does not consist only of the control electronics but also contains parts like remote control receiver, brushless motor controllers, a frame, and so on, we tried to combine many open-source parts that are already out there. Just take a look into the wiki for more details.
Some highlights of open-source components that we have chosen so far are:
There is still a lot of work in front of us, but I am really happy with the progress we are making. If you are interested in contributing just drop into the #openmulticopter IRC channel on Freenode, or write an email to the mailing list.
Some time ago I announced the Open-BLDC project in the Mikrokopter Forum, the post, that you can find here inspired a very interesting Discussion. One of the topics were PWM Schemes and why one should think about them. The most important reason is efficiency. Most controllers to use H_PWM_L_ON or H_ON_L_PWM schemes. An alternative is PWM_ON_PWM scheme which prevents currents through freewheeling diodes connected in parallel to the MOSFET’s. The freewheeling diodes have higher losses then a MOSFET. I am really asking myself why it is not used. One reason I can think of is that this scheme has 12 steps instead of 6 and therefore is more difficult to implement and BEMF measurement for commutation detection may be more complicated.
Another approach to the efficiency question may be using fieldvector control. This involves a sinusoidal pwm scheme and current measurement on the phases. Using that way of control should decrease torque ripples which are typical the other schemes mentioned above. It also involves a lot more work on the firmware side.
I started building a rig for testing the efficiency of the different schemes. It involves a harddisk platter connected to the motor and two harddisk magnets. At the end I will have a eddy current break and can measure how much current is needed to achieve a specific rotation speed. I hope that this way I will be able to make a more or less scientific comparison of control approaches.
If you have a motor controller I would be really happy if you could take an oscilloscope and record the voltages on the phases. I am really interested what control schemes others use.
As you already know I have layouted the Open-BLDC boards. I was not sure if everything fits mechanically. So I took some cardboard and created a mechanical mockup. It really looks good! It is darn stable (even though it is only cardboard and not FR4) and the screws fit snugly. I think we are getting really near to a state where I can order some boards.
You can take a look at some images attached to this post.