YC's Posts (4)

Sort by

After my field orientation control algo worked, I applied it to the quadrotor that I am building. Then, I noticed there are about 30% of chance of reverse spin in any of the hour motors. Then, things get pretty challenging, there are only about 0.7^4 of change that all motor will spin in correct direction. In real life, it is painful to start the motors.. Thus, this becomes the motivation of looking into high frequency signal injection. After pains taking a few months of learning and development, the high frequency signal injection method finally works for me. The motor now can reliably starts without backward rotation. 

For anyone who might get some interests to this, the following is just a brief learning I got from this project.

Most of the outrunner brushless motors in drones' world can generally be categorized to surface mounted permanent magnet synchronize motor (SMPMSM). There are whole lot of papers out there to discuss the application of high frequency signal injection to this type of motor. 

At somehow high speed, the back EMF is usually sufficient to reconstruct the rotor location by various methods, including but not limited to observer based and phase lock loop etc. At low speed or standstill, the back EMF is too low to make reliable estimation of rotor angle. This creates an issue that nothing can be used to estimate the rotor angle at low speed in normal driving condition without an external encoder. To enable the rotor angle detection, an external voltage signal is applied to the motor so by measuring the current from the motor to estimate the rotor angle. By the way, high frequency signal injection is pretty much the only existing sensorless method with reliable results at low or zero speed.  From a different perspective, you need to use some energy to sense the rotor location when the rotor is in low energy status. Signal injection is kind of applying some energy to probe the rotor....

Signal can be in any forms. However, sinusoidal and pulses are most common choices in practice. After running through the math, the injected signal method can only narrow down the angle estimates to one of two possible rotor angles, which is 180 degree off each other.It is pretty interesting that picking one choice for driving the motor will cause the rotor to move to the opposite direction if drove the motor with another choice. Naturally, simply picking one choice will end up with 50% of chance of clockwise spin and 50% counter-clockwise spin.

To identify which of two possible angles is the actual rotor angle, another signal will be injected to the motor and utilize the stator inductance asymmetry to distinguish the actual rotor angle. 

After knowing the rotor angle, the algo can continuously use high frequency signals to track the rotor angle to some reasonable rotor speed, then passes over to observer based method to save some energy...

As far as I tested, there is no reverse in 156 consecutive starts. It seems fairly good in resolving the reverse spin issue that I have with open loop start. 

I actually saw quite a few master theses on this topic. The amount of work I did  and the data collected in this project is most likely sufficient for a master thesis.... :)

Read more…

iPad LCD as Displayport monitor

3689714192?profile=original

I made a adapter board which can drive the back light and pinout a full size DP port. 

The backlight driver is running in constant current mode and dimming is done through a digital potentiometer.

The input is 5V compatible, but preferred to have ~ 2A to provide enough power for back light LEDs. 

The screen from ebay is far from perfect, next time I will try to order to oversea seller, at least they have a reasonable price to begin with. 

The Lcd is pretty capable, it compatible to various non-native resolutions, like 800x600, 1024x768 etc. However,  I can tell Intel integrated GPU has better compatibility in non-native resolutions than AMD integrated GPU.

The casing is card board, the laser cut acrylic is too expensive to me ....

Anyway, here are the pics.

3689714264?profile=original

3689714143?profile=original

Read more…

Intel edison Yocto image build step as of 12/13/2016

3689706420?profile=original

I spent quite a few hours in figuring out a way to build Yocto image for edison from its recipes. Here is the steps in building an image successfully.

1. download recipes from http://iotdk.intel.com/src/3.5/edison/iot-devkit-yp-poky-edison-20160606.zip

2. unzip iot-devkit-yp-poky-edison-20160606.zip

3. cd iot-devkit-yp-poky-edison-20160606/poky/

4. source oe-init-build-env ../build_edison/

5. sudo apt-get install build-essential git diffstat gawk chrpath texinfo libtool gcc-multilib

6. sudo apt-get install libsdl1.2-dev

7. download  http://git.yoctoproject.org/cgit.cgi/meta-java/commit/recipes-core/icedtea,upzip and replace all checksums in /poky/meta-java/recipes-core/icedtea/icedtea7-native_2.1.3.bb with the value in downloaded file. Then, replace all patches in /poky/meta-java/recipes-core/icedtea/openjdk7-03b147 with the patches from downloaded file.

8. comment out the following two lines 

IMAGE_INSTALL += "iotkit-comm-js" 
 IMAGE_INSTALL += "iotkit-comm-c-dev"


from 
poky/meta-intel-edison-distro/recipes-core/images/edison-image.bb

9. edit ../poky/meta-intel-edison/utils/flash/postBuild.sh line 9 to build_dir=$top_repo_dir/build/../build_edison

10. ../poky/meta-intel-edison/utils/flash/postBuild.sh

9. zip -r toFlash.zip toFlash

Read more…

RTK GNSS module build

3689705945?profile=original

I just realized this is the very first blog I ever wrote :) 

RTK GNSS is an interesting topic for many quadrotor diyers like myself. It can provide stable sub meter coordinates which is very attractive for autonomous quadrotor flights. Initially, I tried RTKLIB on windows platform, and the result is pretty encouraging. However, I cannot imagine to have a windows running computer on a quad. Intel edison is another option for me: reasonably priced, small enough, and powerful enough to run real time RTK algos. After having this idea for a few month, I noticed REACH is commercialized RTK GPS using a very much close methodology. My intention is not to commercialize my design so REACH's results confirmed Intel Edison is suitable for RTK algos.

In the second version design, I would like to have Linux take over the control. which means linux can get the data for running RTK algo without the help of of a MCU. In my design, I put a four port USB hub on board along with a few USB-UART bridges. These USB-UART converters will get rover data from GPS modules, and reference data from either MCU or 433Mhz radio. On top of that, the USB hub also connected to a 3G modules. in this way, the RTK module could get online to take advantage from real time networks. 

3689706126?profile=original 3689706074?profile=original

Read more…