| R&D Labs: For lovers only!
|
 Most of the visitors on the Pixel site are very picture-hungry. The more, the better it seems. This part of the site has some more text because some things simply need more words to explain. Hence the title of this page: for lovers only! One should indeed appreciate this section for the same reason one reads Playboy, that other popular model magazine : for the articles... |
R&D Challenges |
This part of the Pixel Gallery is dangerous. Reading through the hundreds of mails I got from people all over the world, it seems that every time I give an answer to something, people tend to come back with 10 more questions. The reality is that it is impossible to describe a step-by-step method to bring people from the stage 'I want to make a Pixel' up to a working model. I have no plans, only a couple of concept sketches, and a few computer drawings like the one you see above. Note that almost nothing in the real Pixel is like on the drawings. That is basically because the drawings were made before the building just to get a visual idea of all the strange things I saw in my head.
In spite of all of that, I will try to elaborate on some of the major areas of development that anyone who tries to go my way will have to deal with. The challenge is best described by Walter Scholl, the man of WES Techniek. He saw Pixel, he touched Pixel, he was involved in the development, he is a very skilled modelbuilder and he continues to claim that it is impossible to copy Pixel, because one can copy the components, but not it's soul...
I would not pretend however that I am the only one able to do this. But having said that, I realize that it has been a major undertaking and that you need to be very skilled (in multiple domains), and be very patient to come to positive results. I wish you good luck, and am very curious to see how other people's Pixalikes will look like.
I have many more ideas, one of them is Pixel IV at 75 grams. You see, did I tell you that some level of obsession helps as well...?
| Blades & Reynolds | Most of you probably don't have a clue what this
means. I'll try to explain in an easy way. Not that you'll have to bother a lot, but it
will put rotorblade design in a context. The Renolds number (Re) is a representation for a
specific aerodynamic environment. Some of these mathematical numbers hit the general
public. Most popular is the Cx of a car, where even my neighbor knows that the lower the
Cx the better. For Re however it is the reverse: the higher the better. Re describe to a
large extend how a certain airfoil will behave in a certain environment. The Re number
depends on the type of environment (air, water, oil,...), the length of the airfoil, and
the speed of the airfoil. A Boeing 747 flying at 800 km/hr with a 10 meter airfoil has a
very high Re. Pixel rotorblades on the other hand, with a mere 25mm depth and tip speed in
hover of maybe 60 km/hr is on the complete other side. They have the aerodynamic
environment of a butterfly, and that is not really a floater. The point is: by nature (I mean this literally), the Pixel rotor will have a low efficiency. That means that it will require relatively speaking much more power to produce a certain lift than comparable bigger designs. As a starter, the news could have been better. On the other hand, this gives a first class pointer towards the priorities: design the most efficient rotor. Probably 70% of all my testing efforts went to that. I can testify that it takes more than cutting some rough guess blades, screw them on a rotor hub and let them spin at 1200 rpm.
|
| Blade Design | Did you know that mathematical models indicate
that the fat flies can not fly? And yet I get crazy every time their buzzing hangs around
in my house. Till proof of the opposite, they seem to fly very well indeed. The
point is that whatever the mathematics say, you will have to give it a try. 'He succeeded
because he did not know it was impossible' is an applicable statement. Pixel blades
testing learned that wider/shorter blades seem to perform better than narrow/long ones.
This goes against all theories, but can I help it? Later on I will expand on the test
set-up. Overall, longer blades (given a certain width) always score better. However, if
the purpose was to build a small helicopter, it needed to have short blades, so I made
them wider. On Pixel I for example, blades are 28mm on average, and make up for a 37cm
rotor. On Pixel III, the worst blades needed TWICE the power for a certain lift than the
best ones I made Blade airfoil is a difficult one. The thinner they are, the better, believe me. But the thinner they are, the more they flex and twist, so their is a limit. On that size, 10% relative thickness is about realistic, given that the blades are covered with 20gr/sqm fiber (put on with 'red' ZAP) for torsional strength. Blade twist can improve performance by some 10%. For Pixel 2&3, about 8% is build in. Blade taper is another attempt to increase efficiency. Make the root about 50 larger than the tip (while maintaining average depth) and you will be safe.
|
| Disk Loading | It is rather well known that planes fly better
if they are lighter. For airplanes, the biggest difference (apart from aspect ratio)
between a floater sailplane and an F3A aerobatics plane is the wing loading. Take any
plane and double it's weight (and hence the wing loading) by putting lead into it and it
will fly at least very different. Most of us will acknowledge it will fly a lot worse.
Taking the opposite reasoning, reducing the weight by half of any reasonably good flying
plane will improve flight performance substantially. Why wouldn't the same be true for
helicopters. These do not have wing loading, but disk loading. That is the weight divided
by the virtual surface of the rotordisc. One of the reasons that Pixels fly so well is that they have only about 50% of the disk loading compared to 'normal' helicopters. For Pixel that is around 10gram/sqDm, for about any other helicopter I know it is in the twenties and more. This reduced loading was one off-set against the weak performance at low Re.
|
| Detailed Aerodynamics | If you want to get into the full insight, there is a beautiful site where you can find most if not all...For the real stuff, go to site mentioned under 'Links and Books' |
| Return to top of 'R&D Labs' | |
 |
 |
 |
