Blakbird

In order to use a lift equation you would need to know the lift coefficient (CL) of the rotor airfoil. Obviously there is no test data to generate any such information because these rotors are not actually intended to produce lift. You could use a lift coefficient for a generic symmetric airfoil like an old NACA 2412 as a starting point and assume a certain angle of attack (alpha), maybe 10 degrees. Then you need the overall wetted area (S) which is the projected area of all the rotors put together. Then you need the dynamic pressure (q) which is a function of speed. This is harder for a helicopter than for an airplane because the speed changes as a function of diameter. However, you can save yourself the trouble. Although there IS an angular velocity (omega) that you could mathematically calculate which would make the rotor lift the helicopter, the LEGO parts would structurally fail and/or melt LONG before you ever got such a velocity. And even if, by some miracle, you really could generate the required lift, 9396 has no gryo for directional stability, no pitch on the anti-torque rotor, and no cyclic to control heading and balance the suspended weight, so it would immediately fly into the nearest solid object, possibly your head, and smash. It would be an interesting thought exercise to at least calculate the number and just see how ridiculous it is, but big computers with really complex calculus are used to calculate this kind of thing. Let's do it the easy way. A Blade 300 heli has about the same rotor size as 9396, so let's use it for comparison. It uses a 4500kV brushless motor, a 3S Li-Po battery, and weighs about a pound. This means that the motor spins at about 50,000 rpm. The main spur drive has a 15.5:1 gear ratio so that means the rotor spins at ~3200 rpm at full power. Let's assume it only needs half power to take off and lift the 1 pound weight. 9396 has twice as many rotor blades (4) and the Blade 300 (2), but they are also not really designed for lift so let's assume those two things cancel out. That means we need 1600 rpm/pound of weight to lift off. 9396 weighs about 2 pounds (without PF) so let's assume it would be 3 pounds and therefore would need to rotate the blades at 1600 * 3 = 4800 rpm. The linear speed of each blade at the tip would be about 292 mph (469 kph). Assuming you were using a 3S lithium battery at 11.2 volts, you'd need a massive 6750kV brushless motor producing about 700W of power and drawing 60 Amps. Considering that the largest Lego motor, the XL, is only about 16kV and produces 7W of power at this voltage, you're going to need about 100 XL motors in parallel. The PF battery pack is also limited to 1 Amp, so you are going to need 60 battery packs. Of course, all of this gear weighs much more than the entire helicopter and you're also going to have to lift all that which means you need even more power, and the weight is going up faster than you can add motors and battery packs. Now suppose you just use real R/C components instead of PF to power it. Well, the power system is going to cost you about $1000 including motor, speed controller, and batteries. Now once you install them you'll be generating a 100x more torque than an XL motor. Since an XL motor can already destroy a plastic axle, you'll quickly vaporize your entire model. Still want to try it?

Does it twitch only at long range, or always? Usually when a unit like this is twitching it is because the gears on the servo resolver are stripped. The resolver rotates along with the servo output gear and measures to rotational position so the servo knows when to stop. When the resolver gears strip, the servo can't tell exactly where it is so it "hunts" back and forth for the right position. This usually shows up as twitching. However, if this only happens at range, then it would be seem to be a signal issue, either with the hardware or with local interference. Try it in another location (another building) to see if it still happens. This will rule out local interference. If it is a hardware issue other than loose antennas, sadly you will never fix it.

Actually, they should both be turning at the same speed. As Alasdair said, the left side goes through driving rings which means that there will be delay before it starts moving, but once it starts they should both be turning at the same speed because they have the same gear ratio. If they are not turning at the same speed, then either you put some gears in wrong or there is something wrong with one of your motors.

Of course that's not wrong! Neither is it wrong to jump your radio control car over your nephews.

Despite the similarities, they are totally different sets in terms of which types of models can be built with the instructions. The only viable solution is to get both of them. Personally, I like 8094 better because I think there is more ingenuity and uniqueness involved in the models. The 8485 models are much bigger more physically impressive, but the 8094 models are just so much fun. I think the lack of a third motor is a benefit is some ways because it forced the designers to be more creative in obtaining multiple motorize functions. The external power jack is a huge plus on the second one though. Nothing prevents you from using the newer controller with 8094.

Yeah, there are plenty of bugs in LPub, but relatively few considering and most have workarounds. If you are using LDView as your rendered, make it sure it knows to scan your LSynth parts directory to find the parts. Once you can view the model correctly in LDView, it should work in LPub. You'll probably want to replace the hundreds of LSynth bits in the PLI with the straight part like this: 0 !LPUB PLI BEGIN SUB part.dat 4 Put all the lines of LSynth parts here 0 !LPUB PLI END In the first row, "part.dat" is the part you want to be in the PLI, and the number is the color. This one drives me crazy but it easy to fix. The first time you drag a callout, LPubs adds a META command something like LPUB CALLOUT PLACEMENT LOCAL XY. However, the next time you move a callout, LPub does not add another META command. Instead, it edits the last one which moves your last callout (and all the others). The way around this is to copy the first CALLOUT PLACEMENT command into your new step, then regenerate. Now when you move the callout it will edit the right command. By the way, the same thing happens with MULTI-STEP PLACEMENT. This is an artifact of the order in which things are parsed. When you have multiple levels of submodels, sometimes changing the scale at one point in the instructions seems like it is AFTER something else, but in the file it is actually BEFORE something else resulting in an effect. Its a good idea to go back through the instructions a second time after you finish which will help you clean up these unexpected issues. Once you've done a few dozen of them, you can see the problem before it happens and correct for it. Like looking directly at the code of the Matrix! I suspect this is the same problem as mentioned previous. It is probably changing a META command somewhere else in the file. See if you can find it and then copy-paste it into your current step. LPub uses fairly complicated logic to decide where to draw the assembly and this is effected by callouts. It applies this logic AFTER you drag which accounts for your change results. I tend to just change the X and Y values in the META command and then regenerate until I get it right. Good luck! Even with the problems, Kevin Clague's software makes instructions 100x easier than without it. By the way, go to the forums at LDraw.org to ask questions like this and you'll get a lot more answers.

