Open-BLDC SMD prototype and final prototypes

Leave a reply
Open-BLDC SMD Prototype

Open-BLDC SMD Prototype

It has been again a long time since the last post. (I have the feeling to repeat myself here)

There have been some news on the Open-BLDC front. I have been on Motodrone two weeks ago. Because I took the plane to get there I realized that it will be too difficult to take the breadboard prototype with me. So on a short notice I soldered together a smaller version using smd parts. As an extra feature this prototype includes Allegro hall based current sensors. These will enable us to investigate vector control (aka. field-oriented control).

At first it worked perfectly. Sadly after some tests I burned two of the three bridge drivers. I only had one spare to replace, so I could not work on the software for long. Today I got replacement bridge drivers. Now I should have enough spare ones to compensate for more burning. 😉 So no news on the vector control front yet.

Open-BLDC Logic Board V0.1

Open-BLDC Logic Board V0.1

Open-BLDC Powerstage V0.1

Open-BLDC Powerstage V0.1

But I was not lazy while waiting for the replacement parts. I finalized the circuit and routed the logic board and powerstage. The powerstage was more or less straight forward but I am not very happy about the size and dimensions. I just am not sure if it is fittable on a standard Quadrocopter. Still it should be good enough as first etched prototype.

A much bigger challenge was the logic board. I somehow came up with this crazy idea to constrain the size of it to 45mm X 20mm. Still after many many hours of struggling with that puzzle I managed to squeeze all parts and wires into 45.5mm X 21mm! Yes you are right I am pretty proud of myself. I am still a routing beginner so the result seems to be good for me. 🙂

Now I have to wait so some other people review the work I did to try decreasing the amout of possible bugs in this boards. (If you like you can clone the repository here and check the stuff out, and give feedback on the mailinglist. (please subscribe before posting! :/ )) When I feel confident enough I will order some boards for testing and we can finally concentrate more on the software. 🙂

Open-BLDC Sensorless Commutation Detection

6 Replies

Hi!

As promised I made some videos. First one is showing the maiden run of a motor connected to the breadboard prototype of Open-BLDC.

(There is also a Vimeo version: Maiden Run of Open-BLDC from Piotr Esden-Tempski on Vimeo)

Yes the motor sounds like a truck. The reason is that I am making forced commutation (not detecting the right time to commutate but do it in fixed time) and the PWM duty cycle is higher then it should be. This way the motor is just jumping between the magnets and has a lot of vibrations.

The second video is a demo of sensorless commutation detection.

(There is also a Vimeo version: Open-BLDC Sensorless Commutation Detection Test from Piotr Esden-Tempski on Vimeo)

We are using a novel way without a virtual crosspoint. (you can read it up in this paper) We do it even a little bit differently then described in the paper, there are no comparators and latches. What we do is condition the signal to be in the range of 0V to 3.3V and sample it with the ADC at the right times. This is probably the simplest way to do something like this in the STM32. One can now play around with the data that the ADC delivers. I think there is a lot of stuff that can be done using such an approach.

In the video you may also wonder why it is so loud. Well the PC fan that I just forced onto the rotor is not really the best payload, also it is not balanced well and the bearings in the motor are not the best anymore because of the unbalanced load. ^^ I am also using the simplest and worst PWM scheme that I know of. The so called H PWM L ON scheme.


“H PWM L ON” PWM scheme. Click on the Image to see other PWM schemes.

You can also see in the video that the motor is pretty robust to external disturbances when running in the commutation detection closed loop. Still I am sure that it can be improved. (If you are interested the sourcecode running this can be seen here)

If I am not mistaken then only current measurement is missing in the circuitry. When that is done then I can design the first etched prototype of Open-BLDC. WOOO! 🙂

Cheers Esden

P.S. If you have any comments/ideas feel free to write them in the comment section. ^^

Open-BLDC status report

3 Replies

Hi!