| One of the challenges of Pixel is that apart from making it small, I had to design rotorheads. Helicopter rotorhead are very complicated units, and making the big things just smaller does not work. So, I had to do lots of testing to get the appropriate balance between rotor size, controllability, stability etc. Above is the final version of the Pixel I head. It is a dual flapping head, without damping. This head is very stable, but lacks some control power. | On Pixel III, I build 4 different rotors, before I got it right. This is the 3rd version, conceptually similar to the head on Pixel I. I could not get the aerodynamic balance right however. I got perfect control but needed the head to spin at above 2000rpm. This is way too much, and power consumption was far above 'budget'. That head looked great, but that is not enough off course. The problem was that the hinge axis were too close to the central hub. The torque moments produced by the lifting blades had not enough 'lever' to make the heli move. | Another attempt on Pixel III rotorheads. This is the hinged rigid rotor, developed from the full rigid rotor. Results were better than with the fully rigid version (as shown on the Pixel III pages). But I kept on having a heli that was fine only for the expert helicopter pilot. And that was not what I was looking for. |
 |
 |
 |
| Pixels have a
separate motor for the tailrotor. I did not get there all by myself, because Keyence uses
the same principle. I was unsure whether this would work, but it actually works great.
This is the final version for Pixel II that I tested on Pixel I. The motor is simply glued
to the tailboom. Tail control is managed by changing the rpm of the motor. This reduces complexity of the tail mechanics enormously (no gears and transmissions from the front to the back of the helicopter), and even more importantly is much lighter. |
Same idea applied to the tail of Pixel III. It almost became routine to put it together. The motor is the DC5 2.4, and the prop a trimmed down version from WES. One disadvantage of this control system is that inertia of the propeller is going against speedy corrections. It takes a little while before the RPM rise or fall following to the given commands or gyro input. The more, most speed regulators have a build-in delay/ramp-up time to smoothen out the changes and to detect/ignore short time pulses that could be created by motor noise. All electronics have to be tested carefully to avoid left/right pumping of the tail. | Two versions of the same tailrotor for Pixel I. The bottom one is the prototype at 2.7 gram. Above is a molded one that brought weight down to 0.9 gram. Apart from the huge (!) savings in weight, this substantially reduced inertia of the tail towards rpm (revolution per minute) changes and made the tail substantially more stable and controllable. |
| Return to top of 'R&D Labs' | ||
|
|
|
| This is how a typical test set-up looks like. A simple balsa frame is build and the rotor is glued on to it. The base of the balsa frame is glued onto the digital balance. Note that the rotor 'hangs' inverted. This is to guarantee that the air is 'sucked of the table' rather than pushed onto it. In the latter case all the readings are 10% to 20% optimistic because of the ground effect (meaning that the fact that the air is pushed onto the table enhances lift). A hovercraft is about 100% lifted through ground effect, but I have never seen one fly high up into the sky. Now you know why. | This is the small
digital balance (from WES) in action with a spinning Pixel I tailrotor. You can read 25
grams of lift. Note that here the rotor is put the wrong way and hence giving too
optimistic results. To the left of the balance, above the cutter are two gray spots. These are scrapped motors that I tested to optimize the powertrain. I must have tested 20 different types or so. At the price of these little beasts (most of them were coreless, and some of them were recuperated from brand-new high-end servo's) |
This is the
testframe for the mainrotor for Pixel . At the bottom there is the already final version
of the gearbox. Two DC 5 2.4 motors are put on. The 3mm carbon vertical axis is connected
with some silicone tubing. This was to anticipate some abrupt torque effects and to allow
for easy disassembly. Gear ratio's were adjusted by changing the pinions on the motors. Servo gears gave excellent supply here (of the ones I broke to pieces to get the motor for example) |
| Return to top of 'R&D Labs' | ||
 |
 |
 |
| The test bench for Pixel III is made from light ply glued with Zap. Id realy does not take long to do. You see the Speed 300 motor, the gear reduction, the vertical hollow carbon axle, a servo glued to the sides for collective pitch, and a battery to drive the servotester used to move the servo. | The whole thing is
mounted on top of a plate, itself put on top of a more sturdy digital balance than for
Pixel I (needed because of the extra weight). Then the complete unit is hinged onto a
sturdy box, because torque effects start to be considerable. On this base I can mount multiple rotor designs, change pitch, change reduction ratio's, read RPM, measure current and voltages hence power consumption, get lift, etc. It does not look too hi-tech, but is surely works. |
Same but seen from the top. At the left you see my hand twisting the level on the servo tester to set the appropriate pitch. At the far right are the two hinge pins that allow the plate to tilt up and down for lift readout on the balance, but avoid at the same time that the whole set spins around. The motor is connected to a 20Amps variable power supply. I can set voltages and maximum current with potentiometers on the power supply and have instant digital LCD readout. |
| Return to top of 'R&D Labs' | ||
 |
 |
 |
| These 3 different motors are in fact all the same DC5 2.4. On the left is the original one, and I made (very unsuccessful) attempts to make it 'better' as seen on the other 2. Because Pixel I needs each motor to burn out roughly 5 Watt's, and because that is about TWICE the maximum rated power, I anticipated some heath problems. On the bottom right is a DC5 motor whereon I fitted real carbon brushes to the collector. That worked, but the carbon brushes were 'too big', and had 'too much friction'. The motor did fine, but I lost lots of power as compared to the original one. On the top right is the same motor reworked on two levels. First I fitted a 'real' 5-pole collector that I scrapped from a brand-new 5-pole servo motor. The result was that I had a terrible headache because removing the collector from the original motor, fixing it to the DC5 and soldering it to the original windings was too much for my eyes and hands. It surely looked great. | The second change
was that I turned down the housing to a thin wall unit, saving some 3 grams on a 10 gram
motor. Impressive, if it weren't that the whole thing had hardly enough power to turn
itself. The explanation is simple. Coreless motors need the surrounding housing to conduct
the magnetic waves. A thin wall is a bad road for these waves, and results in huge
magnetic losses. On the top right (still on the picture on the left) is the same motor reworked on two levels. First I fitted a 'real' 5-pole collector that I scrapped from a brand-new 5-pole servo motor. The result was that I had a terrible headache because removing the collector from the original motor, fixing it to the DC5 and soldering it to the original windings was too much for my eyes and hands. It surely looked great.
|
The second change
was that I turned down the housing to a thin wall unit, saving some 3 grams on a 10 gram
motor. Impressive, if it weren't that the whole thing had hardly enough power to turn
itself. The explanation is simple. Coreless motors need the surrounding housing to conduct
the magnetic waves. A thin wall is a bad road for these waves, and results in huge
magnetic losses. The second picture shows a cannibalized motor, without any housing at all, with carbon brushes, and with completely distorted windings due to high temperature and centrifugal forces. If you think the picture is unclear, I assure you that even if you have it in front of you, it remains hard to see all the details. This is all small stuff. Conclusion: the DC5 2.4 is excellent as is, and making it better is a challenge. For the freaks, there is a beautiful site that explains everything about brushless motors. See the 'Links and Books' on this site to get there. The picture above shows an exploded view of a typical brushless motor. |
| Return to top of 'R&D Labs' | ||
 |
 |
 |
| Some say this is just electronics, I pretend this is art! A 2.4 gram full proportional servo, that now comes fully assembled including the connector. The housing is not ommited, there simply ain't any to save weight. Design is 100% WES-Technik | This is the CETO receiver as it comes from WES. It ships in kind of a jewelbox, weighs 7 grams, and has the micro X-tal laying on the right. | The same beast in close-up. The connectors on the receiver are compatible with the connector mounted on the WES series servo's. If you are not going for the last gram, just plug-in and run (fly I mean). For Pixel, you will understand that no plugs were used and all interconnect wiring was soldered directly to the PCB. |
The problem Most of the technology used in Pixel is running far beyond the original limits. So are the batteries. I use mainly the 50 mAh cells from SR or from Sanyo. I got more consistent quality from SR, but my one best pack is (was) from Sanyo. Order of magnitude of current draw is around 1 Amp, about 20 times the capacity. For big capacity cells this is not an issue, mainly because the internal resistance is low (9 milliOhm or so). The smaller cells have way higher resistance (55milli) and that means that much more heath is generated. Lifetime expectations can be assumed to be short. In my first months of 'Pixelitis', I tended to replace the motors when I saw performance going down. It appeared very quickly that it were actually the batteries who gave up. On Pixel II, at 1 amp, the batteries give up after some 20-30 flights. On Pixel 4 (O.75 amp) I get some 10 flights more. Real disposable capacity is around 30 mAh. The other 20 mAh are lost in heath. Charging is a challenge I noticed that most chargers - even at 500$ a piece - cannot find out how to reliably charge tiny NiCad batteries. On my Schultze, I need to charge at 250mAmps at least to get the deltapeak work. At 100 mAmp it just keeps on charging. I notice that overcharging (like at 100mAmps) gives some 10-15% more capacity on the battery, presuming you stand next to it and disconnect the battery when it is getting hot. You'll agree that this 'manual delta-heath-peak' method is a weird option to implement on a 500$ microprocessor based charger. For normal operation I just charge on 250mAmp and that gets my battery ready after some 12 minutes. Recycling from time to time seems not making too much of a difference. Discharge Reference Data To see if my batteries are still OK, I discharge them at a fixed rate (using a discharge program on the Schultze) and see if I get the discharge curve that I measured as a reference. Note that it takes some 5 cycles of a new pack to break in and give the reference results. Once I see that the batteries score 5-10% less than the reference data, they are ready for trashing. Here is the table of voltage read-out on a 8cell 50mAh pack discharged at 1 amp, measured every 15 seconds.
And this is the same data in graph
|
| Return to top of 'R&D Labs' |