You are not alone. I have destroyed several shocks trying to get the rod out. I even a special tool which uses an assembly of other shocks to put tension on the one I'm taking apart so I can keep my hands free to depress the tabs. It didn't help. Good luck.

The 8275 was the very first Power Functions model, so everything in it was new. Remember that the 8043 B-model is a track loader, not a dozer. A loader needs to lift the load up high which is why it uses the linear actuators. The range of motion of a dozer blade is very small so it doesn't need them. I actually like the mechanical way that 8275 did it very much. 8275 is by far the fastest of the PF models. The others are 8043 (super slow), and 9398 (slow). The 8043 B-model is pretty quick and comparable to 8275. The skid steer performance of 8275 is amazing. It will turn in place very rapidly. Also keep in mind that LEGO's choice NOT to use the linear actuator for the blade is the only reason the 8275 came with 4 of those pneumatic actuator brackets. All of the MOCs which use those would probably not have been possible without the availability increasing because of that set. The only other source is 8421 and not many people are parting that out. Even so, that part is selling for $20+ each. By the way, if you want to find reviews there is an easier way than searching manually. Just go to the "Set Index" link up in the Eurobricks title bar and it has the ability to search for any set and find reviews.

They make excellent "dirt" for LEGO excavators to dig!

I admit that I'm crazy and appear to build everything, but even I'm not that crazy.

Up until 1982 there were no friction pins at all, only gray pins. The 4459 pins offered a much sturdier construction but at the expense of ease of disassembly. They were used up until 1990 when they were replaced with the grooved part, so you'll find that a lot of the old 8800 series Technic set use them. I discuss a tool that can be made to help extract them here: It works great and saves your fingerprints from coming off.

I have built a couple of Erik Leppen's cars in which he uses those parts very extensively. You may want to check them out. http://www.brickshel...ry.cgi?f=436700 http://www.brickshel...ry.cgi?f=461416

There' no such thing as rotors that tilt forward. All helicopters use a cyclic to vary the pitch of the blades cyclically and produce forward thrust, and an intermeshing helicopter is no exception. So there really is no need to the tail "prop" in real life, although I understand its application on this model. The example you provided is fascinating! Not a true helicopter, but kind of a combination using a prop for thrust and a rotor for lift. Almost more like a gyro except the rotor is powered. Cool. The limiting factor for speed in a helicopter is that the combination of the rotor's tip speed and the helicopter's forward speed make the tip approach the speed of sound. This would destroy the rotor, so you can't go that fast. However, if you STOP the rotor and use it as a wing, then you have a much higher limit. The tip would still flutter if you went supersonic, but you don't have the rotating speed to contend with.

Cool. This is just the way a clutch on a nitro powered R/C car works.

There's one other compactor with real vibration, but it was a long time ago! Like your model (and like a mobile phone), it uses an offset mass to achieve the vibration.

Great review! Very detailed. Your close-up pictures are very sharp. What kind of camera did you use? Do you have any photos that show where the battery box goes if you add PF? I'd like to know how serious the lack of a pole reverser is. Finally, do you have any of the older helicopters that you could put in a picture for scale? I'd like to know how big this is relative to other sets.

Incredible work! I've worked Landing Gear Actuation on several airplane programs and your models are remarkably accurate. I've always preferred the older airplanes with mechanical sequencing. As for the proportional nose wheel steering, real airplanes use commutator valves and control manifolds to accomplish that, so good luck!

This thread comes up every year or so. Here is the one I started in 2009.

There are a few instances in which this length actually matters. For example, in one of Paul's cars you can't make it right with the longer axles! Took me a long time to figure that out....

Hmmm, works fine for me. I can skip to any page at any time. As Alasdair said, you have to leave the spaces and the "of xx" in there. What I can't do is export just a single page if I find an error. I have to export the whole set of instructions again. I didn't mean that 250 pages was a limit, I just meant that was the largest I made. In fact, most of my instructions start out at 700-1000 pages until I start combining steps onto one page. Still no problems with LPub and model size.

I wonder if you got bad motors? My copy is MUCH faster and climbs all the obstacles in your video with no problem.

Not sure what you mean by this. I've done 5000+ part models in LPub without any problems. I think maximum page count has been about 250.

Your parts are easily worth a couple of hundred dollars, but selling bulk part lots usually doesn't get you much money. They are worth more selling them individually, but running a Bricklink store is a LOT of work in sorting, picking, packing, and shipping. Your best bet may be to simply see if one of us here wants to buy the whole lot. I'm sure several of us would be interested.

99% of my instructions are straight out of LPub. I export the pages as PNG images then import them into Acrobat to make the PDF. All I do is add a cover page. Once you find all the features of LPub, it does pretty much everything you need.

That's not an error. The orange output does go all the way through. However, you cannot put an output axle all the way through. Your answer is right (I typed mine into the calculator wrong), but your equation is wrong. The gear ratios need to be multiplied together, not summed. My error was that I did (20/12)*3 instead of (20/12)^3. It was only a coincidence that it came out so close with such a fundamental error. Sorry about that!