kbalage

A real life RC vehicle is not a video game :) You don't see any RC car controllers with triggers. There are 2 big camps, first is controllers using sticks (joysticks) and the other is the pistol grip style with a wheel for steering on the side. When I was a kid we had mostly stick controllers, but nowadays the pistol grip is more widespread for cars. For anything that flies or needs more channels, the stick controller is still the way to go. A pistol grip controller has limited number of channels so it is not universal enough to cover most LEGO RC vehicles, that's why I'd go with the classic controller with 2 joysticks. Throttle and steering can be separated with this configuration and sticks are convenient for precision control. Front triggers could be added for the video game generation if they really prefer throttle and brake control there, otherwise they can be useful e.g. for tracked vehicles as additional channels. Well that shows how frequently I use these controllers in video games :) The RC excavators I've seen either use buttons on the front or extra levers to control the tracks. I think front buttons are more convenient since that way it is possible to drive and operate the sticks the same time. Based on my experience motion control it is far from being precise. If someone prefers it then it is already available in the PU app and can be used with a smart device.

@Tcm0 controlling LEGO cars with the buttons only on the PU remote is possible, but it is far from being convenient for most of them. I suggest to test it with a few vehicles and compare the experience with a game controller using BC2. Proportional control for steering and throttle is a must if you want fast and precise control. It is worth to check the virtual controls of the different Control+ profiles and see how the functions can be translated to physical controllers. A few examples: - a faster car (e.g. the Off-road buggy) needs the ability to control speed. You want to be able to select your speed and maintain it, quickly accelerate, stop, reverse etc, and for this purpose a joystick is the best controller. Although a single joystick has 2 axes to use, the default Control+ profile for the buggy showed how bad it is to assign both throttle and steering control to a single joystick, so another joystick is required for steering, see e.g. the Control+ profile of the Zetros. Steering also requires proportional control, the servo gives us the ability for precision control so let's use it :) - If you check the Control+ profile of the Liebherr, it has 2 joysticks (all axes are used for the different movements), there are 2 sliders for the tracks that can be replicated with pressure sensitive buttons, and other functions like opening/closing the bucket or predefined activities could be triggered with buttons. Here's an example how I configured the Xbox controller with BC2 for this set. I would say that a LEGO controller would need 2 joysticks, 4 buttons on the top next to the joysticks and 2x2 pressure sensitive buttons on the front like on the Xbox controller. These would more or less cover the requirements, and if more buttons are needed then a train controller could be attached any time.

It's not like TLG would need to reinvent the wheel. They have decades of experience with electronics, remotes, child safety, all the know-how that is required to produce such remote is there. They already made one remote for PU, nothing would prevent them to make another one. The only thing missing apparently is the will to make it. As I see all the PU-based smart solutions (Control+, City PU sets, Mindstorms etc) were created fully with touch control in mind. The train remote was designed for the City trains because they had something similar for PF and train fans are loud, but according to TLG that should work for everything else as the small PF remote had the same abilities and that was also enough for all the PF vehicles they ever made. TLG fully focuses on the sets and hardware is created based on their needs. An app-based touch interface will always beat physical controls from the designers' perspective since the app can offer a "rich experience" compared to a simple remote. Any generic hardware that would improve the user experience of a smaller amount of users might be at the end of the priority list, if it even happens to be included in the list. Honestly I don't have high hopes, the best I expect is the implementation of the Xbox/PS4 remotes in the PU app like it works in the Mindstorms app. The VM functionality is fully experimental and apparently does not have much priority either, so a dedicated remote designed to work with that has almost zero chance in the next 2-3 years. Hopefully we'll have a working 3rd party solution way sooner than that.

I don't think it is such a big effort, TLG already made remotes with joysticks, dials and buttons. If Chinese companies can produce a generic BT controller for $15-20 with 2 joysticks, a D-pad and a few buttons that work totally fine with BrickController2 then LEGO should be able to do it as well. There's no real need for super advanced ergonomics or anything extra to have something good enough in a LEGO "suit". Even with studded parts or pin holes it would be far-far better and easier to use than touch control. I'm sure it would be more expensive than the PU train remote, but at least it'd be an option to use.

Depends on the angle of the slope, but it slips rather than rolls.

Interesting, I have an "Xbox One S" controller and I had the impression that it supports BLE but apparently it is BTC only. This makes the BLE-compatible hardware list pretty limited, I'm not sure if it is worth for TLG to develop a solution if only a handful of compatible 3rd party controllers exist and it is quite difficult to identify which ones would actually work with the VM directly while a wider range is supported through the app. BLE compatibility is not something that is actively advertised by the manufacturer. The solution available for the Mindstorms 51515 set btw has its own flaws, the reaction time highly depends on the smart device used and possibly on the complexity of the code. I did some tests when I did my first video about the set and sometimes the response was very laggy, and there were other issues like multiple motors not starting/stopping the same time when controlled by the joystick so running the robot straight was not always successful. I still think a native solution with proportional joysticks would be the best, that could work through the PU app and could also connect directly to the hubs. Mould King could make such remote so it should not be a challenge for TLG :) They'd only need the will to do it and then dedicate the proper resources.

They managed to do it for the Mindstorms robot inventor with the Xbox One and PS4 controller support. Adding a support for the controllers mentioned above would not be a big deal in the Powered Up app, but this would still mean that a smart device is required to run the code and do the assignment of controls. BC2 works the same way, you need the app to run constantly. There are multiple challenges with the controls themselves. Mapping buttons / joysticks to PU motors require a lot of parameters, it's not a simple X axis = Port A assignment. Is it a servo (needs calibration, limits, power, etc), if it is a button then what does it do (max power/0 power, stepper, etc). This configuration needs to happen on the smart device with the code itself that is executed by the remote, then the whole configuration has to be able to run on the hub in standalone mode with the remote being connected to the hub directly. Due to the limitation of the BT protocol used it would only work with the Xbox One controller so it is doable, but definitely not a trivial task. @howitzer - here is a video demonstrating the concept for 51515: As you can see this one only works in streaming mode with the hub, so it cannot work without the smart device.

