gyenesvi

Interesting idea.. do you mean replacing the FW on an existing product just like for the lego hub, or team up with the providers to create the FW to be compatible from the start? Back to existing controllers. Wikipedia says that the latest Xbox Series controllers (since 2020) do support BLE: https://en.wikipedia.org/wiki/Xbox_Wireless_Controller#Third_revision_(2020) They seem to be fairly accessible out there, I have bought one second hand for $40 just for controlling lego models (through phone for now). The latest PlayStation 5 controllers also support Bluetooth 5.1, which includes BLE according to my understanding: https://en.wikipedia.org/wiki/DualShock#DualSense Have you looked into these ones? If only these major ones were supported that would already be a big step forward. Would it be possible to build up a bluetooth connection to these using Pybricks FW on all hubs? I know that decoding their communication protocol is another thing.. Does that seem like a possible way (I really cannot judge), or would these also require replacing the firmware (if a BLE connection is possible)? Another thing I wanted to ask as it's not clear to me. Can Pybricks be controlled from a phone like the original lego FW can? Or is it just for running programs on it directly?

Oh that's a bummer. I am guessing then that's true for Xbox controllers too, do they use Bluetooth classic as well? I did know that the Spike/Mindstorms hubs have that, I did not know they also support BLE, thanks. I guess then that's why the Mindstorms app supports Xbox controllers. Or is that making the connection through the computer/phone as well? BTW, is Bluetooth classic limited to one connection? Do you mean manufacture? :) I guess that's what many people here are dreaming about.. but still not enough to make it a product that sells well I guess.. We are just a few hundred enthusiasts, maybe a thousand.

I suggest adding a more detailed description to your post, because at first, I did not really realize what this is all about, I was like, "okay, he put a camera on a car using a crane arm, nothing special, but why do you need 8880 for that?", and I was completely missing that it actually acts like a gimbal, stabilizing the camera through the use of pivot points and rubber bands. It's one thing that it's more detailed on Rebrickable, but if someone is not interested after reading your short description on here, he won't follow the link to Rebrickable, and miss the essence. Now that I understand the core idea, it makes more sense to put it on a full suspension chassis, since that also acts as a stabilizer :) Cool idea! I'd even change the title again to reflect that it is a gimbal, as that's the novelty :)

Just to clarify, I meant that the (profile) data becomes part of the FW program, which is available already, not only in the next beta. I do understand however that that does not allow configuration without re-flashing the hub. The external WYSIWYG config would have the advantage that only play mode would be required to be flashed onto the hub. I think it would be simpler to have a configurator from the web browser than a mobile app, then it would not be tied to any kind of platform/os, would work for anyone. And then we could avoid the usage of the smartphone.. instead just use a computer.. Is that a meaningful move? :) But that needs to be learned as well, and I don't know such stuff either..

Wow, I am blown by these creator sets, now that I looked up their building instructions! I knew about the blue pickup, but not the yellow one. They look pretty cool and have nice functionality for the theme! I believe even steering might be possible for the yellow pickup's independent suspension with today's parts. But the live axle is a better fit for the classic defender. So we have hope! :) Such a set would be instant buy for me. Though truth is, even without suspension I'd probably buy it :D but an offroader in expert style would be strange without some sort of suspension. I really hope the expert theme will draw in more technic elements for simple functionality, and since they are smaller builds, they have the potential of evolving critical parts (like suspension parts) for tight builds, which would be really useful.

I have been wondering whether it would theoretically be possible to connect a hub running Pybricks with a bluetooth gamepad controller; I mean building up the bluetooth connection, and reading the button presses, hidden behind a python interface, just like for the lego remote. I am guessing this would need to be part of the FW. Do you @Pybricks guys see any theoretical obstacle for making that possible? Is there something special about the lego remote as a bluetooth device that is relied upon by the FW that enables it to build up the connection between the two? If that would be possible, it would open the door for using a gamepad controller to control the hub directly without an intermediary phone, much like the RemoteBlaBla wouldn't it?

