gyenesvi

Interesting drivetrain and form factor, even though the wheels feel a bit out of proportion. Could the whole body be lifted a few studs maybe? Then it could have more ground clearance in the middle and at the front/rear bumpers, and the wheels would also not feel so huge? It would be good to see how this drivetrain can cope with more bumpy roads and some uphills.

Wow! Now that is one (or two) epic alternate model! Great functionality and great looks, I love the color consistency you achieved, the way you used all the bit messy color scheme of the original and turned it into two separate models, it's as if all the parts were meant for two models :) Even really well working claws without special parts! Congrats!

Thanks for the reference and some more detailed explanation! There's quite a lot of stuff to be absorbed related to this..

Thanks for the video, it has pretty good performance, interesting how well it climbs with that one XL motor! The chassis flex also shows nicely here, and I guess with the grey shocks mounted symmetrically the axles also tilt more smoothly than originally. It was nice to see all the improvements you made!

That's an interesting and funny beast. Would be nice to see the mechanism (construction of the legs) in close up / slow motion though, to see how it was implemented in lego form (I have seen the Strandbeest in non-lego form already), to see those limitations that you are talking about. For example I don't understand why it needs so many legs, and why it needs to be so fast. Maybe without those features it could be built in pure lego form?

That is a great idea, both the part itself and also the way you built it! I like the modularity. I was just designing something the other day, where an L shaped flip-flop like this in 3x5 size would have been the perfect part to fit and make things compact and strong. I have seen this contest but did not enter when I realized that you need to actually build the wishbrick from existing parts instead of designing them for example in Studio part designer or a CAD software. Also, it would be awesome to have a contest like this by TLG, where a few of the winners would actually become produced parts instead of winning some sets. That, I would enter for sure! :)

I also found something in the Buwizz 3 protocol that may be related to this issue. There is a command to set a connection watchdog, a timeout value. The documentation says: "If timer expires, the device drops the connection and uses the parameters of the ... command for the stop." And the options for stopping are: braking motors, coasting them, or coasting them to stop in N seconds. Maybe this means the following: if the connection drops (for example because of running out of range) for a certain time, then this stopping mechanism kicks in. I guess that would work, no? I have not yet seen a setting for this in the app though.

Just found an interesting bit about the Buwizz protocols. The Buwizz 2 protocol has a command to set current limits for each port. The documentation says: "If the motor current is above the current limit, the PWM duty cycle of the affected motor is reduced until the current falls below the limit. PWM duty cycle will increase if the motor load is reduced." The Buwizz 3 protocol has no such command. But I guess the same could be added. Wonder why it was removed in the first place though..

I think the point was not that it is a firmware issue, but rather that it could potentially be solved in the firmware. And according to my understanding from talking to them at the camp, this is what they aim to try; to slow down the motors when the firmware predicts that a peak in the current is coming. Probably the prediction part is non-trivial; it needs to predict the peak, because if it actually sees the peak then it may already be too late. And if it's too cautious, it may slow down too early and not use the full potential of the motor. I do believe that certain situations can be prevented with optional firmware settings, for example the firmware does have a ramp up/down time setting already, and some reasonable non-zero value could be default. That may be useful to prevent sudden direction changes (though BrickController2 and ControlZ apps don't not have such an option to set, and when I experimented with it in the Buwizz app, it behaved a bit strange, was hard to set a usably low ramp time). But I guess it is not a solution for all situations. For example, I have seen models that can go full speed fine on a flat surface, but when they hit an uphill (and start to get slower naturally, so no sudden speed change), the Buwizz shuts down.

Not sure what you are trying to achieve here, or if you understand the system correctly, but the BuWizz unit communicates with Bluetooth instead of IR (controlled from a mobile app), and the receiver is included in the brick, so the system does not need an IR receiver or IR controller. The brick has 4 output ports which can be controlled independently, and you could stack multiple outputs onto one port to control things simultaneously. So it does not mix well with the PF IR system, if you'd put some of your motors on a PF battery, and the rest on a Buwizz, then how do you control them? Half from a PF controller, and half from a mobile phone? Furthermore, things are not so simple with Buwizz motors, as they draw a lot of current. A Buwizz 3 battery can drive 2 Buwizz motors from 2 separate ports (even that cuts down occasionally), but I believe a Buwizz 2 battery cannot even drive 2 Buwizz motors safely, or it will cut down even more frequently, depending on how hard you push the model. So for 4 Buwizz motors, 2 Buwizz 3 units are recommended. Which one did you buy? The image above suggests you have a Buwizz 2.. For PF motors, it could be fine though, those are less demanding, it could drive maybe even 4 L motors, though I have never tried.

