gyenesvi

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?..

@Pybricks is it possible to connect the XboxController to two hubs at the same time? Or how is it possible to write control programs for sets like 42100? In the video of @kbalage above, you show the Leibherr Crane (42146) in action, which has two hubs, so I am guessing it is possible to make it work somehow. But I tried connecting to two hubs by pressing the pairing button while connected to the first one, and although it does connect to the second one, but then it drops the connection to the first one.. Is there some trick for making this work?

Wow, I didn't even know that one existed. It is indeed underwhelming though.. (And it is actually built out of 3 sets..)

I guess that should be possible, why couldn't it?

Not sure how those would help. Where could they get stuck when raising? I think they would not even need to touch the bottom/top either, as the full range of movement seems to be less than half a stud, actually even a bit less than a plate, so there would be tolerance space at both ends against any jamming.

These new piston pieces are nice, they do make life easier in dense builds, though I don't get why that extra spacer (the two collars) is required at the top under the stud. This way it won't fit into a full stud sized space under the hood, as the pistons stick out about 1.5 studs in their up position, while if that half stud would have been spared out, they would only stick out 1 stud, and the whole engine could have fitted into a 4 stud tall space (including the driveshaft). Not sure if that spacer has a function or if that's just for aesthetics (which would be a pity).

That means no new 5L steering links :( Also, it's pretty sad that they have budget for this kind of unique (=not so reusable) A-arm with towball sockets, but they can't make generic technic beams with towball sockets in more sizes.

That's a really nicely made alternate model, good choice for the set and great use of the available parts!

That's how I understood it, even saw the Python code for the controller! I just saw in the GitHub discussion (for the development) that it's kind of prepared for supporting more kinds of controllers, but for now the Xbox ones are done and tested, but they will probably add more in the future. They said they'd mainly target mainstream widely accessible ones though, maybe not all kinds of generic ones (the hard part seems to get it to connect smoothly). I'd expect PS controllers next maybe.

Sure, that does exist, but not in the same speed/power category as L or XL motor. It's a very weak one only useful for switching mechanism and maybe very small models. Even the PU L motor is weak for steering bigger models (depending on the steering mechanism). So I meant the above for a regular drive/steer motor.

Oh my God, so it happened! Best news of the year so far :) I was only hoping this to become reality, but they did it, and it seems they did it with style. Seems really well implemented at the first sight, will need to dive into this asap..

I don't get it. What if you have 3-4 motors in a model how do you charge it? Sure you won't take out all of them.. Most probably you won't have access to their charging ports either.. That's just too big for a motor.. Even the current ones are already too big.

That’s probably because 42160 is not designed for heavy off-road, it is not geared down. But this Jeep has planetary hubs, huge difference in torque. I do have builds with C+ system that can climb well. Also depends on the battery.

Great! Well that's the difficult part with the C+ battery, can only go in the back at this scale I guess. That's what I have done in my next Jeep Wrangler in similar scale that I'll publish soon :) It's completely Control+

So what's the difference? Are there multiple new versions? The two chassis renders that you show seem to be different both from each other and from the first version you had.. I can see you replaced the front leaf springs with shock absorbers.

It does not matter if the connector sunk inside the motor or not, it still needs the same amount of space :) (which is bigger than a stud in at least one direction). So they'd have to make the motor housing bigger in that case, and loose the same amount of space or even some connection pinholes on the housing. Sorry, no idea what you are talking about here about raising voltage, but one thing is quite probable; Lego is not manufacturing the actual electric motors themselves, just buying readily available ones, so can only work with form factors that are available out there.. But sure, more compact stuff could be manufactured for a specific usage. Just not worth it for Lego.

I can believe that the worm gear is secured strong enough, but the weakest link to me seems the axle-pinhole connector onto which the steering links are connected on both sides. Nothing holds that in there in a form locked way. Interesting that that hasn't moved out in your tests, probably it also depends on how new the parts are, maybe over time it can get more loose.. But yeah, I can also imagine that in a manual model that you only play occasionally on flat surface it won't really make a difference.

But Lego often comes out with cars that are just recently unveiled, like the new Defender and the new Ford Raptor was back then. Not impossible, but taking that into account, the new Land Cruiser seems more probable to me.

Why do you think so? The real one is not a new model, right? But what would be the advantage of that? It would be hard to recharge the model.. I'd be more happy with just smaller motors that are a bit more powerful. That battery looks too good to be true, constant 9V and 1300mAh at that size. Most similar rechargeable 9V batteries are just a few hundred mAh. Have you tried one of these? Though these batteries kind of show how much smaller hub Lego could actually have..

Indeed, that was a big advantage of PF motors On one hand that would be an advantage, but on the other hand, it would not allow you to integrate the motor so tightly, because the plug would be in the way (a plug is about an extra stud more bulky than just the cable baked in). That's impossible, due to the planetary gear-set inside the motors. If you'd want two outputs, you'd have to put a planetary gearset on both sides, which would just make them longer and cause more friction. Sounds logical to some degree.. The system could probably handle a little more power without big problems. Please NO! That one has a really bad form factor, pretty hard to integrate in medium sized models. Plus we already have the Buwizz motor filling in that space.. Actually, the same motor that's inside the buggy motor can fit into an L motor casing.. Now THAT would be awesome! However, I think the most probable would be just a redesigned XL motor, since that's the kind of useless one now in the lineup. Similar size, proper power, maybe somewhat different shaping. And not even sure it actually needs a position encoder; could reduce its length by one stud.

As far as I understand this would not use only 2 shafts; that would be my goal for simplicity and space saving. Also, I know more gear ratios are possible with differentials, but that's also something I'm trying to avoid here, as they are bulky (too long). That sounds interesting, so you are saying that some clutch gear engagement could happen on the upper shaft, while the others could happen on the lower shaft? I guess that seems logical, as the fork is 3 studs tall, and the ball connection is in the middle, so can simply be flipped around. And then leaving out the 20:14 gearing, and one more, we could get a simple 4-speed version, using for example 24:8, 20:12, 16:16 and 12:20 for the ratios? Wonder if the same could be done using two wave selectors as well on two shafts.. Would become more compact, as the forks/drums take up a lot of space sideways if we want to keep the main driveshaft in the middle. Maybe it is possible to sync two wave selectors in the right order using the new 45 degree knob gear on one shafts and the old one on the other.. How about the way above?

The chassis is looking clean, but that steering linkage in the front seems to be pretty prone to sliding apart sideways, exactly the direction of the forces acting on it. Also, what kind of geometry does the rear axle have? Is that independent, or something like trailing arms?

I'd say partly. Of course it takes advantage of position encoding for servo steering and gearbox control. However, as far as I know from usage and the user guide, the app does not support using speed servo mode of the motors (meaning that the Buwizz would automatically adjust power to keep the motor running at a specific speed depending on the joystick position); it only supports direct power mode. For full throttle, it does not make a difference, it would make a difference for low speed crawling for example. I believe this is a missing feature in the app itself, while the Buwizz firmware would actually be able to do it, according to the firmware documentation. So hopefully in the future it will be added to the app as well. Similarly, there might be other smart features missing.. On another note, I have just tested the app with an Xbox controller. Even though the documentation said that it would only work from Android version 12 and up, mine has version 9 and it still works fine. However, one strange behavior I observed with the latest app version, is that the Back button does not work inside the app. Does that happen to others as well?