Lets "fix" powered up!

[allanp]

So many of us, myself included, find powered up/control+ to be problematic to say the least. Every great musical artist or band has a bad song or two in their set list, and control+/powered up is TLGs bad song! It pushes up the price of sets, which might be tolerable if it wasn't for it's downsides, namely no physical remote and it's reliance on apps and third party smart devices which removes all confidence in it's longevity. MOCability is also pretty poor, and set costs can be inflated due to components such as driver chips, tilt sensors and encoders being included in the hub and motors but not actually used by the model. However, it does have some advantages over previous systems, such as it's ability to do more complex things, being able to use motors as motors or as servos, being able to flip the controls when the transforming vehicle flips over, the inverse kinematics of the Leibherr excavator and so on. So what if we could design the next generation of electronics, how would we fix all the issues whilst retaining all of it's benefits?

Firstly, I think it's best not to even try to retain ALL of it's benefits. Inverse kinematics is a fun novelty but it soon wears off, is set specific and just not worth the previously mentioned issues that comes with it, but I think it's possible to retain most of the other benefits. I would love to hear your ideas, maybe we can come up with the next great thing! To get the ball rolling, my current idea would look like this:

EDIT: over the course of this topic I have listened to feedback and my ideas have evolved quite a bit since this first post. On with the topic.....end of edit.

Possibly a 4 wire system, 2 for main power, and 2 more for PWM/data, with stackable plugs. It could possibly reuse the PF plugs for backwards compatibility.

A large physical PlayStation style remote with lots of buttons, a couple d-pads, a couple of rotary knobs and two large fully proportional twin axis joysticks, each with a two way rocker switch. Bluetooth enabled, you can pair controllers to receivers by turning on each receiver and activating the controller you would like to control that receiver in turn. 

A basic battery box.

Receiver. Has an input from a basic battery box, an output and a push button for pairing. It has a direct, unfused through path for main power but does not do any switching/pwm control of the main power rail as it doesn't contain a motor driver chip. It controls the data signal only.

3 motors. One is a POWAH motor, one is a regular motor and one is a micro servo motor. They contain their own motor driver chips so it can be better paired to the motor it is driving. There is no internal gear reduction or rotation sensing on the regular and power motors.

Gear reduction box. Similar to the internal gearing included in the current motors, this is now a separate unit, allowing you to have as little or as much internal gearing as you want. These units can also be used in other places in the model.

Rotation sensor/encoder. Convert the regular and power motors into servos by adding one of these. Can also be used as rotation sensors in other parts of the model.

Force sensor. You can add more springs (shock absorbers or drive belts) to get the desired spring force (this would be the load sensor of the Liebherr)

Speaker. This would come with a bunch of preloaded sounds (petrol and diesel engines at various RPMs, horns, sirens, helicopter sound, train sound etc) as well as a few spare slots in case a model designer wants to add a few set specific sounds (like for a merry-go-round or steam train or whatever). Different signal strengths would play different sounds. Can optionally be plugged into a computers USB port to load in your own sounds but not strictly required. Has a factory reset button to restore the original sounds.

"Code" blocks. Instead of an app/smart device, you have physical blocks that are real life physical representations of them. Most of these affect the PWM signal only with through paths for main power. There would only be a couple to start with but more would be added over the years as sets require them. These could included a NO/NC relay switch, various logic gates, math bock (for multiplying/dividing/adding/subtracting of the PWM signal), servo controller, sensor reader block, delay timer with mode and time selector dials, ramp up/down block, etc. Sounds ambitious, but these blocks allow for much more complex control while eliminating the need for an app or a smart device. It is all "programmed" by the way you build and wire it all together. If the current system is "un-Lego like" will how much more like Lego can you can than physically building your "program" out of physical blocks?! 

I think that's plenty of options and controllability for any Technic set. It might remove some capabilities, you couldn't use inverse kinematics or control a CNC type machine or robot arm, but isn't that what Mindstorms was supposed to be for? Maybe much of the problem stems from unfortunately trying to make Technic into Mindstorms, resulting in control+ and killing off Mindstorms in the process!

Sorry for the long read, but it's not an easy thing to get right and what I suggested might not even be feasible! I should have run it past my embedded systems expert buddy first! I would love to hear your thoughts, improvements, criticisms and ideas.

 

Edited August 22, 2023 by allanp

[Mr Jos]

Motors having no direct reduction would eat ABS, the RPM is way to high without a gearbox, so removing all internal gearing would be a no-go.