I have been reading yet another discussion about supporting gamepad controllers in the 2023 sets thread, when I understood something important about this whole system; namely that it is possible to connect the hub and the (lego) remote without an intermediary phone, at least using Pybricks. I am guessing the same is true for the original FW as well, otherwise the existence of the remote would not make much sense. I have been wondering whether making a similar bluetooth connection would be possible to implement for a gamepad controller as well, at least with Pybricks, or if there's something special about the lego remote (such as a special id) that makes it possible? Maybe this should be a question addressed to @Pybricks. Also, I have now looked more thoroughly into how this whole system is implemented. I understand that the hub cannot store data, hence the profile is encoded in the name of the controller (nice trick). I was wondering if it would actually be possible to encode the profile on the hub. Theoretically, the FW and the python program you bake into it could store the profile. If it was just a single-purpose (non-configurable) program, then the program itself would be the profile data. To keep the configurability, I was wondering if it would be possible to kind of put the encoded profile string into the program, and then bake it onto the hub. It would have the disadvantage that it would require re-baking the FW when the profile is changed, but as I understand that's a quick and easy process. The overall program would remain the same, only a string in its beginning would need to be changed every time. Furthermore, then it would have the advantage that the string could also be generated offline, with a WYSIWYG interface, for example in the browser. Adding to this the maybe possible ability to connect to a gamepad, we could finally have complexly configurable, proportional control, that only needs a computer for the config phase (which could in some cases be as simple as downloading predefined/shared profiles).

68.7mm tyres would be an awesome scale for a classic Defender, that scale and tyre is one of my favorites, and it would make it possible to keep its creator shell and replace its chassis with a proper technic one with suspension, either motorized or manual. However, I'm afraid that in line with previous creator cars, it will rather have 49.5mm tyres, which is a significantly smaller scale with less space on the inside unfortunately (so no suspension whatsoever, maybe working steering wheel). Just imagine, 68.7mm tyres is already close to the scale of the technic defender on 80mm tyres, which would be quite large for an official system build.

This video made my day :)))) I haven't heard the intro music of my childhood TV programme in about 30 years :) And I have not seen this episode about lego motors back then! Thanks for sharing!

That's interesting, wonder if it would be possible to buy them alone somewhere..? Maybe it will appear on AliExpress..

Okay, true, I meant with the PU hub :) Actually I was also using the Phondly LiPo battery insert to the PU hub, which is 9V output, so it was already more powerful than typical 6x 1.2V rechargeable batteries.. And for Buwizz, you can still use power curves (also with BrickController, max power), which has the same effect as voltage mode - it is possible to dial it back.

Don't open that door!!! That's a deep rabbit hole :D Fortunately, I think it's not needed for most use cases..

Haha, it is disassembled already, but I kind of foresaw this request and I made some photos of it during disassembly, hope it shows the key ideas :) One more thing I remembered I wanted to note about the front axle. After some intensive driving, I noticed that the U-joints' end entering the portal hub did rub against the big O-hole of the hub and generated some plastic powder. I have not seen that occur before even during intensive driving, and the two parts are designed to be used exactly that way (the U-joint going into the O-hole), so I was wondering how the U-joints could rub the hole. I suspect that it may be because the other end of the U-joint's axle, the one that is coming from the diff, is not supported right next to the U-joint, but only 1 stud further inwards, so the U-joint has more room to wiggle a bit as it is driven, and that may result in the rubbing. Nothing serious though, just a good reason to try to brace every moving part as much as possible to minimize friction and wear. In this particular case however, I did not see an easy way of improving the bracing.