It has been a pretty long time since my last post. But do not worry there is happening a lot “behind the scenes”. Well not so much behind them because I commit everything I do to the github repository (http://github.com/esden/open-bldc). If you want to follow the progress you can also subscribe to the commit mailinglist and/or the discussion mailinglist. Feel free to write on the mailinglist if you have any questions or just catch me on #uavp channel on the freenode network. (I think that are enough channels of communication 🙂 )

Ok back to the topic. Last week I was able to turn a bldc motor the first time using the bread board prototype of the power stage, the STM32 Olimex H103 evaluation board and firmware that you can find in the repository. The basic PWM scheme that is used by most controllers is implemented and works pretty well. I am also trying out other PWM schemes that may improve efficiency. You may ask why I am doing it now and not after I made a real hardware prototype of the system. The answer is pretty simple. I have to see if and how it is possible, to make sensorless commutation detection, when using different PWM schemes. I had to realize that the schemes have a big influence on the signals that can be captured.

As soon as I have more results I will make a video showing the current state and how the controller behaves when using different approaches. So stay tuned!

Cheers, and I hope hearing from you too in the comments! 🙂

IR2110 based power stage circuit

8 Replies

Circuit

Circuit

I started to build up the Open-BLDC circuit on a breadboard. Then a problem occurred. The low side works as it should but the high side just did not. After several hours of trying and reading the data sheet of IR2110 I gave up and asked Federico again for help. After some time we found an application note AN-978 from International Rectifier. This explained everything. You need to select very carefully the Boot capacitor. This is the one between VB and VS pins of IR2110. It is providing the charge for the gate of the high side MOSFET when you turn it on.

For testing you can take a big capacitor, so that when you manually switch on the high side you see something happen. I took a 330uF capacitor and it is enough to turn the high side MOSFET on for about 30 seconds. Still you have to be careful because the capacitor only gets charged when the low side MOSFET is turned on. So after turning on the power the capacitor is not charged and you have to turn the low side MOSFET on first, then turn it off again and finally switch the high side on.

In the final design one should probably select the right bootstrap capacitor. The equation for calculating that value is described on page 6 of the International Rectifier application note AN-978.

You can probably get rid of the capacitor and the diode if you connect VCC directly to VB. The problem you get then is that when the current on VS gets higher then 12V you get a problem. But I may be mistaken. Correct me if I am wrong.

Conclusion: read the damn application notes and I still have problems with understanding the electrical engineer talk! 🙂

I hope this helps someone. You can see my circuit for one half bridge attached to this post. And a picture of my breadboard.

I use the two LEDs to see what happens with the MOSFETs. They are glowing a little when both sides are off. The one connected to 12V is switching off when the high side is on and the one connected to GND switches off when the low side is on. I love LEDs! 🙂

Cheers Esden

Breadboard Adapters

Leave a reply

I am currently working on building a breadboard prototype of Open-BLDC. I will write about that in more detail in a separate post. I had a problem there. The Olimex STM32 board has two dual in line connectors that just don’t fit on a breadboard. There are some adapters that you can buy for money, for example from Number Six. But that would cost me too much time and money.

So I decided to build my own adapters with parts that I had ling around and a prototype board that I got from Uwe. (Thanks Uwe I will buy one and give you a replacement as soon as possible!) It was a lot of fun building the adapters. They are really easy to make!

Step 1
Just cut out piece of prototype board with the length you need and four holes wide.

Step 2
Solder a dual in line connector to the copper side of the board. Just don’t push the connector completely into the holes so that you can reach the copper with your soldering iron.

Step 3
Solder two single line pin connectors on the other side of the board, right and left of the dual connector.

Step 4
This is a bit tricky. You can use some wire to connect the pins of the DIL (Dual In Line) with the single line connectors. But I found out it is much easier just to put a bit more solder between the pins and let them connect. You may have to try one or two times. Having some desoldering wick around is a good thing if you happen to solder together wrong pins. ^^

Step 5
Profit! 😉

I appended some images you may consider more or less useful. I should make one more adapter to document the build process. :/ I am sure there will be such an opportunity soon.

Cheers Esden

Selecting parts for Open-BLDC power stage prototype

7 Replies

The other day I ordered parts to build the first prototype of Open-BLDC on a breadboard. It is a bit different animal then the board designs I already have because it needs legged parts.

The main problem is to find the right MOSFETs and driver chips for this application. As I have no electrical engineering background I did not really understand the values that were listed in the data sheets. I asked an electrical engineering friend and he helped me with locating the most important values. Thanks Federico!

MOSFET Values

I realized that the most important values for MOSFETs are:

  • Drain to source voltage
  • Gate to source voltage
  • Continuous drain current
  • Input/Output capacitance (turn on/off time)

The MOSFET I selected is not perfect but should do for this first prototype. It is the IRF1010N from International Rectifier.

Drain to source voltage
In my case as I am using the standard three cell LiPo batteries used in models. I need something above 12V. The smallest ones are 20V but the one I could get from Reichelt was 55V. That is still OK.

Gate to source voltage
For example the high side MOSFET has 12V attached to source. When the gate is driven low, the voltage difference between gate and source are 12V. In many cases that is a problem. Because when you charge your battery full the voltage difference gets even bigger or even worse when you try to use a battery with 4 cells instead of 3. Most MOSFET that I found have only 12V specified as gate to source voltage. It still probably works with more because of tolerances but still it is probably not good. The MOSFET I am now using for the prototype has ±20V in the specification. That should work.

Continuous drain current
This one will get more important in the future. It is telling how much current the MOSFET can put through. For the prototype that is more or less a functional test of the circuit it does not matter so much. But in the future when I want the controller to support up to 20A continuous current this one will get very important. The IRF1010N is specified for 85A at 25ºC and 60A at 100ºC. So this values are meant for applications where you have a heat sink attached to the MOSFET’s. I will try to avoid using heat sink. I could calculate the exact number but the rule of thumb is that one should take 1/10th of the value. This means that with this MOSFET I will be able to run at about 6A to 8A. As the lab power supply, I have access to and will use for the prototype, can only deliver 2A that should be more then enough. There are several other values that are connected to this one. Like drain to source on resistence, thermal resistence, power dissipation aso. One can use them to calculate the exact amount of current the part can put through. But I think it is too early to make all the calculations yet.

Input/Output capacitance (turn on/off time)
This is a set of values that tell how fast the MOSFET can be switched on and off. It will also get more important in the future when selecting the right MOSFET for the final design. For now the 76ns rise and 40ns fall times should be enough. They will probably get even lower because I am using a dedicated half bridge driver chip.

Half Bridge Driver

I did a lot less research here. Thankfully there are not as many half bridge drivers out there as there are MOSFETs. The one I selected is the IR2110. It would be a bit big for the final design because of the additional leads. But it should be OK for this prototype. The problem I had here is that I have 3.3V digital input from the microcontroller and I want to drive the MOSFETs with 12V. As it seems the other drivers that I considered don’t recommend that. That is why I had to choose this one. I hope that I will find something that is smaller and still supports the 3.3V input.

Conclusion

Selecting parts is a very tiresome endeavor. The shops only have a subset of the parts that are available out there. I wanted to order all parts from one shop that is somewhere in Germany. I could probably get better parts ordering from Digikey but it would cost more. For the next stage of Open-BLDC development I will have to select better parts. But first I how a feasible circuit should look like. That is why I am going for the breadboard test first.

If you find any mistakes or I misunderstood something here feel free to tell me.

Cheers Esden

How to build arm gnu gcc toolchain for Mac OS X [Updated 8x]

11 Replies

Hi!

[Edit: This HOWTO is mostly outdated now because of the script summon-arm-toolchain I have created together with Uwe. You can find it here at GitHub. A short description on the usage of the script can be found in the Open-BLDC wiki.]

As I decided to use the STM32 for open-bldc and ordered an Olimex H103 evaluation board. I had to build the toolchain for it. This controller is an ARM Cortex-M3 and needs a GCC version beyond 4.3 because there the support was added.

There is a pretty good HowTo on eLua. But as I decided to use the newest versions of the tools some things changed and I decided to write my own HowTo. And here it goes!

I am using macports on my mac, so the howto is based on that. You need to install additionally gmp and mpfr. It is needed so that gcc can be compiled. I also use for most of the stuff I use stow. The toolchain cannot be installed using stow because of the softlinks it creates. You cane install it using macports too.

Sources:

Now you will need the following:

Compiling binutils:

I store everything that I build by myself in /opt/mine directory. I added it to my path and other relevant environment variables just as I did with /opt/local (the macports install directory). The toolchain needs its own directory. I call it /opt/mine/arm-none-eabi to distinguish it from other arm toolchains that I have on my machine.

I need to add another note here. I chose to use the arm-none-eabi target. This way the toolchain builds Version 4 EABI binaries instead of GNU EABI. I am not 100% sure what the difference is. (Please enlighten me here) But if I understand it correctly the Version 4 EABI is the ARM standarized EABI and not the GNU version of the EABI. But as stated before I am not really sure about that.


> tar xfvj binutils-2.19.1.tar.bz2
> cd binutils-2.19.1
> mkdir build
> cd build
> ../configure --target=arm-none-eabi --prefix=/opt/mine/arm-none-eabi --enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld --disable-nls
> make
> sudo make install
> cd ../..

Now you should also add the toolchain bin directory to your PATH so that the further steps can find the binutils binaries.


> export PATH=/opt/mine/arm-none-eabi/bin:$PATH

Building GCC bootstrap:

GCC needs the newlib to build all of it’s libraries but newlib needs gcc to build. This chicken and egg problem can be solved by building GCC without libraries first, then building newlib and finally building GCC it it’s full form.


> tar xfvj gcc-4.3.3.tar.bz2
> cd gcc-4.3.3
> mkdir build
> cd build
> ../configure --with-libiconv-prefix=/opt/local --target=arm-none-eabi --prefix=/opt/mine/arm-none-eabi --enable-interwork --enable-multilib --enable-languages="c" --with-newlib --without-headers --disable-shared --with-gnu-as --with-gnu-ld --with-gmp=/opt/local --with-mpfr=/opt/local
> make all-gcc
> sudo make install-gcc
> cd ../..

I have to comment here on some options used. Somehow the configure of gcc is not able to find gmp and mpfr by itself. Because they are installed in nonstandard directories when you look at a linux system. That is why you have to help it by providing –with-gmp and –with-mpfr. In the case of libiconv you have to add –with-libiconv. Not adding this option does not break the configure but introduces problems in the build process.

Building newlib:

Now that we have binutils and a basic gcc install we can build newlib. This one is pretty streightforward.

[EDIT This section should be obsolete! The patch does not even apply to the newlib-1.17.0 sorry] Still you will probably need a patch that deals with makeinfo being not found by configure. I found it in a post on comp.gcc.cross-compiling.arm. But I offer the patch here for download and your conveniance.


> tar xfvz newlib-1.17.0.tar.gz
> cd newlib-1.17.0
> patch -p1 -i ../newlib-1.14.0-missing-makeinfo.patch # the patch will yield a warning because it is for an older version of newlib but should apply
> mkdir build
> cd build
> ../configure --target=arm-none-eabi --prefix=/opt/mine/arm-none-eabi --enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld --disable-nls
> make
> sudo make install
> cd ../..

Building GCC:

This should be simple now. We build the full GCC version.


> cd gcc-4.3.3/build
> rm -rf * # clean up everything it makes stuff safer ^^
> ../configure --with-libiconv-prefix=/opt/local --target=arm-none-eabi --prefix=/opt/mine/arm-none-eabi --enable-interwork --enable-multilib --enable-languages="c" --with-newlib --disable-shared --with-gnu-as --with-gnu-ld --with-gmp=/opt/local --with-mpfr=/opt/local
> make
> sudo make install
> cd ../..

Building libusb:
This library and the following libftdi is needed for jtagkey-tiny support in openocd.


> tar xfvz libusb-0.1.12.tar.gz
> cd libusb-0.1.12
> mkdir build
> cd build
> ../configure --prefix=/opt/mine/DIR/libusb-0.1.12
> make
> sudo make install
> sudo -s
> cd /opt/mine/DIR
> stow libusb-0.1.12
> exit
> cd ../..

Building libftdi:


> tar xfvz libftdi-0.15.tar.gz
> cd libftdi-0.15
> mkdir build
> cd build
> ../configure --prefix=/opt/mine/DIR/libftdi-0.15
> make
> sudo make install
> sudo -s
> cd /opt/mine/DIR
> stow libftdi-0.15
> exit
> cd ../..

Building openocd:

I am using the jtagkey-tiny from Amontec, and usbprog. If you are using something else the options to configure will need enabling the other device.


> cd openocd-svn
> mkdir build
> cd build
> ../configure --prefix=/opt/mine/DIR/openocd-svn --enable-ft2232_libftdi --enable-usbprog
> make
> sudo make install
> sudo -s
> cd /opt/mine/DIR
> stow openocd-svn
> exit
> cd ../..

Building insight/gdb:

Well I still have some problems here. I will update the post as soon as I find a solution here.

Compiling and flashing an example program:

Openocd supplied config file for jtagkey-tiny has an error in my case. On my machine the jtagkey-tiny appears as “Amontec JTAGkey” and not “Amontec JTAGkey A”. You have to edit /opt/mine/lib/openocd/interface/jtagkey-tiny.cfg and change the line ft2232_device_desc "Amontec JTAGkey A" to ft2232_device_desc "Amontec JTAGkey".

Now you can download stm32-blink.tar.bz2 that I cleaned up a bit. It is based on the example blink project from Olimex.

The example project from Olimex uses parts of the Firmware Library from ST. The documentation and the library itself can be found and downloaded here. You have to be careful though, the library has a very wierd license that is probably problematic when used in open source projects. I assume that the strange license may pose also problems when used in closed source projects too. But I am not a lawyer so do not kill me if I am wrong. 🙂


> tar xfvj stm32-blink.tar.bz2
> cd stm32-blink
> make

Next step is to start openocd. You should start opencd in the stm32-blink directory so that later openocd can find the binary you will be uploading.


> openocd -f /opt/mine/lib/openocd/interface/jtagkey-tiny.cfg -f /opt/mine/lib/openocd/target/stm32.cfg

Now open a new terminal and run the following commands to flash the stm32-blink binary.


> telnet localhost 4444
> halt
> flash write_image erase stm_h103_blink_rom.bin 0x08000000
> resume 0x08000000

Now the diode on the stm32-h103 board should start to blink happily! 🙂

Notes and links:

Here I gathered some additional links that may be usefull:

Disclamers:

I hope this tutorial is useful. If I made any mistakes feel free to write a comment to this post. I will try to update it if something changes and/or needs to be corrected.

Cheers Esden

Updates:

  • Fixed link to stm32-blink.tar.bz2
  • Changed links to source packages to real links.
  • Added newlib patch for missing makeinfo
  • Added some additional links. For example to the ST Firmware Library and it’s documentation.
  • Added link to the Reference manual of STM32.
  • Removed the newlib patch section.

Open-BLDC MK

Leave a reply

In the last few weeks I was working on an alternative firmware for the Mikrokopter Brushless Motor Controllers. The main goal is (as always) to create a firmware that is under the terms of a known and proven Open Source License. In this case it is GPLv3. (I am thinking about relicensing it under some BSD like license, but I am not sure yet.)

The code is available at GitHub here. There is still a lot work to do, but the motor is starting and turning as it should. Well nearly. I have some slight problems with the startup code, that needs some further tuning. Also when you break the motor it does not always detect that no more commutations take place and freezes the motor in one place. I think that I still have some problems with the commutation detection and the debounce.

The next goal is to make it possible to change the commutation timing corresponding to the commutation detection. That means that it is possible to do the commutation slightly before or after the commutation detection. For that it is necessary to capture the time between detected commutations and according to that trigger the commutation cycles. I hope that the 8bit timer that I have available is enough. The only 16bit timer of the Atmega8 is occupied by PWM generation and I am not sure if I can use it for the timings too. :/ (needs more reading ^^)

I have to make a video of the running drive soon so I can show it to you ^^

For now it is all. Take a look at the Open-BLDC site for more info and links to some interesting resources I found about brushless sensor less drive controller techniques. ^^

Cheers Esden

Updated: Open-BLDC and open source Quadrocopters

Leave a reply

Hi ho everyone!

Today I will write a bit about a “little” project I started recently. It is called Open-BLDC.

As I was writing my Diploma thesis I got involved with the Quadrocopter Community. There are some different projects and companies producing, selling and developing these small alternatives to helicopters. I really love these things.

There is only one really open source Quadrocopter, namely UAVP. The source is GPL but as far as I know you can not get any hardware anymore. The board schematics is somewhere in the repository. But still it is no more under active development and the code is pretty outdated compared to other projects like Mikrokopter.

Talking of Mikrokopter, it is an amazing project with a really amazingly big community. The problem I see there is the License. It is some strange proprietary license. I don’t want to get into the legal stuff here but it just feels wrong. Read it yourself for example here (sorry that it is only in german, it is not my fault ^^). The other thing that disturbs me is that you only get the ready product. You can not follow the development because the development branches of the code are not available to the public, so getting involved is very difficult. (yes I know there are branches of the code of other people in the repository that are doing their changes … but still) (I will for sure get bashed for calling Mikrokopter not properly open source … try to convince me ^^)

There is another project that grew out of UAVP, called NG-UAVP. The guys are working hard since 1.5 Years on their hardware and software. And as I asked them, they will probably release their source under GPL and the hardware under CC-NC. That would be awesome!!! But they want to have something really working and stable before the first release. Hopefully they will release it soon and stick to that licenses. (yes it is not completely sure 🙁 )

Anyways. I really would like to have a completely open source project from the license to the way to develop everything. One thing that is a basic part in the current Quadrocopters are Brushless DC Motor controllers. There is no open source one anywhere. So hoping that UAVP-NG gets released under GPL I decided I should start with the controllers. If NG-UAVP fails to release under a proper license and organize the development so that everyone can contribute I will move from here to the IMU and controller.

Enough said. I started up the free version of Eagle (another missing thing in the open source is a really usable pcb cad software) and created a first shot at the schematics. After that I uploaded it to GitHub (and another place where open source is lacking, a good web interface to GIT, I really would prefer to have the interface installed on my own server). Not long time after that MarcusBec from the #uavp channel on Freenode took a look at it and told me that many things were just bullshit, and what I should do to make the design better. I am very thankful for that! So I already have one very major contributor to the project! That is how Opensource works. ^^

Now it seems that the schematics make somewhat sense. The controller pretty high end, using drivers for the P-MOSFETS and three rows of them. The microcontroller is an Atmega168 which makes a lot of space for code. Three interfaces are available for now, PPM (standard interface used in modelling), Serial and I2C. In the future I plan to add Can-bus too, for more robot centric applications. Currently I am working at making a PCB design, and hope I get it somewhat useful.

I am still looking for feedback and ideas. Check out the repository at http://github.com/esden/open-bldc and take a look at it. Perhaps you find something wrong and/or worth cleaning up. If you just have questions, don’t hesitate to contact me too! It is Open Source after all!!! 🙂

Cheers Esden

Update:
I got informed that my information about UAVP was wrong. The boards of the original project are still available from http://lipoly.de/ and http://www.quadroufo.com/. The source is also still under active development also by its main developer Wolfgang. So it may be a viable basis to work on for a really open source quadrocopter after all. But thankfully is open-bldc still no wasted time, because there is still none, at least to my knowledge, open source bldc useful for quadrocopters out there. Sorry for the mistake here I will research my information better next time!