gyenesvi

This is pretty cool, I never thought pneumatics could be controlled with such precision. What is the key to that, for a single valve? Is it that it's opening the valve slowly? It's opening them fully though, right? Can it make small adjustments as well? And I still don't get what prevents a valve from dropping the arm when it gets open in the downward direction? I mean I am not even sure why it would drop in a manual system. Is it because there is pressure in the tubes and that is put to the valve too suddenly (in this case I understand how a slow opening can prevent the drop), or is it because opening the valve lets the air flow out and the weight of the arm just pushes it out immediately? I hope it's clear what I am trying to ask..

You don't actually need to calculate that, just know that up-gearing looses torque.. If the motors are running in the same direction, than you will actually HAVE to remove one gear to make it work. Currently the motors would need to run in opposite directions.

Nice medium scale trophy truck with light-weight design (are those 81mm tires?), though I'm curious how much it will reap, that much of up-gearing looses quite some torque to move it, you have to calculate that in as well.. And the 8T gears might prove a bit weak for high power. Btw, why don't you lower that upper L motor by one stud to make it more compact and get rid of one of those 8T gears and align the 24T gears so that the 8T in the middle gets symmetric forces?

I agree with @Lok24 that as a system, Powered Up is not inherently flawed, so we don't necessarily need a new system, the problem is that it does not live up to its potential, and as @eric trax says, many components have shortcomings. The hubs for one, and the motors as well, the PU variants are both larger and weaker at the same time, to the point that the XL misses its point of existence against the L. And NO, it is not readily available for the average user without some programming knowledge (which technic users don't want to have to learn). I for example only make alternate models of PU sets that are controllable with the original C+ profile because otherwise much fewer people would buy them.. (many actually ask if it is controllable) @Lok24, we are talking about the usability of the system for building your own models, not official sets. Nobody said that official sets would not work out of the box.

Wow, very nice build and smooth functioning, I like the simple layout of the control electronics and routing of the control pathways! Cool way of using two controllers together. I also had the same question in mind, but if I look at the build, I'd also guess that the two smaller hubs were actually a better fit space-wise for the shape than the one large hub would have been..?

Just for the record, the (widespread) programming language is called C++ ;-) A "bug by design" sounds like a contradiction.. (a bug is something that you did not really design) But yeah, an S motor has always been missing from the lineup. I wonder if they actually had plans to produce one, as the naming would suggest, or maybe all the naming is just marketing crap.. Indeed that could have been also great but only with a proper multi-joystick proportional controller produced by Lego. It's sad that there was so much potential left on the table even for the PF system.

I agree. In principle, using the Powered Up app, one can build a MOC and "program" a control interface for it (at least that's the idea, though the coding canvas thingy sucks for a few reasons, like missing support for HW elements and missing documentation until recently). Another way to reuse the electronics without coding is through the official Control+ profiles. If you happen to build a motor configuration that matches that one of the official sets, you can use that sets Control+ profile for control without any coding. That's what alternate models do for one, and with the increasing number of official sets and profiles, more and more simple motor configs are supported for cars for example. Though I understand that's kind of a cumbersome approach. But definitely the electronics itself is not single-use (but true that more flexible SW support would be really needed).

Well I've seen a video on FB that has more similar proportions to the lego one ;) though the trusses are still a bit too wide I guess. But we are getting there slowly :) https://fb.watch/m6mwAATNFt/

Hmm, thanks, I suspected it would be PITA (same as other flexible items), not saying I want to try it immediately..

Yes, I meant the yellow grille piece. To show more pictures, you have to upload it elsewhere, for example on Bricksafe, and then link them here. Looks cool from all angles btw :)

Really cool! I did not know that pneumatic hoses are available in Studio, how did you do that? Are they available like other parts, or is there a teick for using them? (I cannot check Studio now)

That's a pretty cute one, looks nice. But as far as I know shrinking stickers is not allowed, only cutting originals. For the front grille, you could try using 1x2 grille tiles. Does the suspension use rubber bands?

Yes it is similar in a very simplified form. Port selection can be omitted and solved by changing the cables on the hub when you only have two ports, but that does not really generalize to 4 or 6 ports (sometimes some ports can be blocked by the build itself, or cables may be short to reach further ports, I have had both cases happening). Furthermore mode selection should be addressed at least, along with proportional control as you say. I did not know direction reversing is possible though, but it should be possible for all button groups. That would mean one extra swich next to each joystick/button pair, which may be feasible, so that's also a possible way. The point is that one way or another, a remote that can configure itself seems doable, and some proportional joysticks should not be too hard either.