Separate encoder would be good for measuring other rotations, but it would also require and extra IO port for every motor if you want encoders on all of them in your build.

Main audience wouldn't be interested in having to set up all these things for MOC's, in programming the controller to do all of these cool things you mentioned. It's all I do with my MOC's, and there's 0 interaction at all. Guess it's to complicated or whatever to take a look into it. Physical coding blocks would be a mehh... for me. Would make the build unneccesary bigger and complicated for most, as stated above.

For the MOC'ers of us I'm not worried, as long as I have a PyBricks install left on one of my laptops I will be able to run my EV3's forever. No updates needed, as it works perfect. If you rely on the Lego app, yep, forget it. Just like they ditched EV3-G, many people still search for it, but it's nearly completely gone from the web. The same will happen with these preset control+ apps, but there will always be ways to get them working again.

Why make another controller just for Lego, just take an already available bluetooth controller and make it compatible, save the design costs. I understand that LEGO will never say, if you want to control the Liebherr LR13000, you will need to buy a PS4 controller as extra to control it. But they could just make an extra PS4 program and say, it's compatible with it but not required, it would work with your smartphone as well. This would make many people happy.

If only people were interested in it I would make programs for every Technic machine to operate it with PS4 controllers, but there just isn't any interest for it, even when free.

[SaperPL]

The physical controller issue - TLG should hire or consult some kind of UX (User Experience) designer that would explain to them that touch screens are not tactile and don't communicate well the feeling that you're still pressing the button, and so if you're not looking at the screen, but at your $700 RC Lego toy, it will definitely end up disconnecting when you'll slip your finger off from a virtual input. Different devices will handle input differently, but prolonged holding of a turned on phone will mean sweaty fingers because screen backlight will put some heat there and the phone will emit heat, and also because you will end up pressing your fingers into the touch screen to not loose that connection.

I like the idea of code blocks, but rather than making them each a different item, I'd like them to have a dip switch for like 7 basic functions + 1 slot for programmable function.

I wish there was a simple brick that would be programmed to handle gearbox switching based on the load, that would automatically control servo based on the load on drive motor.

Fully detachable wires would be cool as well.

[gyenesvi]

While this topic has been discussed a lot, it's because there is a need for it, so it's never discussed enough, so good to have a separate thread for it. I have been thinking a lot about this problem as well, so I need to chime in :)

While many ideas of @allanp are quite interesting and similar to my ones, I do have to agree with the observations of @Mr Jos as well unfortunately. For example the physical blocks are interesting idea, but I guess some of them would be hard to implement (or even infeasible) on one hand, while take up a lot of space in the builds. And space is never enough, so I don't think that's would be a good direction.

The controller question is an obvious yes vote for me, every hardcore fan wants it, but I am not sure about whether the general public would actually appreciate it (with their wallets) and if it would be worth producing a lego specific one. I agree that the simple and feasible solution would be to make it possible to use readily available BLE compatible PS4 and XBox Series controllers. I believe all the technology and HW is there, it would be just a matter of writing FW. Obviously, an app would be needed to configure the hubs once (hubs in official sets could even come with preloaded configs), and it should be a just a few clicks to swap official configs on hubs. I also agree that it is a good idea and simple solution to have the app control as default, so no need to buy controller by default, but it should be an available add-on option. I think it should all be doable even with the current system.

I agree with @allanp about at least 3 (significantly different) types of motors, and also about the need for a small servo and a more powerful motor. Not sure about the separate gearing module though. As @Mr Jos notes, it could be dangerous to the plastic, and also the separate block would take up more space. Though I agree that somewhat faster (about 2x) motors would be useful (without reducing torque wrt current ones), while still not problematic. At least one type could be fast, as it was with the buggy motor (maybe not that fast).

But let's step back one step to think about the big picture first instead of getting lost in details. The first question that needs answering when designing such a system is what means of communication to use for control. In the PF system, IR had some advantages of being simple and easy to pair/configure, but it had too many drawbacks as well in terms of communication and limitations in fine grained control, so it definitely needed to be replaced. The alternatives that come in mind and have been experimented with even before PU are Bluetooth and 2.4Ghz radio. So which one is the better choice? As far as I have heard, RC toys mostly use radio, so why not use such a system? I guess the problem is that they come with their brand specific controller-receiver pairs, so in that case Lego would really have to develop their own (as I guess they did 20 years ago already with the RC line?) and I think they wanted to avoid that as it did not seem to go that well? Anyways, Bluetooth does have standards around it and implementations of low level communication protocols, so I guess that's why it makes sense to go with that. On the other hand, it automatically brings the idea of app control with it, as that's a simple way to avoid the controller problem. So I think we've got to accept that, there is no simple satisfactory physical controller solution here, unless Lego produces their own, which would be expensive to add to each set and limited in capabilities, or would mostly look/work like existing gamepad controllers. All in all, I think really the right way would be to provide support for those gamepad controllers along with app control.