Considering the pace of development so far, what are the chances that all the functions will be implemented in the VM plus the controllers etc. in a timely manner? I wouldn't hold my breath... Pybricks is here, already useable and has a pretty well defined development path. Don't get me wrong, I would also love to see a solid official solution, but based on the past years I'm a bit skeptical about the timelines TLG can follow. They are still focusing on the experience tied to products (Control+, Mindstorms) and does not seem to have much interest in investing resources for generic solutions.

TLG is also working on a similar standalone solution to run code on the hubs, the only big question is the timeframe when they manage to have it completed and released. I wouldn't expect it this year for sure. The real question at this point - how an "official" solution could be better and more convenient then Pybrick's implementation and does it really worth the wait? If I think about it, to beat Pybricks they'd really need to release a physical controller with proportional joysticks, then simplify the code blocks and make it possible to create a configuration for the controller and hub(s) that can be saved on the device(s) to run it without the smart device.

@Clever Nickname this is a bug that happens with all the apps (PU, BC2, Buwizz, Control+)

The behavior is not that easy to reproduce, sometimes it happens, sometimes it does not. As I noticed it also happens when the vehicle does not get an input nor it is pushed beyond the "limits" so the cause might be something more complicated. I already reported it like ~2 years ago when it occurred with the very first sets like the Rally Car, but apparently it either did not get much attention or isn't that easy to eliminate. Or both...

A similar anomaly happens with all of the apps (Control+, PU, BC2) so this might be a bug of the system itself.

Lol thanks, I'll definitely have to try that one day :) Glad you folks like the review. I tested a few tires on the set but for me the clear winner is the one that was used on the blue prototype as well, the 68.7mm tires from the 1989 Batmobile set. Here's a very quick video with them:

After the preview and the prototype demo video here is my full detailed building review of the LEGO Technic 42126 Ford F-150 Raptor. This is a nice build but has some flaws and questionable design choices as well, so the overall feeling is quite controversial. Here are all the details:

@XoverBrick very interesting, thanks for sharing! Where did you find the official description of the items? They are not listed on the instructions page :) The hardware seems to be very promising, my only concern is the limitation from the software side - I guess the new hub and the light matrix will be only supported by the Spike Prime app and I don't expect a quick change in this. I'm almost sure the motor won't be supported by the Powered Up app either initially, but hopefully that can be added faster.

@Zerobricks we appreciate your proactivity here on the forum, but I don't think anyone was personally attacking you. We really like BuWizz 3.0 and would love to use all its features and functionalities, but at the moment not all features are fully functional that you advertise on the webpage. I think it is a completely understandable request from your customers to get a roadmap which shows when you are planning to implement all these features, and also when you are planning to release the information you promised.

Those beams are definitely more difficult to rub off then to make the gears crack without them :)

As it was already mentioned by multiple reviewers, the rear axle of the Zetros seems to have a potential problem. Under constant heavy load pushing the truck beyond its limits, a 5L beam that holds the gear driving the rear differential gets pushed out a little bit, and as a result the gears start to slip, crack and might get damaged on a longer term. I tried to run several tests to see what might be the cause, can it be a friction variation of the axle pins or is it something else. We also tried to come up with a quick fix with @Attika that eliminates the issue under "normal" circumstances without completely rebuilding the rear axle. You can see the details in this video:

The Zetros and the Tow Truck will be available from August 1st. The Raptor can be already preordered for some curious reason, but it will be only shipped after October 1st.

No any complicated mods, rather some variations with wheels, shock absorbers, and a few things to remove that come off easily:

I don't think there're any deeper reasons behind the motor usage other than the sets' requirements. Maybe as the first C+ set, the rally car used an XL motor for drive to offer a starter set with both L and XL motors. Based on my tests (video below) the XL motor handles low rpm / high load situations better than the L motor, so it fits in the sets you mentioned. The buggy is a light car with the motor output geared up so L makes sense. The Zetros seems to be contradictory for the first sight, but with the hard coupled dual motors it is already more powerful than it ideally supposed to be, there's really no need to use XL motors. I'm sure the CAT will use XL motors if needed.

I checked the page again but apparently the "Technic" category for the hub is only as promising as the Spike Prime / Mindstorms hub since that one is also called Technic Large Hub. As I see there'll be a new (probably smaller) Spike Prime basic set, and the hub and the battery will be also sold separately, these are the 3 products. Apparently all of them belong to the Education line so not much excitement for the Powered Up community at the moment.

TLG clearly went away from anything that has a higher performance or have the possibility to break or stress plastic components out of the box. That's not a feature for the masses as it has way to many potential issues, but we don't really need TLG to produce these. If someone wants high performance motors or power sources then 3rd parties like BuWizz are there to provide the components.

This function - like the 3 speed gearbox in the Volvo - has more educational than play value. You build a functional feature that you can understand and see it in action. Having the diff open when you are not climbing certainly puts less stress on the components so it's advisable on a longer term. It might not have a huge visual difference, but if you want to demonstrate that then it's enough to lift a wheel or two when it is open. About the turning radius, that's a combination of multiple factors. First the wheelbase - that was given by the proportions of the original. Second, these wheel hubs on the live axle. They had to be mounted on a certain way, and that's what the system allows, there's really not more left in there.

That'd make sense, or even a re-release of the more recent ones like 42114 & 42124 with new set numbers, but the fact that 42129 is (at least initially) released with the old hub design contradicts to this theory.