While I agree with your observation of these two extreme ends, I wonder how difficult it would be to cater for both to some degree. Given that the capabilities of PU are tuned for the 2nd camp, the main issue here would be to make simple cases simple, to satisfy the 1st camp. Supposing that by that we mean something like the simplicity of the PF system, it would be a good start to have a PU remote that can achieve at least what the PF remote could do; that means channel selection (port mapping) and direction reversing. So I started to think what would be required for that. If we consider that there would be at least 4 channels to select from (but 6 in case of the larger hubs), then the number of buttons and their states for configuration would be too many to be placed on a small remote (I think something like the PU train remote would be a good start if it had two continuous joysticks instead of the buttons, plus a few more buttons on the top). In case of PF there were only 2 joysticks on the remote, with a reverser switch and one channel selector per receiver, while the port mapping on a single receiver-remote pair (red/blue) was fixed. Now if the PU system had separate receivers from the battery, the same system could possibly work, but that would not work with the current PU hubs, something more complex is needed. We could go in the direction of @allanp's idea with a small touch screen in the remote that would allow configuration of the remote, but that would be already too big/complex/expensive I think. I wonder if some simpler way of config would be possible with some buttons and using an LED as feedback. Something like this: there would be 4 config buttons on the remote; 1 button to start/finish config, 1 button for port selection, 1 button for direction selection and 1 button for mode selection. Config could go something like this: press the start config button. Then press the port button repeatedly to get the corresponding port (A - 1, B - 2, etc). The number of light blinks would acknowledge the selected port. Press the direction selector to switch directions. The light color could indicate the acknowledged direction (e.g. green - forward, red - reverse). Press the mode selector repeatedly to select mode (speed/servo/etc), the light color would indicate the selected mode (similarly to direction, just more colors). Move one of the joysticks (or press one of the control buttons) to indicate that that's what you want to associate the port with. Press the config button again to store the config. Repeat this for each joystick/port pair. Note that multiple ports could map to the same joystick, or multiple joysticks/buttons could map to the same port with different modes for example, each config sequence would add a new mapping. A long press of the config button could clear all mappings to allow starting over. I think that could be comprehensive enough as a start - no reliance on app or too complex remote interface. For more complex cases (such as power limits for ports), there could still be an option to connect to the hub from an app and do something more fine-grained.

Yeah, I did not want to mention that as well :) But actually this specific model was designed to be fast and run on outside terrain, which may include wet rocks where grip can matter in race conditions :)

I wonder when that time will come though. More concretely, I am trying to think what would trigger that. I think the transition from PF to PU was triggered by the need to replace the IR communication with something more reliable, and the need to be able to create more complex things by relying on programmability, like inverse kinematics, robotics, etc, and trying to keep up with concurrent products like Sbrick and Buwizz at the time. I believe in these regards the current PU system is far from getting old anytime soon. By that I mean the systemic aspects. Probably / hopefully components will evolve over time, such as new motors / sensors may be introduced, new hubs / new firmware could even be introduced, rechargeable battery could be introduced, I could even imagine a separate battery and receiver be introduced, existing remotes could be supported. But all that is still not a new system, that is just making the current system fulfil its potential. Because there's a lot of potential left on the table yet. But I don't see the need for a fundamentally new system right now, as long as there's no technological innovation that supersedes the current one. Even if motor technologies change, for example to go brushless (highly unlikely), the current system could absorb that, as it is quite flexible in its current form. And I think the future is more SW driven and digital, as opposed to the physical building block idea that you have, simply because digital is much more capable and flexible. True that lego traditionally operates more in the physical realm, but I think in terms of RC control, a balance of physical and digital as we have currently is necessary and quite okay for the future.

Did you put the drive motor into the rear axle?

That is a pretty ingenious solution for the use cases where you have plenty of space!

That indeed sounds like a valid use case that I did not knkw about as I'm not involved with trains. Thanks for noting! 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. 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. Why would it not? Do you mean the encoders? They are integral to the PU system. Or I misunderstand you.. I just explained above about size, and space being premium in small models.

@Bartybum, I totally agree with you about size and encoders. 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. 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.

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.

Yeah, I know, I often have to re-render things many times..

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.

Well, that's the problem :) Unlink them.. I was able to do it on my models ;)

Cool model, I have seen this in real life and I believe Jantayg still keeps experimenting with new variants of it. For the really final renders, can you fix the tire threads to point in the same direction? :) Just looks a bit weird this way..