gyenesvi

This could be amazing if they made it with portal axles, but only the 4x4² has them, not the regular one. The regular one has independent front suspension, live axle rear, and locking central and rear differentials. Maybe we get those plus a gearbox using the new parts. Surely a fake V8 with the new small pistons. That's the most likely I guess. If the color was neon yellow, which I could imagine, and could look cool in itself, then we'd end up with another highly incomplete color, just as in the case of the Land Rover.. Nothing else produced in olive green since then. I would highly doubt that. That portal hub piece is huge and would not fit into this scale (assuming it's the same as Land Rover). Have you ever tried building with those portal hubs? They result in horrible axle geometry. They don't even fit inside the defender rims, which would be too big/wide for this model anyway. And they result in a really bad scrub radius, by which the wheels would surely get stuck in the fenders. I am hoping that they used the planetary in 42180 to clear out the existing stock. Other than that, it's just for the looks, to make the model lifted. To make this model with portal hubs, they'd have to design new ones, which would be great, but really hard as some compromises would have to be made. Something like the one on the right of this picture would fit into the Defender rims and would give good scrub radius. But those wheels would be still too big I think. Another route that could be done is making deeper medium sized rims. Then, a smaller portal hub that has a 8:16 gear ratio and only 1.5 stud height difference could fit into such a size (or some single piece hub design in that size). With Audi tires, that could look good on this. But that sounds like too much / too specialized to ask for. Why would a manual model have planetary hubs? That has a lot of friction when driven backwards, which would be quite bad for play, especially if the model had a gearbox too. I'd simply guess Audi hubs in this. I'm afraid of that too, or a recolor of that. But this model would deserve some proper, angular, better scaled fenders. Those huge/wide fenders screwed the looks of the Defender.

Oh, I'd love to take part in such a competition, great scale, cute builds, I actually have a design I'm working on right now that could fit this :) I wonder what that -6 score for the last entry? That kind of put it from 1st place to last place.. Was it not a proper truck build, or cheated in any other way?

Hmm, good to know, I thought that it's about 4x4x3 only. The 6 stud height sounds very big..

If it would be this, done properly on the inside, that could be fantastic, because that seems like the G500 4x4 Squared, lifted on two portal live axles, has 3 locking differentials and a mean stance. I would definitely dig that technically. I could even say I like how this version looks, even though I don't like G-wagons in general. But no, let's be realistic, we are not getting that. It's not really about pursuing realistic functions nowadays, it's all about the looks.. Okay, we got new gearbox parts, so those may end up in this as well. So I guess we'll get a standard version. Standard independent front suspension, simple live axle rear. If we are lucky we get a proper 4-link in the back, not just a fake one with the ball joint, including maybe a locking differential, maybe both rear and center (that's what the standard version has). Looking something like this: Now on the looks, I wonder how much effort they make for the wheel arches and the wheels. My first guess would be that they just recolor the Defender's fenders (which are overly wide and ruined the whole looks of the Defender), or just brick build it from connectors (would not look that good, but the Zetros had it too). But getting such blocky fender pieces would be great. Also, I hope they'd use thinner wheels. The Audi wheel width would look better on this than the Defender's. But that can't go with the bigger deep rims, nor can any other slimmer tire (those rims are too wide for that). Maybe we get new rims, but I would not be surprised if they just reused the Defender's wide wheels. Let's see..

Yeah, I have been thinking about that too, whether it is just called like that as it approximates the real thing or is it actually close to constant velocity.. I'd tend to think that out of all the lego joints, the new large CV joint has the most stable velocity though. But yeah, I guess the best is to align as @Stereo suggests, can't really harm things. Upon looking up a video of a real CV joint, sure they are more complex, but I'd think the actual conceptual difference between the U-joint and a CV joint is exactly that sliding motion instead of the 3rd moving part. I'd tend to think that the fact that the large lego CV joint has the spherical surface that slides as it rotates is what allows it to rotate without oscillations. It seems to me that a real CV joint also has that sliding in it, albeit with more nubs (3-6 instead of 2), and the nubs are actually ball bearings to make it smoother. But the principle seems the same in the lego version I guess.

Why would you need that? As far as I understand, the name CV = Continuous Velocity means exactly that it does not have the oscillating velocity problem of U-joints. So there is not need to align them. And I guess when you have one CV and one UJ, it still does not matter how you put them, since one of them is continuous, so there's nothing to align with. But anyway, when I use two CVs, I align them to the same orientation just to make it look better.

