schraubedrin

Sure thing Good learning exercise on how to use flickr.

Thanks, very interesting!

Thanks for the high quality review! As others have said, TLG has been successful in relaunching the Racers line - They just missed to print the right branding on the box. Could you please show the launch mechanism in a picture series? It seems to be quite well thought out. I was wondering how the L-arm doesn't immediately gets stuck on the rotating axle with the connector hub. Does it get stuck on the elastic mounted axle with ball, so you have to reset it after a run? I agree with Erik, could you please add some dimensions or building/connection ideas with the new panels?

... This contest is going to be even harder than i thought. Here's what two days got me so far: It's a chassis with 3 axles, the first steered and the last driven. The feature currently: reducing the trackwidth by one stud on either side: Top: Bottom: Currently every function is manual.

Another incredible offroader from you And as B model, that's even better. There's just one important question i have: Did you try it with bigger wheels?! More than the original, i think this B model would profit from the additional ground clearance.

Of corse, i wish for an official LEGO clock since i saw the pneumatic one from nico71. I think clocks are at least as good as GBCs to get more mechanics back in LEGO Technic while still being attractive to a wide audience.

I suggest to check around step 465, here's the most potential for difficulties. Best of luck solving that puzzle! Unfortunately i can't see your pictures, they seem to be dead links.

That's a tough one, there are a lot of steps coming together here and i can't find any obvious errors on your pictures. Could you please provide a picture of the underside?

If you can still move it by hand, it just means that the drivetrain to the rear axle and fake engine provides less resistance than to the left wheel/track. So i'd check the left side for additional resistance, e.g. by removing the track and see if the "problem" persists.

That's a cool concept! Could be used in some kinematic sculpture. Is the backlash still a problem with a load on the output?

As i said, i wouldn't trust this data too much. The difference between the test runs is bigger than the difference between the geartrain concepts. I'm with @Allan and @MinusAndy on this one: Although higher torque is more efficient, it's much more difficult to brace it, especially through wheel hubs. And the bracing seems to influence the efficiency even more.

(Warning: lot of text, dry theory and zero nice looking pictures ahead) Sorry for those horrible pictures - my phone from 2014 has a nice size but the camera is showing its age Whenever i see big and/or powerful model i wonder about the geartrain design, efficiency and reliability. I always assumed that it's better to transfer power with high rpm, rather than high torque. It took some time to figure out how to put this assumption to the test, but here it finally is: my geartrain testing stand V3.1: The idea is to measure the torque loss across the tested geartrain at a given rpm for a known resistance. Those measurements can then be compared for different geartrains. There are several challenges i had to solve and that still can be optimised - input is very welcome! Adjustable and reliable power source: i opted for a switching mode power supply on PF motors reliable torque measurement: originally i planned to get the input torque from electrical measurements on the motor and trust the brake's torque. Instead i built sensors based on differentials. rigid test-geartrain mounting: i think i used more 5x7 frames than 42055 but i'm still not satisfied (more on that in the results) consistent braking torque that doesnt change over time: i wanted to be able to run the testing stand for extended time, so no weight lifting or friction. Instead of an electric brake i opted for a fluid/air brake The assembly consists of: 2x PF L motors as power source with the added rpm sensor on a 1:3 ratio to get a better sensor resolution (from 20 rpm to 6,7 rpm) A rotating set of weight blocks on a 1:3 ratio as high inertia rpm-buffer The input torque sensor based on an inline planetary gearset and a lab scale The test-geartrain The output torque sensor The aerodynamic brake as power sink Let's take a closer look at the seperate modules: The power sorce are these two PF-L motors, as the brake is powerful enough to drive one motor alone into thermal shutdown - even without a testing geartrain. They are regulated by a switching mode power supply. Idealy i'd set the driving torque via the current (an electric motor's torque is proportional to its input current). My current-dial isn't nearly acurate enough, but fortunately those armchair-engineer thoughts don't matter in the real world As the rpm sensor only has a resolution of 20 rpm, i attached it with a 8t gear to to get a 1:3 ratio and therefore a 6,7rpm resolution (not visible in the picture). The inertia rpm-buffer was added because i had rpm oscilations, especially at higher torques. It's build from two weight blocks which spin at a ratio of 1:3 to store more energy (kinetic energy is proportional to rpm squared). This ratio is achived by 36t and 12t gears instead of the simpler 24t and 8t gears as bigger gears generally cause less bearing loads (longer levers with the same torque). They are hidden in the dual 5x7 frames to the left and right. To minimize the bearing losses of the weight block assembly, i didn't mount it directly in stud holes but instead layed it on four black discs. This way the weight lies on 8 holes (2 per disc) instead of 2 and has a lower rpm. Another advantage of this bearing system would be a way lower breakaway-torque, but that's irrelevant in this case. The torque sensors work by changing the direction of the roation and bracing the idler gears on lab scales. I built my own planetary differentials because they are more efficient than bevel geared differentials like those from lego and i expected a lot of torque. I had a hard time figuring out the angle between the gears so they don't have any preload. Then i realised that i could have made my live a lot easier by switching the 20t and 16t gears around The input torque sensor (red) is mounted on small turntables which transfer the force from the high torques. As the output torque sensor (green) only has to transfer the torque from the air brake, i mounted it directly on the turning axles to get more precise readings (no stiction from the turntable) The lab scales have a resultion of 0,05g up to 1kg, which is far to precise for this application. Here's a cutaway of the gears in the sensor. The input (red) and output (green) turn in opposite directions through the idler gears which are mounted on the yellow sensor beam, which then presses onto the scale. The tested gear train get's mounted in a big compromise of stiffness, space and removability. This part of the whole assembly has the most potential for optimization. For the beginning i made tests with a 3:1 ratio (power transfer with high torque) or 1:3 ratio (power transfer with high rpm). The power sink was the part of the project i experimented the most with, until i settled on this air brake. It's surprising how much energy it takes to turn those dishes. I can change the resistance by moving the dishes further inside, changing the gear ratio to the air brake, or change the dishes for some different airfoil. It has a permanent 1:3 ratio to provide some resistance even at low rpm. The size of the airbrake is also the reason i had to mount all the other components higher The connection between the modules is achieved with universal joints to prevent potential resistance from misaligned axles, the modules are braced against each other with two 5x7 frames: one immediately under the universal joint to assure correct allignment and one further below for torque transfer. Testing is unfortunately a pretty involved process: First i have to set the rpm via the voltage of the power supply (this can be a challenge even with the added inertia) Then i have to note the voltage, rpm and the min. and max. values on the scales manually. This is necessary (and difficult) because the scales have a high readout frequency and there's a lot of vibration in the system leading to readout variations from 2 to 7g. Then it's off to the next measuring point. I do this once with rising and faling rpm to prevent measuring errors by hysteresis. Automating this with a mindstorms system would be great but i have neither the sets nor any idea how to implement the torque sensors. First results showed that the variations in the testing runs with the same gear assemblies are bigger than the differences between the different gear trains I don't trust those results because of this (and because it goes against my intuition ) (green is the high torque transfer, violet the high rpm transfer) Now i'm not sure how to proceed. I could make more measurements in the hope that they'll even out eventually. Or rebuild the modules to be more stiff? I'm looking forward to your comments and helpfull insights

