2GodBDGlory

I've long wanted to try and build a full RC car in which NOTHING can be taken apart. I'm pretty sure it can be done, but I'll have to get experience with using digital Lego programs first.

I didn't see the older discussion, but I suppose the only other real possibility is that it is an old prototype.

I'm glad to see some more effort being put into PU automatic gearboxes. I've played around with the concept before, with the shift point being determined by the difference between the motor's actual measured speed and the theoretical speed dictated by the remote's position, but this looks quite a bit more sophisticated. Good job!

Thanks! I have been somewhat conflicted over whether or not I should keep it this close to the original, given that I could probably make a much more interesting, more functional, model of some other set, using significantly more creativity, but I did feel like something like this was the most within the spirit of the contest. I'm glad that you appreciate that approach.

Sounds like we're all the way up to seven motorized functions, which would definitely rule out any use of the Mindstorms hub in the set.

I've had the thing done and apart for a while now, but haven't got around to posting my final pictures until now. First I will list the functions, and then show the pictures. Functions: Crank-operated landing gear Crank-operated winch boom deployment Crank-operated winch Crank-operated main and tail rotors Joystick-operated two-way cyclic pitch mechanism with swashplate. My images are at: https://bricksafe.com/pages/2GodBDGlory/whirlwind-rescue

Is that information from the original source? Large cylinders would just mean normal cylinders, right, rather than a remake of the old 2x2 square pistons? (I just ordered some of the old ones in case I want to try building bigger model engines) Overall, the set does sound a lot more interesting, and Bric-a-brac has been reliable in the past, so we can be fairly confident that it's true!

Strange but fun!

If it actually were the Supra, it would make sense to delay it, since there would likely not be a market for a second simple, orange, real world motor vehicle after the Raptor!

Well, I wouldn't be too certain that there is no gearbox. It's not necessarily likely that it will include one, but it does appear to be at least a rough successor to the Defender, at least in being a fairly large 4x4. I think we could all agree that a gearbox could have fit in the Ferrari without too much trouble, so the scale wouldn't exclude it here. Really it just comes down to Lego's preferences, which have admittedly not been encouraging, but perhaps the set's loose connection to the Defender could show an inclination to include a gearbox...

I like the idea of building the mismatched body panel one!

The Rwd would be a bummer in a set this large!

Probable functions: Front independent suspension Rear solid axle suspension V6 piston engine 4WD Gearbox (likely a 4-speed sequential) High/low transfer case (less likely, given the smaller size relative to the Defender) Opening stuff