Wasn't RCbrick 4x4 studs on the top? That's only a bit more than half the size of yours. But I'd guess that did not contain an ESC, just a dual motor controller. True, that would also be a useful product :)

It's a good looking and nicely functional alternate that makes good use of the source material parts, great work! And fast :)

Is it possible to buy sticker sheets from lego.com? Or can I only get a new one by calling customer service? I'd like one for the Ford Raptor set, and cannot find it on lego.com (only on Bricklink, but not much available around here).

Thanks for confirming that, this is what I was thinking. Of course I guesses that from the size, but I think they could still be useful for operating certain mechanisms, like deploying/retracting spoiler, opening/closing headlights, wing doors, etc. Maybe even a small winch that would work but not powerful enough to pull. Sure, agreed :) True, but I think it's not that simple, because if you separate the receiver from the ESC, then you have the problem of powering the receiver, which is usually coming from the BEC on the ESC, so there's a two way dependency there, because at the same time the ESC then gets its control signal from the receiver. Or you need a separate BEC for the receiver, or a (more expensive) ESC that can work with higher voltages, up to 3s LiPo, that could simplify the system wiring. So I think it's a good idea to keep the two together as a minimal product. It would essentially be an RC replacement for the PF IR receiver or for an SBrick (like the RCbrick was). If you think about it from that perspective, a simple logical product would be something that has an input from the battery and 4 PF ports probably powered by two dual output motor controllers, just like the one that the IR receiver has (and probably the Sbrick has two of them). There would be two shortcomings with that: 1) Such simple motor controllers can't handle enough power for (multiple) buggy motors -> hence the need for a proper ESC for at least two outputs 2) GeekServos cannot be utilized, which have great potential in case of an RC receiver being present -> hence the need to allow the outputs of the receiver to be used directly for GeekServos Well, this is how I arrived at the concept I described above. BTW, are you using a second ESC for the PU output currently? Or just something more of a light-weight motor controller?

Amazing build, beautifully shaped, the color scheme is great, and the openable parts are also cool plus all the internal details. It has a really great stance. I also think it's recognizable :) I like that you added some unusual features. I was initially wondering what you did with all the empty space under that big shell, but man, those spare wheels take it all up..

Indeed, that's true, I forgot about that case. I guess in RC cars, this does not really happen, so enough to reverse on the transmitter.. That is indeed true for the DC motor, but what I meant is that as far as I understand the speed servo version of GeekServo does not require an ESC, works directly from the receiver like a regular servo. But correct me if I am wrong and you have experience! However, now that I think about it, to make those outputs available for PF/PU motors, it needs another ESC for those. So that mean that the PU port must have an ESC already in there, right? Yeah, that's actually an inconvenience about the PF port, takes much area.. Forgot about that, I did use that setup very rarely too.. But not so common I guess. I see. True, that's why I always keep thinking of the most flexible solution :) Sure, that could be done for extra servos connected, but for extra PF ports it kind of defeats the purpose I guess. It's great having this discussion, it shows how complex the topic is and maybe why TLG did not venture in this direction..

Looking good so far! That little car in the video has some serious power, having the 3s LiPo combined with Cada motors, must be really fun to play with! Thanks for the detailed answers! About the configuration, one thing is a bit puzzling for me; the PU port does not really fit into the concept, mainly because it's not making use of the PU itself, so can only be used as a dumb motor, so it does not make too much sense. It would be much more useful to be able to add one more PF motor, including for example a Cada micro-motor. I am guessing you did this because there was not enough space for another PF port? By the way, I don't quite get why you need to be able to reverse the PF port by flipping the connector itself. My transmitter can reverse all channels, and I am guessing that's a pretty basic setting, so all controllers would be able to do that (at least for the throttle, that you are handling here)? So omitting the flipping possibility could free up space for more ports, no? Another thing that could be improved without hopefully any real change in the electronics is that all outputs of the receiver could be made accessible by the 3-pin connections for servos (at the same time as having them connected to PF ports). This way one could choose to use either servos or PF motors on the same channel. GeekServos actually also come in the same form factor as DC motors and as continuous rotation servos, so they could be used for things that don't need much torque, such as opening stuff. Also, it would be nice if one could use the 3-position switch that you now use for the PU port for a GeekServo, for a 3-position gearbox for example. Do you think that would be possible electronically? All in all, I would imagine a really versatile configuration like this: - 4x5 stud area for 4 PF ports, half studs for cables on both ends. 2 PF ports synchronized for the throttle, as now, and two more PF ports for channels 3 and 4. For example 3 could be useful for PF lights, and 4 for opening/closing stuff using Cada micro motor or M/L motor. - The remaining 4x2 stud area would have the switch and the 4x 3-pin connectors for the 4 receiver channels directly. What do you think?

