gyenesvi

First of all, this is not that brand new (has been discussed somewhere), second, as far as I know it seems to be mostly copied from RacingBrick's website, adapted to the new visual design.

Interesting idea indeed! As for usage however, I'd expect something different; I'd expect that it does not need a battery or a motor (because that's what you wanted to avoid in the first place, no?) Instead, could it work like the fake piston engine, in which case the wheels are driving the pistons. For the fake electric motor, the rotational movement from the wheels could generate the light maybe? Then it would be the equivalent of the fake piston engine and would not need extra (expensive) components. By the way, given your engineering background, aren't you interested in making non-fake lego electric motors? I could see an interest for that :) Like fast motor, small motor, servo motor, etc..

You are right that PU could be used like PF with the remote for the simplest use cases, I just pointed out that regular technic builders might not know about the existence of some PU components, and that expectations are higher for PU, nobody wants to go back to bang-bang control. It was introduced in 9398, and also used in 41999, and also in 42030. Of course I also do that, but that's the situation we'd like to improve. Not sure about PU app, but I meant the 3rd party apps that support a gamepad controller. For example none of them can do proper speed servo control of the PU motors (only PWM control and rotation servo).

Then I cannot mount them with half pins :) Btw, they don't exist in dark blue, but they are used in black anyway :)

That's a cool video :)

But you asked for the explanation between the two. In case of PF technic sets, the remote was part of the sets, hence people got used to it. In case of PU, it is not. And I know there never had been proportional joysticks, that's why we would like them. And the phone control shows people that motors are possible to control proportionally, that is why they expect it. I have been using it for long of course. But having a phone in between is a problem. For example, I cannot take a video of the model I'm controlling using the same phone (before you ask how I would do that, I mount the phone onto the controller). Also, the phone apps need maintenance, and all existing apps lack proper support for all motors. It does not need a name, it's enough to assign a number to it, and the current config could be selected with the number of presses on the start config button (and could be acknowledged with the number of blinks of the light that you are editing the one you want). Not super user friendly, but much better than nothing. Both the PS5 and the Xbox Series controllers are BLE capable. It should be doable, only FW support is required. Exactly. It can almost be done with Pybricks, it is probably just lacking some parts of FW support to open up some generic Bluetooth connection capabilities, the same way it connects to the PU remote (I looked into the FW code and discussed this with the Pybricks guys). I am trying to convince them to work on it, at least the core Bluetooth code so that I could pick it up and work on interpreting the gamepad signals. I believe if that could be done, I could implement the above described config protocol in a Pybricks program, similar to Remote Bla Bla (since the gamepads have enough buttons that could be used for config purposes). If you guys support the idea, please help me push the Pybricks guys to put more effort into this (for example in the Pybricks thread)!

No, as you see, the hinge piece itself is at the bottom plate, that is why it's required. I tried with different hinges as well, but I have limited inventory for that, and others weren't even looking good in virtual build.. But I don't think the seats are a problem for lowering, I tried and it looked manageable. It is a 5.5L axle under the joiner, not possible to make that 1 stud shorter. Otherwise I could obviously do it :) The more problematic part is the horizontal placement of the HoG axle if I move the roof.. That is also non-trivial as these are thin liftarms with pinholes at the ends in the front, and there is no 4L version of that. Besides, that would be too short. I am experimenting with the angling of it though..

I guess the difference is that if you are a Technic builder, you don't get to see that remote controller and that hub. It's for trains mainly. When you are a Technic builder, you only see a huge Technic hub and phone control. Even if people were aware of the remote controller, it would not cut it, as the expectations for PU are higher than it was for PF. We expect proportional control with joysticks at least. I want to bring attention to the problems with the Technic hub (and touch on the size of the motors as well) when building / designing space constrained technic models such as RC cars. I remembered this after building the Audi and having a detailed look at its structure and strengths and weaknesses. The Audi is a medium sized vehicle (about 1:10 scale), many smaller ones have been built in Technic, yet it is visible that they struggled with the placement of the electronics as it takes the interior of the car, leaving not much room for seats, yet (as a result) much of the inside feels empty and unfinished at the same time. It all starts with the hub. Where to put it? It is huge, so even in such a large model, there is not much possibility. If that was not enough, it needs to satisfy other constraints as well; you need to be able to reach the turn-on button, on the top, and you need to access the batteries at the bottom (even worse, the screws with a screwdriver, that's crazy) so you can't actually bury it somewhere in the model (like it could have been buried in the back of the Audi where it has ton of space). So the only practical possibility they were left with is the middle of the cockpit, the battery cover facing down. Now that brings in other problems. If the hub blocks the middle of the car, then there is no way for example to route all-wheel drive through the chassis (either with single or two coupled motors), so the only way to do it is splitting the two motors to front and rear, which in itself can even be useful for splitting torque, but it is only making the space issue even worse, as you can't put the two motors side by side. And all this forces the steering motor high into the cockpit as well, so all these together block the space from building the interior of the car, which just feels lame. Also, as a consequence, the steering system needs to have a gear mesh inserted, which reduces responsiveness and precision (though with touch control, you would not notice the difference anyway), but also makes it harder to center the steering, as now the center position of the servo does not result in centered steering due to the gear mesh. That's a bunch of compromises because of suboptimal electronics components, mainly the large hub in this case, but a smaller servo could also have helped. Imagine how hard it is to build a 1:12 scale car, which would be better suited for the power of lego electronics.. Also, rechargeable hub could help, as then it would be possible to charge it inside the model without needing to take out either the batteries or the whole hub (not to mention the screws), and that would allow for better placement of electronics, more space in the model, etc..

There's like 1 - 1.5 studs space above the chassis floor. There you go. They cannot be, they are sitting on the floor as you see. But that's not a problem I think, they are high in the original one as well, which does not even have complete seats :) because of the electronics, but I wanted to build the interior more proper here without electronics. Which one do you mean? In the HoG? It's intentionally there to be able to pull out the HoG without removing the axle that goes to the gear..