Hey, just a final remark before I dismantle this model, I had some time to go out and test it more thoroughly off-road. Indeed, the 3L steering arm was a bit too weak. However, I managed to rebuild it to 2,5L (using the set's parts only, with the cams on the steering motor, the motor itself moved backwards one stud as I wrote above and the steering arm on the wheel hubs also decreased by half stud) and that worked out better, had no problem manoeuvring. Actually the overall off-road performance was surprisingly good, it climbs well over rocks, it has plenty of ground clearance and articulation. With locked rear diff even good enough traction. I had fun with it :) Posted some photos on Rebrickable. Thanks!

Looks pretty good in yellow, and has good proportions and functions. Only, I was wondering if it would be possible to move the LAs one stud forward to be less close to the wheels. I guess it would decreas the bed elevation a bit though..

I haven't tried setting those yet, but to a 0 value to make sure that is not what is causing the delay. However, that seems to be faulty in the Buwizz app as well, maybe because of this very issue, though not sure how acceleration profiles are actually implemented. Well I don't know either, but it may actually simplify the firmware. I mean it doesn't need to queue all the commands, only keep the last one and keep overriding it. That's actually simpler.. By the way, I just sent this issue again to the Buwizz team, let's see if I get a reply this time.

Did you manage to come up with something about this issue? In the main Buwizz thread I have just described an issue I observed with my own experimental program to control the Buwizz, and I think it may have the same underlying reason in your app as well; it may be a firmware issue. Also, as I describe it in detail there, it may help you reproduce the issue (basically it needs slow ramp-up of the speed with the slider to manifest itself). Let me know what you think!

Well, I would not be surprised. As I am experimenting with it, I think I have discovered some sort of a bug or issue with the firmware. What happens is that as I am sending control commands to the unit, for example to set the motor speed according to the position of an on-screen slider, the Buwizz unit is too slow processing those commands and there can be significant delays in it responding. If I am moving a slider slowly, and sending commands whenever the slider position changes under my finger, it seems to overwhelm the firmware. If I keep moving the slider up and down slowly for say 2 seconds, and check how the motor responds, it may take it to process all the commands maybe 5-6 seconds. That's an amazing amount of delay! It only shows with slow slider movement however, probably that is why it is not manifesting itself all the time under regular use. If I move the slider quickly, it does not result in a lot of commands being sent, and hence the problem is not visible. This happens in generic PWM mode, and also in speed servo mode. The docs says that the PID controller of the servo runs at 100 Hz, which I interpret as it should be capable of processing messages sent with 10ms intervals. However, even if I wait 10ms after sending each command, the result is still not perfect, although somewhat better. If I add more delay, say 50ms, then that becomes the problem itself. By the way, the Buwizz 2 seems to be less prone to this happening. The reason I believe this is actually a bug, and it's not just me doing something wrong is that I observed the same behavior in other apps as well. For example Controlz has an acceleration issue (progressive acceleration in the app results in a lot of delay in the actual model), which I have reported before, and I think is because of the same underlying issue. The BrickController app is less prone to this, because as I have seen it in it's code on GitHub, it applies a 10ms delay in the sending of subsequent messages, and also with a small physical joystick it is harder to make really slow acceleration (harder than with a larger on-screen slider). Furthermore, the Buwizz app itself also has a problem when setting ramp-up times, for example if you set it to 1 sec, the actual speed-up will be much longer (like 3-4 secs). I believe it is the same issue underneath. As a reference, I have tested the same motors with the 4-port Technic Hub, and that one can quickly and smoothly control the motors, following the movement of the slider without practically any delay, so it does not seem to be a HW issue. From the Lego Wireless Protocol, I know that the way the lego firmware works is that while it is processing a motor command, if it receives multiple subsequent ones in the meantime, it only keeps and executes the last one, as that would override the the previous ones anyway. This way it does not process all the useless commands unnecessarily. I believe this is what the Buwizz firmware fails to incorporate, and the delay comes from processing many obsolete commands. I have sent a message about this (and a few other issues) to Buwizz about 3-4 weeks ago, but did not receive any reply. I am hoping that others who have experience with Buwizz app development, like @imurvai and @_Ozzee_ can chime in to tell about their experience regarding this issue, and confirm or deny my theory. It is already frustrating for smooth speed control, but imagine how much inaccuracy this can cause in steering servo control for example! I believe this should also be top priority to fix.

I like this, the simplicity of the chassis and the suspension, really cool small scale stuff. Maybe it could use a some panels on the body to avoid too much beam stacking. Can you maybe show more details of the front axle, how the steering and drive is solved in such a small space? It looks slick. Is the steering going to the axle through double cardans from the servo motor?

I would very much love this to happen, though I think its quite unlikely. I guess there were a couple of reasons why they did the new Defender, although I'd guess most people would have loved a classic one more. One reason is that I guess Land Rover wanted to advertise the new Defender (that's the downside of a licensed model). Second, I think there were technical reasons as well, for example related to the suspension; Lego is being cheap (in the bad sense) and going for easy solutions; the new model has independent suspension, which is much easier to do than a proper live axle in such a scale, as it needs a lot of space with current parts (both the axles themselves, and the drivetrain going into them). I'd love to see classic offroaders that improve the parts palette with ones that enable building compact live axles, which is very much a weak spot of technic (just look at those huge Zetros axles). And that includes wheel hubs with the new joints as you say (along with new variants of the joint itself maybe, such as a female part with 2L axle), and also suspension links in various lengths, and parts for a linkage based steering system. Instead of the overcomplicated gearbox, I'd be happier with a simpler multi-functional one, for example, high-low gear with a central diff-lock, but in a more realistic arrangement, that leaves some space for the suspension and the drivetrain going into the live axles. Of course, a simpler gearbox mechanism like you designed would be welcome, but I don't have high hopes for such a system from Lego either..