The second key design issue I think is the hubs; whether to separate power supply from the receivers. I really liked the PF system, where they were separate, it felt more in Lego spirit, more composable, multiple receivers could be connected to a power supply without bloating the build with multiple big hubs. This is not possible with PU and is a big problem. Even a single hub is a big space burden on many smaller models. And such a system is actually possible with bluetooth as well, because Sbrick has done exactly that, though there is a caveat here. The PF system had a very simple motor controller chip, while the PU system has a more complex chip I guess, so it would probably need to be bigger maybe? Not sure though. Maybe it was simpler to put the two together (just like Buwizz did for the PF system). Nevertheless, separation of the two would also open the path for easier (official Lego or 3rd party) rechargeable battery versions, without the need to duplicate the control electronics and the firmware/app code. I think this is a big missing feature of the system, especially if we consider that PU plugs are not stackable and available 4 ports run out easily, or we need to use huge 6-port hubs.

Where to put the motor controllers is another interesting question. I guess putting them inside the motors would make those even more expensive and even bigger, neither of them is desirable. And I guess the hub/receiver would not get too much more simple, as it needs to have a programmable chip in it anyway. This is because the hubs/receivers need to be configurable, so there must be a fairly complex chip in there that runs the FW, including the BT communication.

Whether all motors need rotation encoders is another design question. I'd say not necessarily. Maybe enough to have angular motors with encoders, and linear motors without encoders (smaller and cheaper for driving vehicles, which is a significant percentage of models). Especially if a proper separate servo is available.

In short, if we depart from the IR communication (which I guess most of us would wanted to get rid of), then things get much more complicated.. So it's not trivial, and some decisions of TLG start to become understandable. But I agree that there's probably room for improvement :)

I do have to say that I initially was very enthusiastic about PU and its programmability, whose introduction coincided with when I got back to lego, but when I saw its problems and started to try old PF stuff as well, it was a much better play experience (of course using Buwizz as power source and BC2 for control).

[JopieK]

It is a shame that our German friend decided to quit his endeavors as he thought no one was interested.

Pybricks also seems to be a viable solution: https://github.com/undera/pylgbst

But adding something like an ESP32 (with e.g. Arduino) to the system would be nevertheless be a great way to solve these problems. As it is 'loose coupling' it would even be acceptable for the more purist fans. Maybe the Pi Hub (Build HAT) would be acceptable even for the purists as it was an official cooperation between Raspberry Pi and LEGO. If I get the chance (I mean if I have again a place to put my LEGO up and take it out of storage) I will definitely move to that direction I'm sure.

[Mikdun]

14 hours ago, gyenesvi said:

The first question that needs answering when designing such a system is what means of communication to use for control.

Dropping IR was quite obvious. Using BT is fine, at least it is well documented standard so any developer can write software for it. Using proprietary protocol will end up in legal battle at some point. BTW bluetooth is also radio.

14 hours ago, gyenesvi said:

The controller question is an obvious yes vote for me

I agree not the first time with this. Especially with using current gamepads.

 

As for the rest:

- is "dumb" motor necessary? May be useful, but "smart" motor can do it as well, the only downsize is price (and maybe size), but with low volume it may turn out the same price.

- less geared-down motors? Yes, it will be useful.

- splitting functions into smaller blocks? Not really, it will take too much space. This is one of the reason Buwizz exists and is used.

- physical coding blocks? Not really. It will be great for first steps, kinda "Duplo level" coding, but I cannot imagine building CAT with gearbox logic from them.

- more sensors? Yes, definitely! Especially since they all exist in EV/Mindstorms/etc.

- other? More flexibility in form of cable extension, socket multiplier (even if then we will lose the encoder data), lights that can be used on the same channel with motor, sound element.

[allanp]

Thanks for the input guys, I know it's not easy trying to come up with a solution that fixes all problems while retaining a lot of the benefits of control+, it requires a LOT of thought on a subject that's already been discussed quite a lot here so I really appreciate all of your comments.