Hmm, I'll look into what the issue might be. Thanks for reporting it. So this isn't normal? I have to re-search my 42100 hubs every time i start the app.

In the end, we all (LEGO and FOLs) want this set on the shelves. Maybe it would be an idea to look at how to "unboingify" the set based on the provided parts list and instruction from @Ngoc Nguyen If we find a solution that doesn't look like an Osprey, LEGO could drop the name and repackage the existing parts with new instructions.

30: 10 9: 6 20: 4 53: 3 59: 2 33: 1

Are you sure you want to use those 8 tooth gears in such a powerfull drivetrain? I have a feeling that they are relatively inefficient. Those have been used in several crawlers. But with high power transfer the inefficient tooth design heats up and they die easily.

The Lamborgini leak showes us the new helicopter blade part (i think) Found here:

I actually liked the mechanisms used in 8202 and 8205

Is there a difference in torque between the axles? That would mean one of the motors has a problem. Is there a difference in torque when you use the other ports on the IR receivers? (switch the servo with the motors) That would mean an electrical problem, e.g. corroded contacts.

This looks like an impressive project. Might be fitting for the current small car contes: [TC18] Technic Small Car Contest

What an incredible looking model. I love the seamless combination of Technic and System parts. Is this the normal green color?

It's really interesting what everybody thinks of the goal of the contest. I think that's shaping our contest ideas quite a lot. For me those contests are a motivation to build and a way to jumpstart creativity. And i think restrictions are a great way to boost creativity, they start my "problem-solving-engine"

I'll add another voice in favor of small scale contests Although the theme for the next contest seems to be quite clear, what do you generally think about a part restriction contest? Something like "no gears" or "no wheels" would certainly yield interesting results.

If you're focused on power functions, i'd suggest to search a used 42030. It has the complete collection of power function parts and can be available bellow 100€ (depending on your country). New sets with power functions below 100€ are rare: https://rebrickable.com/parts/16511/electric-power-functions-battery-box-4-x-11-x-7-with-orange-switch-and-dark-bluish-gray-covers-new-version/71/?sort_sets_by=2&sort_sets_dir=D

I've finally got it working Thank you so much for your feedback and encouragement, @AVCampos and @imurvai. What i endet up doing: - Buy a cheap Samsung Galaxy S5 (~30€) - Try it with the original Android 6: C+ Hub gets recognised (Wuhu!), XBox Controller doesn't (Dang it!) - Install lineage OS 16, attemp it there: XBox Controller gets recognised (Yippie!), C+ Hub doesn't (Wait what?) - Search for a middle ground, find and install lineage 14.1: XBox Controller and C+ Hub get recognised (f finally!) Although i'm incredibly happy to have worked it out for a small price i'm more confused than ever. Somehow lineage OS 16 enables or disables the functionality of the app (as proven by the difference between the LG G2 and S5). This implies that some features Brickcontroller2 uses to connect to the C+ Hub get lost from lineage 14 to lineage 16 - but only for Samsung phones?! Maybe my S4 Mini might even be able to run Brickcontroller with a different operating system? That's all from me for now. I'll be back playing with Lego instead of phones