HobbyKing.com New Products Flash Sale
Heli Hacker's blog
Posted by Heli Hacker | Dec 05, 2010 @ 06:12 PM | 4,563 Views
I replaced the PhuBar3 receiver input code with assembler code that polls all the rx channels without waiting on any of them. It tests fine with the Spektrum ar6100, but I will have to see if other PhuBar3 owners can try it with other receivers that actually have overlapping pulses.

Latest code is here:

Downloadable zip files are on the Downloads tab, and SVN checkout instructions are on the Source tab.
Posted by Heli Hacker | Nov 05, 2010 @ 06:15 PM | 5,078 Views
I want to document one of the differences between the FireFox 200 and the CopterX 250 that makes different gain settings necessary when using the PhuBar3 unit on these two helicopters. The CopterX 250 needs a much lower tail rate gain than the FireFox, mostly because of the difference in the tail rotor control arms (aka bell crank).

In the photos below, you see the FireFox control arm has a leverage ratio of about 1/2.6, where the CopterX ( and I believe the Trex 250 it is cloned from is similar) is 1/1.25. This makes for higher mechanical gain on the CopterX, which necessitates a lower electronic gain setting on the Phubar, or any other tail gyro for that matter. This is discussed in several threads on the Copter-X 250, Trex 250, HK250Gt, etc. Many people have problems with the tail wagging before they realize how different the 250 clone control arms are.

The tail servo link ball typically needs to be set further in on the horn than most people are used to, in order to compensate for the higher gain of the tail control arm.

On the CopterX, I have the tail servo ball link about 7mm out from the horn retainer screw, and tail rate gain of 17 on the Phubar3 seems to give good performance

On the FireFox, the link ball is 11mm out and the tail rate gain needs to be about 45 for good performance.

I believe tail rotor speed plays a role here too, since higher speed creates more force per degree of blade pitch. Plus the CopterX tail boom is about an inch longer, giving the tail rotor more leverage in counteracting main rotor torque.
Posted by Heli Hacker | Oct 26, 2010 @ 06:56 PM | 5,088 Views
Here are some videos and photos gathered and sized for linking onto Google Code.
PhuBar3 source code and documentation can be found at http://code.google.com/p/phubar/

CopterX 250 with PhuBar3 (1 min 29 sec)
...Continue Reading
Posted by Heli Hacker | Aug 01, 2010 @ 11:56 PM | 5,294 Views
Even with gains carefully adjusted, DCM has a drift of several degrees per minute. Without an accelerometer to correct the drift, I need to introduce decay into the update matrix that rotates the DCM matrix. Unfortunately adding pitch and roll decay causes the matrix to have even larger drift around the yaw axis.

The whole purpose in implementing DCM was so that yaw would automatically cause rotation of pitch and roll. But since yaw accuracy goes to pieces, I have decided to use a simpler approach - one similar to the swash servo mixing equations.

' Use Yaw rotation to rotate Pitch and Yaw values
' if roll is clockwise looking down on vehicle:
' newxval = xval(cos(yaw angle)) - yval(sin(yaw angle)
' newyval = xval(sin(yaw angle)) + yval(cos(yaw angle)
'if roll is counter clockwise looking down on vehicle:
' newxval = xval(cos(yaw angle)) + yval(sin(yaw angle)
' newyval = -xval(sin(yaw angle)) + yval(cos(yaw angle)

This allows roll and pitch to be rotated at each 100hz update cycle, without tracking all three axes together.

I almost have this working, just now chasing a bug that appears to be in my sine(angle) routine.

Update: This code was causing problems, so I decided to set it aside for now and work on getting an accelerometer integrated so I can use DCM.
Posted by Heli Hacker | Jul 31, 2010 @ 02:33 PM | 5,216 Views
With the tail rate mode and HH mode both working well on the PhuBar, I turned my attention to improving piro stability. I had noticed some instability if I do a simple piro when the heli is not absolutely level.

I believe this may be partly because the roll, pitch, and yaw data are processed independently of each other. This works fine until you have a fast yaw rate. Ideally the system needs to rotate the pitch axis and roll axis when yawing occurs. If the heli yaws 90 degrees, then pitch becomes roll and roll becomes pitch, with respect to a fixed earth-based coordinate system.