So it seems the physical code block idea isn't that popular so far. The idea was from the industrial machine panels, which used to use a bunch of physical relays, contactors, delay times etc., and you could do some fairly complex control of industrial equipment without a PLC or computer. Just like with PF or 9V, If it ever broke down you just repaired or replace the faulty component and away you go. But I think the comments about the size and space requirements are correct, so it likely isn't feasible. So then if we have any kind of complex control, is there any other way to do it without a computer/smart device? I think there is. 

Okay now time for another unfeasible idea from Allanp....Control Center +! So now we have a system that's similar to PF, with basic battery boxes and separate receivers just like before. In fact, it probably could just be PF2.0. It's like PF but replaces IR with 2.4GHz. We also have much higher quality (and much more compact) servo motor, a micro motor, a regular motor and a buggy motor but in the shape/format of the current large motor. We also have a small, cheap, basic PF style remote for the smaller cheaper sets. But for the flagship we also have a new PF2.0 control center +. This would be a new physical remote but could also be mounted directly to the model like in control centre 2. It's quite large, almost the size of the original control Centre, it is just small enough to be comfortably hand held but just large enough to be on your lap when sat down. It also has an inexpensive LCD screen, like this remote has (though the control center + wouldn't look like this): 

This would be designed and made by Lego and not using pre-existing remotes like the one pictured above or from a console. That's because it's not being used to play a game or fly a plane but most likely it will be controlling excavators and other such heavy machinery, so it would be nice if the controls you are operating closely mimicked the controls of the kind of machinery you tend to find released as a Technic set.

There would be several buttons and so on, but the two main controllers that catch the eye would be two large, fully proportional 2 axis joysticks with a two way rocker switch on each, allowing the simultaneous control of six functions from your thumbs on these two controls, but of course there would be other buttons and stuff elsewhere for more functions. This is like a real life excavator where the two arm movements are controlled by two axis joystick and the bucket is controlled by a two way rocker switch.

The screen allows programming. For some programming examples:

Load sensing of the Liebherr. There is a touch sensor that is pressed when the load is too high. On the control center +, press the "program" button, select the touch sensor, select "when activated", select the motor output channel that moves the arm in and out, select the direction or motor rotation which moves the boom outward away from the crane, select "disable". The arm will now not move outwards when the load gets too high but will still move inwards. You can also add any number of other actions to the sensor trigger, such as disabling the motor and direction that moves the hook upwards, turn on output 3 at 55%, into which you have a speaker, which when given a signal of 55% plays sound 11 of 20 preloaded sounds, a warning sound in this case. Additionally you can select to turn on "light 2" which is a indicator light built into the control center +.

For an RC pneumatic excavator, we have 3 servos, connected to 3 receiver outputs which we can label what ever we want, like "shoulder", "elbow" and "bucket", or simply leave it to the default 1, 2 and 3 if we choose, in the control center, controlling 3 valves for the 3 arm movements, and a powerful buggy motor for the compressor plugged into a 4th receiver output and labeled "compressor". For the shoulder, press the "program" button, select "joystick 1", select "X-axis", select "proportional control", select "shoulder", go back a few steps and select "on/off control", select "compressor". Now repeat for the elbow and bucket and you're done. You now have 3 proportional arm movements that will also automatically switch on the compressor at full power when any of them are used. There would also be some tweakable settings, such as limiting how far the servo can move, ramp up/down settings and so on. Alternatively we could also have a pneumatic pressure sensor to control the compressor. 

For a manual gearbox, we have 3 drive rings in a six speed gearbox. Each of the drive rings are controlled by a servo, 3 servos in total connected to receiver outputs which we have labeled 1, 2 and 3. We also happen to have a bunch of push buttons on the control center which we can program. So press "program", select "push button 1, select "output "1" and set it to +40 degrees, select output "2" and set it to 0 degrees and do the same for output 3. Repeat that for all the other gears, selecting the correct servo positions for all servos for each gear and it's done.

For a sequential gearbox, we would have the rotary cams in the model controlled by one motor, and instead of moving to absolute positions we program the motor to either move one way or another in 45 degree steps with each push button press.

For more complex programming there could be programmable sequencers and look up tables and so on. When pressing the "program" button, the various controllers on the control center + are now used to select and alter setting in the LCD screen. Everything is fully programmable and do-able from the control center itself. However, to make things easier for the more advanced stuff such as when programming the sequencers or look-up tables, there is an option to plug it into a computer via USB. There is a free program you can download and it will enable very easy editing and program creation. This program can be used to download ready made programs for the big flagship sets that come with the control center +, but the sets will also come with detailed step by step, button press by button press instructions on how to program your model all on the control center itself. This option of being able to plug into a computer via USB while also being able to program on the unit itself is taken from my guitar effects pedal! It has an LCD screen which enables full control and programming capabilities:

...but it also has a free to download computer software which allows for much easier programming and from personal experience, it's an absolute joy to use! It makes it much easier but i have no concerns over longevity.

So what do we think, do we like this PF2.0 idea? Does this combo of having a 2.4gHz version of PF with basic remote for smaller sets and a totally baller control center + remote for the more expensive sets (also available separately so they can sell more units and take advantage of economies of scale) address everything?

Edited July 28, 2023 by allanp

[lcvisser]

I appreciate all the enthusiasm displayed here, but I think many (all) of the ideas here are not feasible.

I just got my very first C+ hub and motors and I think it's fine. I got the motors to move using my phone via the official LEGO app faster than it took me to get batteries from the store. I'm betting this is enough for 90+% of the market. I'll be playing around with Pybricks over the weekend to see what the options are, but I'm sure that PyBricks and similar 3rd party solutions cover the needs for another 90+% of the "advanced" users. The remaining <1% is a very small market (and note that Technic is already a relatively small market) which would then have to cover all the development costs of the advanced components (Control Center +, rotary sensors, relays...).

Prices for such components would be high (high development cost, small market), and I'm sure people will complain about that in the same way as they are at the prices for C+ sets (and note that the actual component costs are only a fraction of the total cost). And we saw in the late 90s, early 2000s what happens when LEGO puts a lot of fancy parts into their models below cost price.

So instead, I'm going to argue another way forward: promote and enable 3rd party compatibility. SBrick, Pybricks, and many other enthusiast initiatives have show what is possible. For a sustainable future for Control+ and future systems, I'd hope for LEGO - for every electrical system - to:

• Make public the electrical interface specification (pinouts and signal requirements)
• Make public the communication protocol (I think this was done at some point for C+, but I can't find it back)

In this way a healthy, complimentary, 3rd party ecosystem can emerge - without reverse engineering - alongside the sets being released. This ecosystem can serve the needs of power users, shielding LEGO from having to carry the development and production costs for those niche products (including all associated regulations across the globe). 

That being said, I see some improvements for C+:

• removable wiring (like in the old 9V system), to allow different lengths
• a smaller (micro) size motor

The latter may still come - the former unlikely.

[Lok24]

15 minutes ago, lcvisser said:

For a sustainable future for Control+ and future systems, I'd hope for LEGO - for every electrical system - to:

• Make public the electrical interface specification (pinouts and signal requirements)
• Make public the communication protocol (I think this was done at some point for C+, but I can't find it back)

It is here:

https://lego.github.io/lego-ble-wireless-protocol-docs/

and, to be precise, "control+" is only the app.

This protocol ist used to devolop thnings like Pybricks  or legoino.

You can make your technic sets sustainable if you load the existing code via pybricks into the hub(s).

No programming needed, taks app. 5 min.

Regarding motors: there is only one(!) without sensors, the train motor, and the price difference  is just 3€

And you can use the SPIKE Prime Sensors as well.

 

 

 

[allanp]

Yes but let's remember that PF was around for ten years before it was replaced. Powered up has been around for about half that time already, and judging by the lack of development of the app and the hardware, I get the feeling it's time is limited. It certainly won't be around forever and will be replaced eventually by..... something. So what is that something? What direction should it take? Do people really want it to be just more of the same with total reliance on third party computers/smart devices and third party software just to make it usable for MOCs and limited use of third party physical remotes with the need to program in python or whatever? Not everyone is proficient, or even wants to be proficient in coding or python or whatever else. Is that really the most desirable thing you could want if you could design everything from scratch? Control center+ would have USB connectivity for optional computer control, so if TLG were to make everything public so that enthusiasts can make their own software (like a train manager or something) they can still do so. If PU is going to be retired and replaced, which it will be, with all new motors and hardware developed just like they did with PU and PF before that, which they will do, then what should replace it? This is what I am suggesting PF2.0 for, for when PU is eventually replaced. And yes I am suggesting it very early, years in advance, but these things take years to develop. Better to let TLG know what you want now, instead of a few months before it's released.

[Lok24]

10 minutes ago, allanp said:

Do people really want it to be just more of the same with total reliance on third party computers/smart devices and third party software just to make it usable for MOCs and limited use of third party physical remotes with the need to program in python or whatever?

The python programs for alle technic sets are already there, no need for any programming.

And If you have a remote (of any kind) and hubs you always have to configure that in any kind.
Why not  use a Smart device ? Where a the children who would find that "unsual"

How should that be configured in your " Control center+ " environment?

I use her a standard remote and City Hub with an ESP32 (app. 10€)  as a "Batterybox", where  you can configure speed, direction, time to run and many more via web-Browser.

 

[gyenesvi]

While @allanp's Control Center+ idea sounds interesting (and the kinds of motors you describe for PF 2.0 is similar to what I'd like to exist), I agree with @lcvisser that there would probably be no consumer market for it, only 1% of consumers would actually appreciate it, so there is no real incentive to produce such a thing. Especially that a quite similar system can be achieved by enabling a configurable BLE gamepad controller, which would have zero production cost.

Interestingly, there is an existing 2.4GHz wifi alternative to the IR controller, that looks exactly the same.

https://www.greengeckoworkshop.com/products/wifi-lego-rc-combo-100m-range-2-4ghz

That's a simple and nice product, wonder why it never took off, I have never seen it used, maybe it came too late when other options were around. Also, the controller seems to have only on-off input, wonder if it would be easy to turn it into a continuous joystick, and how people would like that as a product. I also don't know how it's paired with the desired receiver.

[Mikdun]

36 minutes ago, gyenesvi said:

Interestingly, there is an existing 2.4GHz wifi alternative to the IR controller, that looks exactly the same.

https://www.greengeckoworkshop.com/products/wifi-lego-rc-combo-100m-range-2-4ghz

That's a simple and nice product, wonder why it never took off, I have never seen it used, maybe it came too late when other options were around.

It is used. It's all over Aliexpress.

I have 6 or 7 set of those and just use it as a drop-in replacement for Lego PF remote system. It works like a charm. Long range, no problems with sun, no problems with lack of direct line-of-sight. It works exactly like Lego IR, so there is also remote with 7 steps each direction, looks just like 8879 remote.

Why you do not see it? Because it is not allowed to write about non-Lego stuff here. 

[gyenesvi]

13 minutes ago, Mikdun said:

It is used. It's all over Aliexpress.

Good to know some people use it and it works nicely. But I never seen it in MOCs or in FB either, not just here. And I think such drop-in replacements are sort of allowed here, just like Buwizz.

[Bartybum]

@allanp How much do you expect an advanced programmable transmitter like what you describe to cost? You're practically describing an RC transmitter. I'm picturing $200-300AUD, which already makes it a super niche product that very few people will buy. At that stage you're just begging for something to be an official Lego product for the sake of it, and not for any practical reason. Just go third-party, like others have said. Alternatively, maybe a controller that just feeds control input commands to a smartphone (where the control profiles are stored) via BT, which then feeds commands to the hub? That would at least make it far cheaper, since you already own the computer that comes with a programming app.

For me, PU has one pressing issue - flexibility. I think there's two areas that need to be addressed that would make improve PU's flexibility:

1. Size - The smart hub is too big.
   1. Separate the brains of the smart hub from the batteries, like a PF receiver but with four ports, stacked vertically to make for a super compact hub. Have a dumb 6x AAA battery box in the style of the PF train battery box, but with Technic pinholes at either end, two slider switches and two ports.
   2. Introduce a slim battery box, to allow for small C+ and dumb PU sets.
   3. Introduce micro/S motors.
2. Encoders - Not every motor needs a damn encoder, it's driving the price up for zero reason (especially the simple motorized sets) and there's so many functions that could be done with just a dumb motor.
   1. Introduce dumb PU motors in all sizes: micro/S, M, L, XL.

Edited July 28, 2023 by Bartybum

[Lok24]

9 minutes ago, Bartybum said:

Not every motor needs a damn encoder, it's driving the price up way too much

1.) The price is just 3 € higher than for a dump train motor ;-)

2.) the encoder enables the motor to be used as sensor or servo in other szenarios, and it offers load regulation.

3.) we still wait for extension calbes

4.) we still wait for the VM solution

 

 

[Toastie]

6 hours ago, Bartybum said:

it's driving the price up for zero reason

Very nice discussion(s) in this thread!

However electronics never drives up the "price tag". In the world we are living in, it cannot. Even when you subtract the development costs ... when selling the product in a "mass" market (and a whopping 0.1% fraction of TLGs sales is still a massive mass market). No, the company selling the electronic device(s) can. It is not the electronics in PUp devices, it is the company selling these - making a fortune out of selling these. As simple as that. Another TLG masterpiece: "Sets like the new Liebherr are so expensive because of the electronics". Sorry, I really don't think so.