About all those car sets: I am not so much into them in their current form, but I do acknowledge that they sell, so it makes sense from a business standpoint. What I was wondering if the lineup could actually be more technic-like while still having a similar appeal for buyers. I believe that there is kind of a missed opportunity here, because Lego focuses on sports cars mainly, with only minimal focus on off-roaders (we might get a decent one every 1-2 years and some smaller ones every year). I believe putting more emphasis on licensed off-roader passenger cars could be beneficial for multiple reasons: - People do like real-world off-roader passenger cars or even pickups, not sure if as much as sports cars, but still a lot I'd say. They're kind of manly. Off-roader category seems to be the most popular one in RC races as well, with many such entries, as there's a lot of challenge in it. What do you think? - Off-roaders present opportunities for much more technical stuff than sports cars. They often need more sophisticated suspensions, an area in which technic is lacking and could improve a lot with new parts (joints, links, leaf springs etc in various sizes), and drivetrains, such as diff locking, RWD/FWD/AWD switching, or a simple hi/lo gearbox that has a meaningful gear ratio (at least 2x), just to mention a few that are complicated or not possible to build today. So I believe such licensed, real-world off-roader cars would kind of combine the pros of both ends: appeal to people, and opportunities for technicalities. I'd love to see a lineup of 1:10 scale classic off-roaders (similar idea to the lineup of 1:8 sports cars, brands like Jeeps, Land Rovers, Toyotas, etc). I do think that it would sell, and could actually contain many technicalities that satisfy us as well. I could even imagine a lineup of mid-scale off-roaders, as those are really popular as MOCs (something like 60-70 mm wheels and 15-stud-wide bodies). Even the shapes of off-roaders are typically better fits for technic paneling than crazy shaped sports cars. I don't understand why this category or cars does not have more representatives, just 1-2 every year. Any ideas? I guess the Land Rover and the Ford Raptor would count as good examples here (maybe the Jeep for the smaller scale), but those are also lacking on the technical side, as they did not introduce anything fundamentally new. But the Land Rover is immensely popular.

I love the idea, indeed, the colour scheme and the parts are quite good for it, even the whole suspension concept has a similar vibe! Nice job!

This looks pretty nice, and it's soo dense with functions using all those small LAs, great job! I like how it only has essential stuff in it, just the right size. Especially like the tilting of the front wheels, the steering shaft (though that chain touching the frame is a bit of a dirty hack for me). The rear drivetrain is also nice, I guess in such a manual model, even those 8T gear trains are okay. The only thing I'd change is that stair-like stack of beams on the side of the rear part under the bonnet, wouldn't some wing-shaped panel fit there nicely? It could make it look smoother.

I really have to agree with this point. This is really frustrating for many users, and it's a fundamental problem because it effects all other apps that try to control the Buwizz units. Sure us MOCers could say that it's not our fault but that of the Buwizz unit, but that would be lame, and our models would still possibly not work well in the hands of MOC buyers. I did fear / think about this as well and hope this is not the case. It seems that there's a third possibility though, and I have already written it down in this thread. In the Buwizz camp I asked about this, and I was told that they outsourced the writing of the firmware and they are having a hard time getting it fixed by the company they work with. Not sure about the underlying reason though, whether it's just too complicated, or it's a communication issue or what. But let's hope it eventually gets solved over time. It would really be reassuring to know about how this issue evolves to understand whether there's a fundamental HW issue or not. Something of a remedy for the meantime: I realised that using a physical controller reduces the probability of shutdowns, because it's easier to smoothly ramp up the speed (shutdown often happens at sudden speed / direction changes). Non-linear power curves also help (logarithmic seems to work for me in BrickController).

Thanks, it is, I suspected something like that. I do like the drivetrain, I just wish the XL motor would be stronger so that such single motor builds could actually be useful for models of this size. I actually have a smaller car in the making with a single XL motor and planetary hubs, I wonder how well it will drive on some rocks. On the other hand, I do see some points in the axles that may be problematic. For one, the steering geometry seems to be anti-ackermann, because the steering rack connects to the hub 1 stud outer than the pivot point of the portals. Also, the connection between the ball-joint's U-frame and the O-Frame of the axle seems to be weak, as far as I can tell the liftarms that connect them on the side can only go until the first pin-hole of the O-frame (on the rear axle at least), so that does not fix it against rotation, and though it is fixed by some other means, that probably isn't too rigid either. Connecting the ball joint and the frame is a typical difficulty when using those ball-joints I guess. On the back, don't the motors limit the articulation of the rear axle? It may only be an optical illusion, there may be more space under the motors which is not so visible from this angle, and I know in reality the axle is angled a little bit downwards, while on the render it is still horizontal, so that may be misleading for now. The springs are mounted a bit far from the center of the axle (longitudionally), which could also mean more friction if the axle itself is not very stable against forward rotation. Did you try placing them at the center of the axle? It seems possible though it does require raising the springs.