Can you summarize what the final setup ended up being? There were a bunch of options in the beginning, and I'm not sure which ones won.. Is the battery inside or outside in this one? If it's inside, how is it charged? What ports will it have? On the prototype cases, I see two PF ports, but what's that in the corner? A PU port? Or a battery plug? Also, are there two GeekServo outputs included? Are the two PF ports driven in sync? If there is a PU port, how is it driven? I guess it's not usable for steering, right? What's the channel mapping between the receiver and the ports? I guess drive channel is for the PF ports, and the steering is for a GeekServo output, and the two position channel for another GeekServo?

No it does not have it in lime (would have been nice to have it recolored to orange). Though that piece exists in medium nougat, which is like a slightly darker orange..

That's a pretty good list, I have been missing some of these, like the 2x3 quarter beam and the small panels.

This color scheme could bring us a bunch of purple and orange parts (maybe that new shade) at the same time :) Would be in for that!

Looks really smooth on the outside, and I love the tail lights, but it's the inside that blows me as well, those suspension details are really cool at this scale. Agree that it was worth the effort :)

Very cool engineering, great functions in there! I didn't think such a huge gearbox could be fit into a motorcycle, together with a clutch system! And the brakes and throttle is a great idea as well, nice mix of pneumatics, electronics and flex system. Even though it's not a really solid thing, I'd really dig something like the engine and the gearbox/throttle/clutch as a standalone model for its educational value of how a complete drivetrain works. Could be a great showpiece model with optional motorization to see it working.

For me the more important aspect of the second color edition is that the parts will exist in the given color, and will be available probably on PaB and Bricklink as well over time.

I actually really like this new trend of releasing models in a second color. True, that releasing the second color later can make buying decisions harder, but this is a really good way of filling gaps in the color palette, and making newer pieces available in more colors, without them needing to design a new model. I think they should keep it up if that means getting pieces in more colors! And I really like they picked (regular) orange for this one :)

That's interesting.. wonder if it will become available in more generic colors.. And to ask it another way, why is that other themes can get such specialized parts, while technic cannot get some basic connectors that are missing from the system?..

I guess even if it's not necessary here (it is probably in some other set), they want to use it more frequently to amortize the cost of creating a new part. This model also uses new truss pieces from the crane, which are probably not irreplaceable here either, though might make the frame construction simpler / more streamlined, but definitely help with decreasing the cost of that part, which otherwise would rarely be really required. So I welcome this kind of part re-usage. (I actually wonder about the other way around, why don't they make more parts that could be used in many places, even though they are not that often really required, such as a 4L beam.. surely they could easily amortize the cost of such moulds)

What do you mean? Even if it was possible with the current situation, you would not do it that way? That's exactly what I'm trying to understand; what's possible with the current situation (and how), not proposing a new feature. So that the Pybricks team can work on the remaining FW features while the community can work on control programs for official sets :)

Indeed, I can see it hinted for the Xbox controller. Thanks for that older discussion link, interesting, but unfortunately, that does not answer the question, as the latest version of the program in there uses two Lego remotes instead of one Xbox controller (so avoids the problem). But in general, I know that connecting a controller to one of the hubs and forwarding control commands from there to the other hub is a possibility. I guess this is what @Pybricks was referring to when hinting that it could work with 10 hubs as well. Even for that, there are two technical possibilities: using Pybricks on all hubs and sending commands via broadcasting, or using Pybricks on one of the hubs and controlling the rest via the Lego Wireless Protocol of the original lego firmware. I wonder which solution could work better though when an Xbox controller connection is also present. But anyway, I first wanted to know if an Xbox controller connection to two hubs is possible at all, as that could be the most direct/simplest solution. If not, we will have to fall back to one of the above two. I just wrote the same in the meantime you posted :) Well I don't think that would be an issue, each hub would have its own program, which could know which controls (buttons/joysticks) to look for, and the two would use a disjoint set. Might be true for Xbox controller, but I guess in general BT devices can connect to multiple others, just like the phone app can connect to two hubs in the original C+ profiles. Might depend on which one is central / peripheral device, as it may be that one central can connect to multiple peripherals but not the other way round (not sure though). I guess in the case of the phone app, the phone is the central and the hubs are the peripherals. But in case of Pybricks, it may be that the hub is the central and the Xbox controller is the peripheral. Though wonder how the computer connection is solved then, it that also acting as a peripheral?..