Introducing a new "electronic" system? Phew. That would require to be able to sell these in mass products. Bat stuff. And all the other super selling products.

All the best,
Thorsten

[Bartybum]

8 hours ago, Lok24 said:

The price is just 3 € higher than for a dump train motor ;-) 

When they first released, the PU motors cost roughly twice as much as PF motors, so I was coming from that angle. That being said, I'll admit I didn't consider whether they actually started charging more for PU sets than in the PF days.

8 hours ago, Lok24 said:

the encoder enables the motor to be used as sensor or servo in other szenarios, and it offers load regulation. 

Yes but not every function needs an encoded motor. Drive motors, two-position switching motors (like in the Zetros), and other functions that can otherwise use clutches don't need encoded motors. The only functions that NEED encoders are precise functions, like steering, gearbox switching or inverse kinematics. Even the inverse kinematics features could (and should, in my opinion) be dropped, but then that brings into question the entire existence of the smart hub, so I won't go there.

8 hours ago, Lok24 said:

3.) we still wait for extension calbes

4.) we still wait for the VM solution

I'm not sure what this has to do with my comment, but I agree with 3 as well, I just don't think it's as urgent as other issues. I don't know what VM means.

Edited July 28, 2023 by Bartybum

[dhc6twinotter]

There are three things I would like to see added to PU, and two of these are deal-breakers for me.  

1) Extension cables.  Got to have these for those mocs that require motors far from hubs.  

2) Ability to have at least 8 motors off one hub.  Either have a hub with 8 ports, or better yet, have Bluetooth receivers that have 3-4 ports on each that can then plug into one port on the hub.  That would allow 12-16 motors to run off each hub.

Those are my biggest gripes with PU.  There are times where I have to use PF because PU simply won’t fit.  

3) The inability to port stack sucks, but if TLG could provide a solution to #2 above, then this wouldn’t be much of an issue.  

TLG should’ve just made Bluetooth receivers for PF rather than reinvent the system.  PF was such a well-rounded system, and PU just lacks some basic necessities.  

I also don’t want to sit at my desk and learn how to program every moc I build.  I want to build something and start controlling it immediately.  I spend enough time sitting in front of a computer at work, and I don’t really want to have to program Lego when I get home.

[Bartybum]

38 minutes ago, dhc6twinotter said:

or better yet, have Bluetooth receivers that have 3-4 ports on each that can then plug into one port on the hub.

This is an interesting solution, but I think the component would have better luck being used as a distributor, since the smart hub already has BT.

Each time the smart hub receives a command from the paired smartphone, it could send a signal out to one of the ports which has a distributor plugged in, along with an ID corresponding to one of the four ports, which then receives a signal.

There are a couple downsides that I could see, the most significant one being that once you have sixteen motors, you're really starting to chew into the battery capacity each time you play. Secondly, the circuitry would need to be beefed up to be able to accommodate four times the power and information. At that stage it might just be be easier to have two smart hubs, each with eight motors, or a distributor with 2 ports instead of 4. There will probably be extra costs with the new hub, which means that any time the smart hub is being used for small-potatoes MOCs, you're stuck with a huge beefcake of a hub that you just don't really need - I rarely ever see MOCs that need more than ten motors, let alone sixteen.

Edited July 29, 2023 by Bartybum

[Lok24]

11 hours ago, Bartybum said:

Yes but not every function needs an encoded motor.

But if you have a dumb motor and you build something new or do some experiments you then have to buy a new motor.

And look at something simple like a windmill: with a dump motor you have to build a  gearing mechanism to adjust speed.
This is not needed with a motor with encoder.
It makes even simple thing much simpler.

None of my PU or EV3 MOCS, has any gears.

What would be better with motors without encoder?
There is just one , the train motor.

 

11 hours ago, Bartybum said:

I don't know what VM means.

Its the way lego want's to go load programs permanently into hubs.
It's annouced since years.

Edited July 29, 2023 by Lok24

[Lok24]

Hello @ all,

here's a collection of questions (and answers) I could ask the PU devolpers 4 years ago (LEGO Fanweekend Skaerbaek Sep. 2019), there are some points discussed and announced, like multiplexing, speaker, VM and so on

https://www.1000steine.de/de/gemeinschaft/forum/?entry=1&amp;id=426445#id426445

(german , please use a translator app of your chioce)

And here's a statement concerning VM (LEGO Fan Media day 2021)

https://ramblingbrick.com/2021/05/28/the-road-map-for-legos-powered-up-system-unfolds/