What is needed is an integrated representation of the attitude of the heli with respect to the earth frame of reference, where motion on one axis can affect the other two. In other words, pitch and roll need to be "yaw aware".

It seemed that a good way of doing this was to implement a Direction Cosine Matrix , as outlined here:



I spent the last week implementing this in Spin Code on the PhuBar3. I am in the process of tuning the gyro gain factor to get the matrix to update accurately, but so far it looks good. It rotates the pitch and roll axes appropriately when the unit is rotated around the yaw axis. The nice thing about DCM is that roll and pitch correction values can be plucked out of two of the elements of the matrix - they just need to be scaled before they can be fed into the swash mixing equations.

I am finally using some of the matrix math they tried to teach me a long time ago in Linear Algebra class !
Posted by Heli Hacker | Jul 31, 2010 @ 02:15 PM | 5,333 Views
With clear heat-shrink wrap, the PhuBar3 is about 7.5 grams. The heat-shrink stuff works best if I cut it larger than needed, then trim it around the connector after shrinking it. This one has an 8-position header on it, instead of having cables soldered directly to it.

Heat-shrink tubing is the clear 54mm material from this ebay seller:

Posted by Heli Hacker | Jul 13, 2010 @ 09:33 PM | 5,561 Views
I took a vibration measurement today on the PhuBar3, similar to the one I did earlier on the PhuBar2. The amplitude of the vibration is somewhat higher on the PhuBar3, most likely because it is mounted differently, and not as isolated from the frame as the PhuBar 2 was.

This was done with the ITG-3200's built-in low-pass filtering set to 5hz. This is a much lower cutoff frequency than the software filter in the PhuBar2 which is set to 47hz. This is comparable to the software filter in the PhuBar2, which is set to 5.3hz

Just comparing the two visually, it looks like the impact on the servo control signal is comparable between the two devices.
Posted by Heli Hacker | Jun 30, 2010 @ 09:42 PM | 5,858 Views
Some interesting test results:

After flying the PhuFox for a while, and making a lot of software changes to the 2-axis PhuBar, I went back to fly the Phubee again, only to discover it no longer flies well with the same parameters as before but with the updated software. I had to increase the decay value to get it to fly right at a 45 phase angle, analogous to removing some weight from a physical flybar. And it flew MUCH better when I changed it to 0 phasing, like I am using on the FireFox. I hadn't changed anything on the heli itself, so it has me puzzled. I'm still trying to figure out what change I made to cause this. But regardless, I have settings for both phase angles that make the heli fly well.

So then I tried the PhuFox at 45 phase angle. After the above mentioned experience with the PhuBee, I figured I should increase the decay, so I set it to 100, about the same value as the PhuBee. 100 percent decay simulates a flybar that re-normalizes itself perpendicular to the rotor shaft in about 1.5 seconds following a change in attitude. It flew with about much better stability than it did with 0 phase and smaller (slower) decay value.

I need to think about what this means. It would seem to imply that the 45 phase allows a physical flybar to provide the same or better stability as a heavier flybar at 90. And perhaps give you stability without sacrificing as much responsiveness as a heavier 90 flybar would require??

One thing is clear. I now have a single set of gain and decay values that work reasonably well, though maybe not optimal, on both helicopters. This perhaps explains how makers of commercial electronic flybar units can program them with default settings that will work well enough to at least get a customer started regardless of what helicopter they have.
Posted by Heli Hacker | Jun 17, 2010 @ 02:42 PM | 7,216 Views
As great as the keychain video cameras are, there are times when they could benefit from some kind of viewfinder. When recording helicopter flights I find myself wishing I could keep things in the frame better.

When I was into high-power rocketry in the 90's, I had the same problem with my Sony 8mm video camera. When a rocket is traveling a hundred feet per second or more, if you lose it from your viewfinder, you may never find it again. I solved this problem by attaching a Tasco red-dot pistol sight to the side of the camera. Once the sight was aligned with the camera, following a rocket in flight was easy with the 1x red-dot scope. Keep the dot on or near the target object, and you can be confident the object will be near the center of the video frame.