I also built mine yesterday and noticed something similar, though I wasn't surprised. It is because the steering system's construction, not your fault. The servo does not go directly to the gear rack, but has a 16T gear mesh in between. In such a gear mesh, it is impossible that both axles are at a proper 90 angle. Since the servo axle is at a proper 90 degree angle by default, the axle going to the gear rack will not be, hence the slight offset. I also expected that the calibration might make up for it, but I think the difference is so small that it is difficult to get it completely centered. What I did actually is I set up BC2 with a gamepad controller. It resulted in the same offset after calibration, but there I can give it a center offset manually. Setting 10 degree offset fixed it quite straight :) About the build itself. The structure is super solid, I love the use of all the flip-flop beams, they are a real game changer for building form locked structures. The suspension is also really neat structurally and works really well. The rear's travel is more limited and a bit more stiff to bear the weight of the electronics which is a bit more towards the back. But really nice and bouncy. The shaping also has some nice building techniques for angling the panels (and many nice panels). Without stickers the looks is not that special though, but with adding some red parts here and there it could really be a cool looking one, though not true to the original. Also some things I don't quite like. First, I am not a big fan of the electronics placement, but I get that with these clumsy electronics, it's hard to do it better (though I expected that there would be enough place to put the hub in the back). The hub takes up a lot of real estate in the middle, and also pushes the motors into the cockpit, so the interior is obscured on one hand with the motors and cables, and empty and feels unfinished on the other hand. Also, it's big, and has a bit of empty shell feeling, not just the middle, but the back and the sides as well have some hollow structures covered up in panels. But altogether it is a really nice set, good amount of great new parts and electronics for the price. The speed is quite okay as well, drives nice, though still only tested indoors as it is raining all the time..

I like the way it's designed structurally, don't know how authentic it is but it looks good :)

Thanks, indeed, I got around building it in real life :) It's looking pretty cool! I found a virtual model of the set and managed to import it to Studio. Then, I generated a proper side view render of it and added that into Studio as a reference image for precise comparison for scaling. So the fiddling with the small details can start.. First off, I realized that the wheel base is short by one full stud. I managed to quickly fix it by shifting both axles with half a stud to the front / back (the suspension links and the drive shaft was easy, the steering links and the panhard rods are angled a bit to bridge the half stud gap). The build above is already with the shifted version. However, I noticed a few other inaccuracies when comparing; the whole body would be better off if shifted forward half a stud (without moving the fenders), furthermore the fenders are sitting half a stud too low. Also, the cab is about half a stud too tall. As both the axles and the body need half a stud shift, the two can actually cancel each other and the whole thing can be rebuilt and simplified (getting rid of the half stud offsets). Furthermore, the fenders are also already sitting in a half stud vertical offset (but half a stud too low), so that could also be raised by half a stud by getting rid of the offset (and also the slight slope that it has currently due to the way it is fixed). So I redesigned the whole chassis in a way that places the axles on full stud boundaries and at the same time shifts the body forward half a stud, and managed to raise the fenders half a stud by mounting them differently (and straight), which also required some changes in the body. I'll still need to rebuild it to this one some time later. I haven't yet found a way to lower the top while also keeping the hole position of the HoG steering on the stud grid..

It’s not fragile, I bought like 10 of them, pretty useful..

Hmm, I have no idea, I never tried this, but I'm afraid that it could skip easily when the wheel is stuck and it's hard to turn it.

I definitely think they will reuse those wheels in some of the space sets.

There's already a dedicated thread for Pybricks, as the question of @kolbjha was specifically for that, so indeed it's better to post questions like this in that thread.