Quote: "This feature has provided a few challenges to implement, but is getting closer to rolling out as part of a closed Alpha version soon."

 

Edited July 29, 2023 by Lok24

[gyenesvi]

@Bartybum, I totally agree with you about size and encoders.

2 hours ago, Lok24 said:

And look at something simple like a windmill: with a dump motor you have to build a  gearing mechanism to adjust speed.
This is not needed with a motor with encoder.
It makes even simple thing much simpler.

This is completely possible with motors without encoders as well (I guess you mean dumb motors). It is possible to adjust the speed of PF motors as well, although they have no encoders. It's just that dumb controllers are on-off, not continuous. In fact I was surprised how well the speed of a PF motor can be adjusted with a gamepad controller for example.

The encoder is required for reading out the position of motors, whose usage falls into 3 main categories

1) servo function (absolute position within 360 degrees)

2) relative position to a configurable zero position (to drive LAs, for inverse kinematics / robotics)

3) very finely adjust the speed of a motor, to hold the speed even under changing torque requirements (for example for precise slow speed crawlers)

The first can be done with a traditional servo. I'd say the third is not really required for lego, since the speed of PF motors can be adjusted well enough for the use cases lego models actually have (they will never be as fast or precise as RC models). So that leaves inverse kinematics / robotics as the main use for motors with encoders.

19 hours ago, Lok24 said:

The price is just 3 € higher than for a dump train motor ;-)

For me price is not the main problem, but the size. PU motors are 1-2 studs longer than PF ones, and it matters a lot for smaller builds. Given that many builders would like even smaller motors than the PF ones were (S motor, or micro motor), the size increase is just taking things in the wrong direction. Bigger motors mean bigger builds, which means more weight, which means more burden on the motors.. small builds are becoming quite impossible. For example building a 1:12 car with drive and steering using PU is impossible with a proper interior. The only really possible solution is putting the electronics into the cockpit.

Another interesting thing about the size of the motors is that they are 8 studs long, which does not always play well together with even sized parts. For example beams with alternating holes have their holes in one side in an even cadence, so you simply cannot attach motors to them, which can be a problem as such beams and frames are structurally pretty useful and more and more common in builds. These are just my experiences with building with PU motors.

I am not saying the no motors should have encoders, but there could be some without them. It could maybe simply achieved by bringing back old dumb PF motors with PU connectors.

[Lok24]

7 minutes ago, gyenesvi said:

It is possible to adjust the speed of PF motors as well, although they have no encoders. It's just that dumb controllers are on-off, not continuous. In fact I was surprised how well the speed of a PF motor can be adjusted with a gamepad controller for example.

That's the point: you need an external/additional device to control. And: you have no load control.
You've seen the video with a train creeping over a switch point?
Always with same speed, independent from battery charge?
I think this is not possible with PF.

13 minutes ago, gyenesvi said:

of the motors is that they are 8 studs long,

The 88008 is 6 studs, the "Small angular" even 5 studs, as far as I know.The PF Servo is 7 studs. Please correct me if I'm wrong.
I agree that there should be small(er) motors, but I think this does not interfere with the encoder.

And ist has nothing to do with the properties of the  "PU system"

21 minutes ago, gyenesvi said:

but there could be some without them.

Yes, " could", but why? What would be the benefit? That's the question .....

 

[gyenesvi]

1 hour ago, Lok24 said:

You've seen the video with a train creeping over a switch point?
Always with same speed, independent from battery charge?
I think this is not possible with PF.

That indeed sounds like a valid use case that I did not knkw about as I'm not involved with trains. Thanks for noting!

1 hour ago, Lok24 said:

The 88008 is 6 studs, the "Small angular" even 5 studs, as far as I know.The PF Servo is 7 studs. Please correct me if I'm wrong.

The small angular one is indeed that small but it is super weak, even for its size. A geekservo in the same form factor is even smaller and is about 4x stronger according to the spec as far as I remember.

1 hour ago, Lok24 said:

I agree that there should be small(er) motors, but I think this does not interfere with the encoder.

The encoder adds one extra stud length for the linear motors, and that protruding pulley on the angular motors which is in the way in many use cases.

1 hour ago, Lok24 said:

And ist has nothing to do with the properties of the  "PU system"

Why would it not? Do you mean the encoders? They are integral to the PU system. Or I misunderstand you..

1 hour ago, Lok24 said:

Yes, " could", but why? What would be the benefit? That's the question .....

I just explained above about size, and space being premium in small models.