Wow! That looks very cool, and has the key new-car-marketing tie-in. It definitely appears to be a defender successor, (Edit: probably not exactly, since the tires are smaller when the real Raptor's are larger, and the part count is also a lot lower.) and makes good use of a number of new parts from the January wave. I assume the wheelwells and fever flares are the same as the Ferrari's. Where did this image come from?

I love the presentation of the model!

Sariel has posted on YouTube that the embargo date for this set is July 16, so we can now set a date to get concrete information on this set!

Sariel has posted on YouTube that the embargo date for this set is July 17, so we can now set a date to get concrete information on this set!

The tractor tires would make it look like a legitimate off-roader, while the defender rims+68ish mm tires make it look like an average G-Class: Glitzy and good-for-nothing, with the strange combo of sports car style and rims and off-roader chassis. I don't mean that as a criticism of your work, though, and I appreciate seeing all the different rim+tire combos.

I recall seeing transmissions with the same working principle (fast forwards, slow backwards), but not necessarily the same execution. Your design has a pleasing simplicity, but is still a bit difficult to understand from a picture. I also found that it ran much more smoothly with the 16T clutch replaced with a normal 16T gear, and the 4x2 beam replaced with two #1 connectors and a 2L axle. Nice work!

Good choice of set and approach! This is one of the most completely functional classic Technic sets, so it should make a good model.

Thanks! You're right that the styling is sparse, but so is the real set, and the information topic tells us that "The main voting criteria is whether you have replicated the sets as close as possible!" and that "the first and most important criterium [is] True to the original," so I think I'll keep it this way. I would definitely fill it in if it were a standard MOC, though!

I haven't seen that video, but after looking closely at the image I too am convinced that it is just a bunch of standard parts put together, with the cracks between parts just being "left out" of the picture. The shape is just too odd to be a new part, in my opinion. I'd be happy to be proved wrong, though!

After building my previous mechanical calculator, which featured two sets of buttons and an adder mechanism to add two single-digit numbers, I wanted to go beyond that and create a multi-digit calculator. I eventually settled on a four-digit setup, and came up with this model here. Before I actually show it, though, I should mention that this model was functionally a failure, because it would not add or subtract with tolerable accuracy (The accuracy was about +/- 2 in each decimal place, so if the real answer was 5426, the calculator might tell you 3204, which is totally unacceptable!, and that's assuming that all the carrying was correct!) Despite that, I think it is at the least a good theoretical framework of how such a calculator can be constructed, and a good first attempt. I'm already starting to think of how accuracy could be increased, so maybe I'll have something to show in several months. Anyways, I'll now endeavor to show this machine, though my YouTube video at the bottom may end up being clearer. Overview images: So, the basic working principle is that when a number button is pushed, first a linkage moves to engage a transmission driving ring on one of the four digit axles which causes one of these dials to rotate until it strikes the axle pushed down by the particular button, allowing a button press to roughly choose 36 degree divisions of rotation. Then, the axle transmits drive through this freewheel which allows the main dial to be reset without affecting the output dials. Next, the drive moves through this carrying mechanism, which is very similar to a design Nico71 used in his mechanical calculator This is known as a sautoir mechanism, and allows for gravitational, or in my case, rubber band, energy to be gradually stored as an axle rotates, and then released all of a sudden. This is used so that as, say, the units dial rotates from zero to nine energy is gradually stored so that when the dial moves from the nine position onward to the zero position again, energy can be released to move the tens digit forward 1/10th of a rotation, effectively doing a carry from 09 to 10. This can work all the way down the line, such as in 0999+0111=1000. Each axle continues past the carrying mechanism to the forward/reverse gearboxes, which are simple, low backlash sliding gear designs, though transmission driving ring parts are used simply to slide axles forward and backwards. After this, drive is taken to these white dials. Now, in order to add numbers, it is not merely sufficient to press, say, the one button and then the two button in a single decimal place and expect it to result in a three. Rather, the axle would just continue rotating from the one to the two position without any adding. To counter this, there is a resetting mechanism that must be employed between inputting numbers. This is engaged by reversing the main drive motors, which can be done in a few ways, as I will discuss later. This causes a worm gear to slide along an axle in a direction-sensitive gearbox, activating a long axle (Sometimes the 24T gear needed a bump to engage it) When the axle rotated, it sequentially pressed down the levers activating the transmission driving rings for each number, which caused the axles to rotate backwards, one at a time, until this stop was activated and the friction clutch slipped. This had to be engaged separately to prevent the reset mechanism from stopping once the first dial reset and slipped the shared clutch. Because of the freewheel mechanism discussed earlier, resetting the input mechanism did not affect the output mechanism. The control mechanism was based on a PF switch (Actually a knock-off one, because all my Lego ones range from finicky to broken, ironically) and had several buttons, which were ON, OFF, AC, +, and -. ON just turned on the drive motor, which then stayed running until another button was pressed. OFF pressed the switch back to neutral, and held it there with friction. AC reversed the drive motor, and while + and - also reversed it, these buttons also flipped the forward/reverse gearbox in the calculator. A typical control sequence might look like ON, 5678, -, 1234, AC, OFF, with the minus being necessary for both resetting and ensuring that the gearbox is in the right position. Another mechanism was designed to sense when a negative answer was reached. Originally I had planned to make this automatic, but in the end it requires close observation, followed by a flip of a lever. The theory was that, provided that the 1000s, 100s, and 10s digits were zero, any time the 1s digit went from 0 to 9 backwards the number would be negative, while if the 1000s and 100s were zero, any time the 10s went backwards from 0 to 9 the number would be negative, while the 1s would make no difference, and so on. In the end, there were four levers with orange parts on the end that could be made visible through slits. Each digit above the ones had cams on a shaft to bump the levers to orange when the digit was at zero, and all four had ratchet-type mechanisms to bump the levers extra high, but only when travelling backwards from 0 to 9. Additionally, each lever was set up so that lifting it would lift all of the levers below it. If it were ever observed that all four slits showed orange at once, this would show that the output had become negative, and a red lever would need to be flipped, revealing a different number on each dial, which was the negative complement. For example, if the number started as 0003, and 0004 was subtracted from it, the dial would originally read 0009, which is obviously incorrect. Once the dial was flipped, though, the negative complement of 0009, namely -0001 would be revealed, which turns out to be the correct answer. Finally, I should discuss the procedure to reset the calculator after use. First, the AC button had to be pressed to reset the input half, but then the tan 20T gears visible here would have to be manually turned to reset the output dials. The big issue was that whenever the negative button was pressed the dials would get out of sync, forcing the user to flip the calculator over and disengage some 20T gears by sliding them along their axles, prior to recalibrating the zeros on the dials with the zero positions on the carrying mechanism. This is something that was quite disappointing to me, that I hope I can fix on any future iterations. Here is the video, which may be more easy to understand! My images can be found here: https://bricksafe.com/pages/2GodBDGlory/whirlwind-rescue (Yes, I put them in the wrong folder by accident. Ignore the half-built helicopters and you should be fine) Overall, this was a very interesting mechanical exercise, but was far from a working calculator, to my regret.

Sorry about that! I'm not quite sure what the 1024 is referring to, though. I'm using BrickSafe for my pictures, and I see that I can select sizes of 640x480, 800x600, and 1280x960 (pixels, I assume). If I embed the 640x480 will that be small enough, or is there something else to the image size I'm missing? Thank you

Interesting model choice! I'm curious to see how such a small model will be rendered studless!