Doing the same with a keychain hat-cam is a little different. A pistol scope is a bit too large and awkward to use with the keychain camera. Even the tubeless type (see last photo below) obstructs your view considerably. But the concept is fairly simple. Focus a bright LED down to a small dot and aim it at a clear reflector that will reflect a portion of the light into your eye. And the apparatus has to be adjustable so you can align it with the camera. Ideally, some optics would allow for collimating the beam of light so it would make the smallest possible dot that appears focused at infinity. A laser would be great for this, but it would not be healthy for your eyes.

Here is my first attempt at a red-...Continue Reading
Posted by Heli Hacker | May 16, 2010 @ 02:08 PM | 5,830 Views
Finished board design for PhuBar 3 using ITG3200 3-axis gyro. Managed to squeeze the board size down to 30x28mm. If I solder cables directly onto the board instead of headers, and use clear shrink wrap instead of an enclosure, the whole thing should be 30x28x7mm, except for where the 5-pin programming connector will stick out from one side.

I added the fifth pin to that connector to supply 3.3v so I can use the TextStar serial terminal for field setup.

I also added connector pads for 2 general-purpose I/O connections plus ground to allow for programming the Propeller to do other functions if desired.

The 3-axis gyro will let me add rudder gyro capability, as well as use cosine-matrix math for more accurate attitude estimation.

Update: I received the boards from BatchPCB on June 1. They look really good - photo below
Posted by Heli Hacker | May 11, 2010 @ 11:13 AM | 5,957 Views
Today I did some vibration testing on my flybarless FireFox "PhuFox" helicopter using the PhuBar and ViewPort to look at the gyro data in real time.

On the graph below, the blue line is the roll rate after smoothing with the digital low-pass filter. The red line is the integrated roll angle. Green is the control signal going to servo #1. The helicopter was sitting on a soft block of egg-crate foam rubber for this test.

On the left side you see no vibration in the signals because the motor is off, but you can see that I moved the aileron stick back and forth to move servo 1.

On the right side of the graph are the same signals except that I throttled the motor up to flight speed. The effect of vibration on the signals is small but visible. The magnitude of this effect on the servo output, when measured, amounted to about 1% of the total servo range of motion. My subjective experience in flying both helicopters is that a moderate level of vibration has no noticeable impact on performance of the PhuBar, thanks to the low-pass filtering.

The change in level of the servo signal you see at t-6 resulted from pausing ViewPort while I throttled up, then I restarted ViewPort. At the higher throttle setting, the pitch curve on my radio sent a higher pitch setting to the receiver and caused all three servos to move to a slightly different position due to the CCPM mixing in the PhuBar.

There are four things that help reject vibration:

1)...Continue Reading
Posted by Heli Hacker | Apr 22, 2010 @ 09:37 PM | 7,767 Views
This winter I decided to build something that would help me fly better and crash less. Using a 32-bit Parallax Propeller processor and a 2-axis IDG500 gyro, I built myself a virtual flybar unit.

I call it Phubar, for Phase-Universal Flybar.

It allows for adjusting the phase angle of the command inputs and the gyro stabilizing inputs to the swashplate. It has angular gain and rate gain settings (Proportional and Derivative coefficients, for you control systems people) with angular decay so it mimics how a weighted flybar will "follow the heli" after a second or two. The gain, decay, and phasing parameters can be changed using a serial terminal app on the PC that talks to the PhuBar via USB cable.

The whole unit weighs about 13 grams and is 35x35x18mm. By comparison, the stock flybar plus one pair of weights is about 19 grams. It has four receiver inputs - aileron, elevator, aux(pitch), and a spare - and four outputs for servos. An LED lights to tell you when it will accept input via USB, and blinks for 3 seconds when the gyro is calibrating so you know not to move it.

I have tested it on a HBFP and a FireFox Ep200 so far, and it is working very well. It took a lot of test flights for me to find the right gain settings. Photos below show the flybarless head and the PhuBar installed. I made the FBL head for the HBFP by removing the flybar and making direct swash-to-head links using link ends and balls from a FireFox 200. TX and RX are Spectrum....Continue Reading
Posted by Heli Hacker | Sep 20, 2009 @ 03:34 PM | 6,025 Views
Also known as Bolo on the Surveyor Robotics Forum.