I see. Oh that's a pity :(

Sure, I see. That's a very cool property I did not know about (thanks for the references), great that you replicated it! Would be interested to see how it works if you ever make a video of it :) I guess we should see the cab tilting relative to the bed if I get it right. BTW, is there a reason why you didn't use 11x3 and 7x3 panels for the side of the bed? Seems like a perfect fit for an even cleaner look!

So that's a total of 8.3x difference between the two gears? That's massive! It looked like a simple 1.666x gearbox :) So there's more gearing inside there apparently.. Did you try it with the soft LBG springs? Though I actually thought is could work with the hard ones as well as the springs are placed halfway on the axle. But maybe that bending does really hinder it from articulating properly. By that do you mean the flex that simply comes from the beam structure, or is there some trickery in the way it is built to let it articulate? Does the Unimog frame have some special structure to facilitate this (I'd be interested if so)?

Indeed it looks quite clean, I like the hood and the building technique for the front grille! The gearbox/motors placement is nice, though I agree that one PU XL motor will not be very competitive (it's significantly weaker than the PF XL). Maybe, putting 2 L motors side-by-side where the current two motors are is a possibility, which then would require moving the gearbox L motor to the front side of the gearbox, where the engine is now.. Also, I like the simplicity of the suspension using the ball joints, without creating a negative caster at the front (this is the only acceptable usage of it for me at the front). The only thing I don't quite like is that as far as I can see, the springs are limited in their tilting forwards/backwards (can only tilt freely sideways). So it cannot follow the inclination of the axle, it must bend a bit, which creates some friction and so it's not going to be articulating as smoothly as it could be.

I did think about that possibility, but I ruled it out because as @Plumber says, their directions would not be the same. But there's another problem too, the gear ratio would also not be the same as with the regular usage of the diff, so it cannot really be taken as a locked version of it. Yeah, I was looking for a solution like these (I have been using the same locked versions), but I don't think such a way of building a locked version exists for this newest diff.

Can you elaborate on that first impression? Just the looks / quality of material, or have you also tried it? For example, how precise is the servo? Is there a receiver integrated into the battery unit? Or does it need some other component to work with a controller?

That's a pretty interesting setup for the rear axles! Do I understand vorrectly that the 11L liftarms on the sides are pivoting around the central gear, and the center of the assembly where the CV joints join in are stationary? I like how the wheels on the same side are coupled by gears, they don't really need separate speeds and one diff for the four rear wheels is enough. The frame is also looking okay so far in terms of dimensions!

Not using Windows, but I managed to open it and view it, thanks :) I actually like the idea of a non-integrated CV joint as well..

This looks cool, indeed a hub like that would be really welcome (even without the ball bearing). It would be good to have more pictures of the inside of it. Did you just put a regular new CV joint through it (both female and male part)?

Indeed, your prints seem to be the best quality out there that I've seen so far! That U-joint is a really handy part, I have just been wondering recently how good it would be if something like it existed.. Pity I haven't seen this before, I'd have a few ideas :) For example, the male part of the new CV joint with an axle instead of an axle hole. I believe it's not possible to make it with 2L axle, as the U-joint you did, because the ball needs a 1.5L space to articulate properly, but it would still be useful with a 1.5L axle. For example, it could be used to make a 5L double CV joint (currently 6L is the shortest possible), or a 7L sliding version coupled with the 5L sliding male part. Here are a bunch of renders of my custom part designs in Studio Part Designer, that include some connectors for mounting the planetary hub into smaller builds, thin L-shaped liftarms/frames, etc that I find would be really useful general parts. https://bricksafe.com/pages/gyenesvi/custom-parts Wonder if you find some of them printable. My latest idea was to see if the existing portal hub could be enhanced in terms of steering pivot. I believe a redesign like this would be possible (with smoother joining of curves), retaining much of the flexibility of the existing one, but allowing it to fit into deeper rims (like that of the Land Rover), and moving the pivot point of the U-joint 2 studs closer to the wheel (it would also require a narrower inner rotating piece that holds the wheel with 3 pins). I guess this is far from being easily printable :)