Really cool model, although I never knew the original one, it's lego rendition is really nice with smooth bodywork. I also like the use of the Mindstorms elements, it really shows how much potential those parts have, the hub, the motors and the whole programmability! Great technical solutions, I like the virtual pivot steering and the fact that it actually works smoothly with a 4-speed gearbox :)

I'm using an experimental software that I am writing on a Mac. It's simply connecting to the Buwizz via standard BluetoothLE connection, and using the Buwizz protocol to get info and try to control the hub. I don't know what info could potentially be queried about the connection if you did the same thing on Android, I don't have an Android device.

Nice video, it's your first right? I suppose when one takes out a MOC to some real terrain, first they are satisfied by seeing it go through some realistic obstacles; and then later they want more and more, take them on more challenging obstacles :) It would be nice to see it climb some bigger bump, not just a relatively flat surface with small bumps! I think the speed is quite okay given that it has only a single motor, but I also noticed that the movement is a bit jerky, also the steering seems a bit sudden. What do you use to control it? With PU servo, the steering could be smoother. But the jerkiness probably comes from the lack of power indeed, although I thought that such movement happens more with PF motors. PU motors could have smoother control, although it may depend again on the control software. These motors can be run in simple power mode and in speed servo mode too. This jerkiness is more typical for power mode, but speed servo mode could possibly correct it! Wonder which one your controller app uses by default or if it is possible to set it? Another thing I noticed is the suspension is still a bit stiff here and there; sometimes the model's weight isn't enough to push the model down and one wheel floats without much flex in the axles. Not sure if anything can be done about it, apart from testing it with a single soft spring instead of the doubled up setup. When you tried that and concluded it's too soft, what was the problem? Did the model sink in under its own weight? Or was it just bouncing/flexing too easily? Often, that's just the right setup :)

FYI, I have some test software to communicate with a Buwizz 2/3 and as I read out the value of the long range mode, so far I have only seen a false value sent by the Buwizz unit. I don't know what it depends on though, maybe my phone's capabilities (but I am guessing an iPhone 12 has a good chance of having appropriate BLE HW for it). Also, the Buwizz API does not seem to have a way of turning this on, so I am guessing that the FW will turn it on automatically if it can.

Sure, I know it's a B model, and I meant my suggestion within the constraints of the set :)