vascolp

In my opinion that is coding. I mean, if I want to connect a PU motor to a motorless set just to see the fake engine spinning, I need to program? That is what make people complain so much and wanting to go back to PF.

Strange indeed... That I can see...

I can never see your pictures... what's wrong with them, I can see all other people pictures... I tried with different browsers, anonymous navigation... don't understand.

Pretty cool indeed!

The Technic Hub can connect to a remote. You probably should say: LEGO does not provide software out of the box to connect its sets to the remote.

Thank you, it wasn’t that simple with current parts. The trick was to use the old Steering Arm with Pins which really allowed me to do it. They don’t grab. Just tried in the second model to replace the axle that connects to the universal joint with a blue friction pin and using the top of the first one. It kinda works, but it is a bit difficult to operate. Maybe with a longer control axle and a 12t gear to hold better. I thought on 42006 for the second one. You still have time to try a 4-way I suppose!

Some time ago you mentioned you haven't done a 4-way claw. Somehow, that came to my mind, and I took some time to see if I could do one. The result is here, hope you like it. BTW, very cool contest entry!

Ah doing a helper program to configure Remote Bla Bla for instance. Not a bad idea!... a bit against the idea of not programming but it would be only configuration.

It’s a curious idea, you are using another hub just to avoid flashing the main hub… But hubs do talk BLE with any other device, does not need to be another hub...

system.storage() works very well and it is definitely part of the solution to keep configurations in a general purpose Hub program. This is one side of the equation. But talking with another Hub, in my opinion, is not the other side… guess what would be the other side!

All that is possible. Just not that simple, specially if you are talking to the Remote and have to associate actions to the buttons. In Remote Bla Bla, if you skip the configuration mode, the play mode does all that, it reads a configuration, currently from the Remote but could perfectly be form some initial configuration lines... and it could be simpler and more powerful. While it could prove to be useful to bring people to use PoweredUp, their is stilI a number of people who wouldn't go that way (I guess you already knew I would think that ). But it is an interesting idea anyway. In fact, PyBricks has the DriveBase class which is sort of similar but for robotics, and it requires a bit more of programming.

If PS5 and XBox can support BLE I do support that! It makes sense to support those remotes widely available. I suppose it ends up somewere here : #262 . @Pybricks guys are you there?!

I agree, having smaller versions of 4 port hubs and motors would be very nice additions to the current PU line. And without major disruptions. The remote with proportional controls and such might not be so easy. I think the problem is that PU talks BLE, not Bluetooth (which uses more power). If you look around, all RC remote controllers are Bluetooth (or 2.4GHz...). There are no BLE RC remotes, only garage door or tv set like remotes. I suspect that that's because BLE is not enough for a proper RC remote? @Lok24, for some reason I can't see your pictures, but I suppose they are screen dumps of the Powered Up app. If that's the case, my feeling is that your post summarizes very well what average people without programming knowledge aren’t available to do. Even if it is that easy. And that, together with the lack of documentation.... By the way, I think brick controller 2 works by having an android device in the middle, isn't it?. Not what I would want, I prefer a remote talking directly with the hub.

Can't see your pictures...

Here are some thoughts, feel free to (dis)agree! This thread is important, it shows us in what ways people are dissatisfied with PU. I could resume this way: People can´t just use PU as easy as PF was. This is true. TLG focused too much in the mindstorms perspective, where programming skills is assumed. And forgot a vast group of people who want to be able to MOC/MOD Lego stuff, by using motors and remotes with no programming involved. People fear that the dependency of smart device will in the future void the usage of PU hardware. While this can be true, this is the world where we live in. The enormous amount of features PU can have, require proper interfaces to deal with it. Building proprietary interface devices when everybody has an incredibly powerful computer in their pockets (we call it phone 😊) doesn't seems to make sense. And this is a general trend in many areas, not only Lego. So, I simply would not worry with this. The remote! LEGO has a remote. People don’t use it but with appropriate configuration it could control every set Lego has or had with PU hubs…. including SPIKE Prime/Inventor Hub. Even many MOCs. The problem is that the only way to configure its usage is by programming. Focus is the “only” word. The remote, take 2. There could be a remote with more buttons, proportional controls, etc. No questions about it. However, it seems to me that sometimes people confuse the remote (a device to remote control Lego creations using PU hardware) with a device to configure PU usage. This falls in item 1.. So, if Lego produces a better remote without fixing 1., things will be the same. Now we have a remote that most people can’t use. Then we would have 2 remotes that most people wouldn’t be able to use! In my view, a new remote, while desirable, is not an issue in the subject of trying to improve PU usage by people. @Lok24 we certainly could start another thread to discuss possibilities of improving PU usage. Basically, trying to improve item 1 above. I would like very much to ear about the abilities of your Motor Control program.

