technicfan20

For example, the force sensor could be placed instead of or in addition to the rubber bands on the gray gear rack (that's connected to the Derrick boom, behind the hub) as a more realistic way of load sensing.

On the high-res pictures you can now finally see the load sensor. An interesting solution (although kind of expected) to use tilt sensor of the hub for this. Is this the first time it has ever been used for something functional in an official set? However, I must admit that I would have loved to see a Mindstorms force sensor, given the price of the set.

Hi everyone, since the 51515 Robot Inventor is EOL, I decided to give it a try. I started with the Charlie robot to get to know the Hub and the app (Windows). However, in the "Wake-up" project I observed some strange behavior. According to the instructions, Charlie should calibrate and then wait for a tap on the hub to play the wake-up animation and raise its arms. In my case, the calibration seems to trigger the tap gesture immediately, even when I insert some time delay after the calibration. Did you also observe this behavior? Are recognized gestures stored indefinitely until they are consumed by a wait-block?

Did you have a look at sharpbrick/powered-up? I tried this some time ago, and it worked well on a Windows 10 device and Visual Studio. If you are fine with using a different firmware on the hubs, then there's also Pybricks.

I assume you have seen the model in action already? So this means there is only a single hub and 4 motors? How could these electronic components justify the price in comparison to the 42100 with 2 hubs and 7 motors? And is there a fake motor as some rumours suggested?

Is this really the solution, to make any special gear you need to get a perfectly realistic gearbox (or other mechanism)? Nowadays you could 3d print everything, but I guess the real challenge is to find an efficient mechanism with the parts you have (just look at the awesome gearbox designs here on EB). In my opinion, the appeal of LEGO compared to scale models or other specialized toys (like RC cars) has always been the flexibility to build almost anything with a limited set of parts. Of course, then the LEGO solutions might be more complex or bulky, and surely they perform worse (its plastic after all). I guess, TLG opened a can of worms by introducing so many special parts lately (to name a few: stronger diffs just for RC models, planetary wheel hubs, maybe even beams with alternate pin holes, ...). I get the impression, that now people demand that there should be every possible part in every possible color. Regarding the color coding: Yes, I also built my first Technic models without any color coding (and I made mistakes ...), but the models had like 1500 parts maximum. Nowadays you have 4000+ part behemoths and I (as a somewhat experienced technic builder) really like to have some colored hints to get the orientation right or to not miss a step so easily. TLGs customer support will really know what the main issues are. Just look at all the threads about gearbox problems of the 42114 here on EB and estimate how many calls they probably got from people, who do not even know that this forum exists. Even if many AFOLs cannot imagine it, it seems that building LEGO can be a real challenge for normal people without any disabilities. If you want to reach non-AFOL adults, the building experience has to be nice and not frustrating, and they probably do not play much with their models. But they can afford any other hobby ...

According to a stream by promobricks (https://youtu.be/7zt5Oha6h6s, in German, credit to @Brick-a-brac) the CAT should feature new (wider?) tread elements in yellow (with one bar? instead of three like the old tread elements) black actuators to raise the blade adjustable angle of the blade a motorized ladder a detailed cabin a fake engine (V12?) It seems that the CAT is very large and completely different compared to the first pictures. I guess this explains the rumored price and part count.

In my opinion, node-powereduo has quite a lot of dependencies (at least on windows), including the use of another bluetooth driver. MicroPython looks nice. Unfortunately it seems that support for Control+ is planned, but not yet implemented. Would it require to use an alternative firmware on the hubs, which could break the compatibility with the official app (at least until restoring the firmware)?

Hi everyone, Most solutions (official and inofficial) to Control PoweredUP/Control+ models are for Android/iOS only. For a quite a while I have been looking for a simple, portable solution to run on any Windows PC/tablet, using a gamepad or a touchscreen as input device. I haven't found a satisfying program, so I tried to create something by reusing existing apps/code snippets. As a basis I chose the "Lego Brick Automation Project" (BAP). It handles all the Bluetooth communication and Motor control for me, but unfortunately the source code is not yet available. But it allows to implement custom C# code. However, the problem is that the custom code is placed within a class, so you can't easily include new assemblies. But it is possibly to load DLLs, so I could implement a library for reading inputs from an XBox controller (https://github.com/speps/XInputDotNet). The global code in the BAP now looks as follows: It requires to place the "XInputInterface.dll" (https://github.com/speps/XInputDotNet/blob/master/XInputUnity4/XInputInterface.dll) next to the BAP executable. Then this newly defined classes/functions can be used to control any PUP/C+ model using an XBox controller! I tried it with 42100, using the following custom program in BAP and a MS Surface tablet. It uses a button layout similar to the official app. Holding the shoulder buttons reverses the track direction, so I can use proportional control for forward and reverse. B stops all motors and the program. X and Y control the opening of the bucket. Commands are only sent, if the motor speed changes. It works like a charm, there is no noticable delay in the control. A big thanks to the developers of the two frameworks/apps I used here! Are you aware of any other solutions on PC, maybe capable of reading motor positions (for steering)?