I realized that it is possible to add a differential to the axle while increasing the width of it by only half a stud on both sides, which is still acceptable! So I went on and redesigned the whole axle to include a differential, and it has been a really good exercise because many things became better / more true to the original. First of all, the redesigned portal part now holds the wheels more firm, because it is also supported from the bottom. Scrub radius is also improved as the pivot point is moved out by half a stud. As the differential takes up a lot of space the axle became much more bulky, but that's a good thing because it resembles the original better :) Also, due to space constraints, the suspension geometry had to be redesigned to a single pivot version (with a slight negative caster at the front), which also makes it just like the original, along with the driveshaft which now enters the axle at a higher point and routed down, again just as in the original. Finally, the spring attachments needed to be redesigned to have two degrees of freedom, as it is required when the axle has caster. Here is the new axle: Because the mounting point of the springs needed to be changed on the chassis end as well, it got too close to the fake engine. I wasn't completely satisfied with the flatter engine anyway because the more I tested it the more I realized that it's not as good as I thought, as @Saruzeufel noted, it skips easily. So I decided to go back to the classic 90 degrees version, and I managed to move it backward a few studs and this way it seems to fit under the hood (where it sits a bit higher). Here is the chassis with the new axles and the new engine. I also started designing the interior and added some simple seats. Here is the complete model in its current status. Changing the suspension geometry and spring mounting point lowered the model by something between a quarter and a half stud. I think it still sits okay. Now all the parts I ordered have arrived so it is time to build it completely.. :)

The fenders definitely look better, but I am not sure about the angled grille, the straight one looked cleaner for me and the front bumper is now too far out.

I think that's still not quite okay, maybe it will bend and stress the A-arm, and it may even pop apart easily. And yeah, working with that hub and the limited length of gear racks and links sucks..

Well originally I proposed 4 buttons for config, that's not that much. Since then I realised that direction swapping is already taken care of by the remote via rotatable button groups, so that's one config button less. So the 3 buttons needed would be: - initiate/finish mapping a port to a controller button/joystick - port selection - mode selection + configuration sequence would make use of the actual control buttons / joysticks for control selection The config sequence for a single mapping would be - initiate mapping - select port (number of presses) - select a joystick / button by pressing / moving it - select mode (number of presses) - this step could be optional, default mode would be using the port as a regular DC motor output - finish mapping (same button as initiate) You'd have to config each port/joystick mapping separately. An existing mapping would be edited, otherwise a new one would be added. A long press on the initiate button would clear all mappings. This would be enough for simple config, but for more detailed config (such as setting max speed / max servo angle, etc), you could still have the app. I was actually wondering if this would be doable with the existing remote, as it does have 3 spare buttons (the green one and the two red ones)..? Though the green one probably cannot be used for much as it turns the remote on/off.

If you already see that shaft falling out, then it will definitely fall out under torque. It's actually worse than that :) What can also happen is that the axle slides into the sliding shaft and out of the U-joint on the chassis end given that it has enough play. That's what happened with my model. I could not imagine it could fall out, but under torque the axle twisted enough to allow things to be pushed apart (though that happened with 2 Buwizz motors). Also one problem I see on the image is the negative caster angle of the axle. That is making the CV joint break more and get more elevated, which pulls the shaft apart. Changing that to have zeros caster could also help.

I don't think that would because the steering link has only one degree of freedom instead of the required two (it cannot turn horizontally). Even if it would, the steering link would be shorter than the suspension link, which would cause toe in/out. You should try to use a proper 6L link there, which would require redesigning the steering mechanism.

Configuration is when you connect things up in a simple GUI, like in the Buwizz/BrickController apps, basically connecting which joystick controls which port, and what are some parameters, like motor mode and max speed. Programming is when you write arbitrary math formulas that calculates the outputs (motor speeds), given the inputs (such as motor positions and joystick position). It's the coding canvas in the Powered Up / Mindstorms apps. And I agree that the first is significantly easier to grasp for the average lego user. Also agree that a CC+ would jack up set prices significantly. As I suggested, the simplest alternative I can imagine is a lego remote like the current PU remote, but - has two proportional joysticks - has some more buttons (maybe two on the top as gamepad controllers have), some may be dedicated for configuration (for example 3 buttons in the middle) as I explained above. I really like the direction swap feature of the remote, that is neat. Two remotes could even be combined into a larger one, that should be enough for many things. Actually the configuration protocol I suggested above stems from the Remote BlaBla idea of @vascolp. Only that with more/dedicated buttons available on the remote, a less awkward / more intuitive configuration sequence could be possible.

Interesting info, thanks!

After ordering missing parts (like tires) I finally started building the whole model in real life, got done with the chassis. It required adding some Panhard rods to fix the axles' sideways movement, and then I started pushing it around a bit as a test just be completely surprised that if I try to steer, the axles bind completely and the model won't move. Just to make sure, I disengaged the whole drivetrain, just left in the connection between the left and right wheels in both axles, and it still binds. So I am guessing this is because - the axles don't have differentials, and - it has a big scrub radius due to the portals, and - it has all wheel steering and a resulting small turning radius All these factors together build up so much difference between the left and right wheels' rotation rate that they simply cannot rotate together (and the tires also have enough grip so that they don't slip). I guess I'll have to redesign the axles to add differentials, which is a problem because leaving them out was what made the portal setup possible in the first place (otherwise the axles would get too wide). So I either let the portal setup go (which is a key feature of the original) or make the axles wider.. :( I also thought about splitting the drive axles in half and only drive one wheel, but that feels like cheating..