Hi, Almost eveything possible exept the 2 remotes at the time. But one remote can control all 4 ports. Probably my Remote Bla Bla stuff would do the job for you? Tell me if you like it!

Maybe my mistake, I didn't refer you ... I am a bit suspect, but preffer the two axle solution with pulleys . The barrel is "so tall" that sometimes it gets stucked against the axle-pin connectors. The single axle solution steers a bit less and it is a bit loose in the center. The two axle solution, as it bends the axles a bit, has a good rest centered position and at maximum steering (check first picture). But they are very similar.... I have already unbuilt this.

You can use the green button in the remote. The problem with this interface is that the hubs have not many memory and the config program consumes significant space. For instance in Remote Bla Bla, the CityHub, (which has half the memory of TechnicHub) simply has no space for the config part of Remote Bla Bla. It only has space for the play code and, even so, trimmed from the support for 4 ports. All this, of course, because we are programming in modern memory hungry languages like python... C and probably C++ would be a different story....

Nice . Yes but, unless you place lots of buttons and/or a screen, it will always be difficult and limited. Thats where an APP running on a computer (laptop, smartphone, mainframe, whatever!) is handy.

Any MOC! 1) If I have a Technic Hub and a motor and want to connect the motor to the wheels of a motorless MOC to see the fake engine spinning… I must program something! 2) A car: two driving motors and a motor acting as steering (servo). 3) Another car: two driving motors, each one on its direction a motor acting as steering (servo), a motor acting as gearbox command. 4) A wheel loader, several motors, driving, steering, shovel up and down, tilt shovel…. I tried to make something to help in these situations, and it does help, but it is really awkward to configure:

In my opinion PU hardware is good. But, for many people, the need to program is not acceptable. While programming can be a valuable thing, that should not avoid the entire usage of PU. And this IS happening. There should be a piece of software with a simple interface that would make possible to use PU motors and hubs in a simple way. Given the richness of PU, this software will always have to use a smartphone or a computer, but not for playing, only to configure. Basically, there are two types of users: the ones who can program and take advantage of PU (like @Lok24), and the ones that want to use it without programming. I guess @allanp is representing this second group, where I find myself many times even if I know my ways in programming. This is the biggest flaw of PU. And it is mainly a software issue. The remote is another story. Yes we could have a better remote. But the existing one is enough in many situations. A better remote by itself does not solve the real issue. What we need is to be able to easely use any remote, either new or old.

This is pretty cool and nice to watch! I guess you could also replace all the air stuff with linear actuators? Maybe slower to move each gate, but you could do it with only one motor! Also, it’s probably easier to route tubes than axles if the gates are too far away or in strange positions.

This looks very cool! Maybe, in the front, using white or LBG lights instead of transparent ones would look better?

And a different material too. Notice that in the old version there are two small holes near the bush that don't exist in the new one. This is most probably because the new material is a bit softer. I also think that parts in the new material are less resistent to warm, Sometime ago I bought a lot of lego that included 42050 and 42123 and washed everything as I always did, in warm water... Usually I use too warm water because I never had problems with that... but this time, many of the axles and bushes, half bushes, connecters etc in the new materials became too loose, they don't stay in place... Did anybody else had the same experience?

So I build both. Pictures below. One pivot axle solution has a bigger steering radius. And when you force it to turn more, the part tends to come out slightly. But requires less embracing and it is easier to build. The Barrel is fine but it is not perfect because it is very angular and sometimes it collides with the tan pins that connect to the wheel holders. The pulley (two pulleys) solves this because its rounded.