Lok24

True. It is just the FW on on the hub. It could and should work exactly like the Move hub. I sent all the infos already, have a look here, Brick2Brick network

@Mikdun I knew there was a tutorial here it is: You see: it works, with a slightly improved remote (see above, configure) and levers as @allanp proposed this could be even better Imagine that this would be possible too with the technic hub ....

Yes sorry, that was wrong. it should be: Many sets with these hubs can be used without a smart device, or additionally with, i.E. Trains, duplo For the Boost 17101 (which I have) you can move Vernie with the remote. What I wanted to explain: If you don't build the sets, you can use some Powered Up components without the App, i.e. for own experiments, with the technic hub this doesn't work.

Hi @allanp Our approach is different. You start with sets and themes, I start with functionalities and above all Mocs, especially those that don't move but are more like machines or automatons, like the barrier I showed. In your first suggestion there should only be battery boxes and receivers, that's how I understood it (maybe wrong). That would have been exactly the SBrick Plus. Many hubs today do not require a smart device or an app. For example Move Hub, Hub, Duplo. Sets with these hubs can be used without a smart device, or additionally with the app. The exception is the technic hub, it cannot be connected to the LEGO remote. A train control with proportional lever would be rather unusual, rather a rotary knob. In my eyes, a remote control should be as modular as LEGO itself. Assume: - a block with batteries and electronics, on-off-connect, - various input modules like proportional levers, knobs, buttons. - Up to four, configurable, suitable for all hubs. Overall, I think the idea with the Control Center + is difficult because configuration on a small display is hardly possible, programming in my opinion not at all. That was it with the EV3. That cost around €200 …. I think we agree, there are deficits in the remote controls. But whoever owns any Powered Up parts, no matter what kind of sets, should also be able to combine them into new MOCs, and also be able to program them. Especially if you establish a connection between sensor events and engines. And the cheapest and easiest way to do this is with a smart device, which is why this option should be available. The decisive factor: this can be used to operate the Moc, but it shouldn't be a must. Or get by with the properties of the "small" remote. What would be needed in the low/mid range? - No changes to the hubs - "only" a better FB - Modular, up to four elements - knob, button, lever - Switch for "Port" it refers to - mode (on/off, prop, calibration)

The idea of replacing hubs with dumb receivers would be a regression to me. You could not build even the simplest automated things without any remote, cause your "simple remote" can only start/stop a motor. It has nothing to do with PU, but would be a complete different system,you called it PF 2.0 yourself. How would you control a shuttle train? A railroad crossing? You wold need a separate huge remote whole time while they are operating for each of these mocs, as the simple remote cannot be programmed. Something like that, no remote, no smart device, only what you see: Or I didn't understand the complete idea.

Then please explain. We have the remote you proposed, with proportional levers and the display. Then you have to configure - where would this configuration be stored? In the Remote? Or in the Hub Where would a program be running? In the remote or in the Hub? And who did the programming? How to share routines and programs with others? It would be a regression to what we have now. What would be the estimated price, compared to a technic hub or a spike hub (Which have no levers, no display?

To complex, to expensive, not flexible, not compatible with the future.

I see, but see no way to have this with the actual sets.

Indeed ;-) Feel free to build something different. I gave already examples. Some kinds of robots, a railroad crossing, a shuttle train, GBC, I expect that not to be a function in the hub, otherwise there would be a LWP command to do so. Suppose no, not as shown on the box. But thats not a failure of the PU system, but due to the fact that no remote is included. For a city train set the answer would be yes. Assuming that BLE is still a standard then. And the proper batteries are still available..... BTW: what do you think how many clients expect that? And how many might have the set and are happy to use their smart device to handle today? Outside the AFOL scene?

But these are two different things that have to be distinguished. PU ist the platform consisting of - devices - cables and plugs - BT-protocol - LWP 3.0.0 - Powered Up App and it spans form duplo, city, boost, spike, mindstorms, technic. Control+ is only one app. For only a few sets. There is no need to use a smartphone. The hubs internally have - a bootloader to load new firmware - a preinstalled LEGO FW It is (like with EV3 since years) possible to install other software. Or control the hubs with any other devices using the original LEGO FW. PU is an open system, ready for now and in future. And it allows LEGO (or any other manufacturer) to add devices (like a remote i.e) And to do so this you don't have to know anything about electronics or programming. (If you look at my example for the CAT from 8 sections only one has to do with programming, all others are configuration only) This is much easier than to build a "7 Speed gearbox" ;-) (which uses non LEGO parts as well, and how would you shift the gears remotely? - very simple with PU) Another simple example is a shuttle train - use a simple city train set and just on additional sensor, you'll find many applications for that in the net. How to solve with PF easily? For simple turn/off of a motor it is simple as with older systems - with much better properties. But it offers a bunch of very extended possibilities. I think that is very, very different. That's why a open system is useful for all users. I'm glad with that.

Here's the link I posted already: https://ramblingbrick.com/2021/05/28/the-road-map-for-legos-powered-up-system-unfolds/ (2022) and again the link to the statements of LEGO concerning my questions in 2019 https://www.1000steine.de/de/gemeinschaft/forum/?entry=1&id=426445#id426445 quoted and translated: There will be a VM on the hubs that will then run code. The Spike Hub, coming in January, can do all that and much more. You can call up various ready-made programs on the hub and upload new ones. The small hubs should also store code with the VM! And here is the complete system: https://www.1000steine.de/de/modelle/myimages/?dir=4092 In short: you can store programs in any hub, like in the spike hubs today, and run them autonomous I don't know these sets in detail, but as I remember it's "only" a motor which has three a four angles to be selected. This can be done "easily" by sliders or buttons. If you describe what is the desired behavior, I can show a small program which tries to do that. I did some programming before the official release for the CAT for a review, when control+ app was not available, here it is a first approach:

I think It only works if the program resides in the hub, as described before.. There are no steps, the setting is in °/sec. Each type motor has individual values No need for a complex remote at all.

Setting a speed in rotation/sec, which then is independent from the load. For example: a train which doesn't (like the the PF ones) starts with step 3 and then is much to quick, but that keeps a constant speed. Or cranes.... I never would spend money for such a controller (nor a technic-set for more than 100€ ).

Sure, why not? You only have to deactivate the retaining spring. A simple remote, two sticks, turnable, two knobs (or 4...) By the way: most of my MOCs (the majority) don't use any remote. And no gears at all. They run autonomous, like a simple battery box or a shuttle train, and many others. With your solution some important functions (for my use) are simply impossible, load control i.e.

You missed the word "simple" ....

wrote that already, extension cables and a simple remote (like the existing one) for proportional control, LEGO VM

That might all be difficult cause the reaction depends on BT an the time to send and receive commands. This can be avoided by executing your blocks within the Hub. Exactly what Pybricks does and with LEGO VM is announced. I posted such "configurable code blocks" from PU App before. And all these blocks will contain dozens of errors, so your device must be updated and needs internet access. Also for new types of devices. And additional blocks. You are inventing a smart device ;-)

Hi, did'nt find my old stuff but created something new Quite simple as an example for two ports Here is an Excel-Sheet with a button Here's the Pybricks-code and the result Of course one could also add a formor do the same with HTML and js ..... But now it''s a little bit off topic, perhaps open a new thread if interested.

That was the idea, and I had such here. No, a website or Excel or whatever, similar to the GUI of SBRICK, BrickController, or BUWIZZ. Which you or I or whoever release and publish And as result when pressing "finish" a program like that in the clipboard from pybricks.pupdevices import Remote my_remote = Remote() my_remote.name("yourblastring") So user has to - configure via tool - click "finished" - https://code.pybricks.com/ - insert program from clipboard - connect remote - run And that should work for all hubs, even with 3.1 I can show a quick and dirty example later, have to search, cause I used that last in 2021 ;-) (And: config could also(!) be stored in system.storage of hub, read, stored in remote and back to GUI)

Yes, the system is 40 years old.... But it sends only in one direction (controller to train), and it needs a decoder in every train. And these decoders have to be configured (with an address) before using to select only their data. (so each motor has a dedicated address). You must have a list of all your trains and addresses... that's not what you want for your LEGO motors. And since 2007 there is also a back channel, which sends data back, but while this is done all other traffic on the tracks must be interrupted. And you need special receivers to filter these messages (only 8 Byte) It is possible, but not that simple. And we are talking about boosters to support multiple trains, 3A each.

Sorry for explaining it not clear enough, the idea was to use an external editor to configure, and so it could be used with 3.2 too. Or you create the string for the remote, but even then you have to use a very small program to rename the remote. So it was meant as an enhancement.

The symbols try to explain: the left moves a motor in a certain angle, the right regulates the power of a motor. The blocks are explained here: https://www.lego.com/en-us/service/help/Power_Functions/LEGO-Powered-Up-programming-blocks-kA06N000000g04eSAA?locale=en-us quote: Sets a tacho motor on the defined port to the given position in degrees. Sets power to the motor attached to the selected port and runs until the program runs without the need of a loop. Positive numbers rotate clockwise, and negative numbers rotate counterclockwise. The main benefit is to have sensors. This is the reason whay it is not that simple to stack the plugs. I did, this why I have 4 very expensive EV3 here. And controlling a gearbox with 3 or 4 Positions isn't that simple with PF, I think. That's wrong. You can use as much hubs and remotes as you like. And the limitation for one controlling device depends on you BT controller. I already tried 8 hubs, no problems. I agree: the properties of PU and PF are different. But for a simple control of 4 motors with one remote (this is what my picture showed) it's not that difficult.

this ist what the programmer/user needs: UP = "A+" DOWN = "A-" STOP = "A0" SWITCH = "CENTER" or i.e. FOR = "B+" BACK = "A-" STOP = "B0" and here is the routine "CheckButton" def CheckButton(x): try: button = remote.buttons.pressed() if x == "A+" : x = Button.LEFT_PLUS if x == "A-" : x = Button.LEFT_MINUS if x == "A0" : x = Button.LEFT if x == "B+" : x = Button.RIGHT_PLUS if x == "B-" : x = Button.RIGHT_MINUS if x == "B0" : x = Button.RIGHT if x == "CENTER" : x = Button.CENTER if x in button: return True else: return False except: return() So the buttons have user-friendly predefined names, and no remote connected does not lead to an error. and the remote itself: # --check if remote is connected --------------------------------- try: button = remote.buttons.pressed() hub.light.on(LEDconn) remoteConnected = True except OSError as ex: hub.light.on(LEDnotconn) print("Remote not connected") remoteConnected = False if watchdog == True: v=0 drive() try: # reconnect remote remote = Remote(timeout=1000) wait(100) print("Remote reconnected") remoteConnected = True except OSError as ex: print("Remote not connected") So it's very simple to use this in "function" in every program. As you see "function" does not contain any "remote"..... I use this i.e for a program, that runs a motor with a certain sped (like an adjustable battery box). But you can at any time connect a remote to adjust. My question is: is it a good idea, and would some people (who have much better python knowledge than I have) be interested to create a pool of such classes? Here is the complete program "MotorControl": # ----------------------------------------------- # MotorControl # # uses https://code.pybricks.com/ , LEGO City hub, LEGO remote control # connect 1 or 2 motors of any kind to Port A and/or B # # Version 2_9 # -----------------------------------------------/ from pybricks.parameters import * # Color # ----------------------------------------------- # Set user defined values # ----------------------------------------------- # define the two profiles # profil_x = (minimun speed,maximum Speed,accelerate in steps of ..., wait for next acceleration(in ms) Profil_A = (20,100,10,100) #min,max,step,acc Profil_B = (10,500,5,200) #min,max,step,acc # define direction of motors dirMotorA = 1 # Direction 1 or -1 dirMotorB = -1 # Direction 1 or -1 autoacc = False # accelarate continously when holding butten # ----------------------------------------------- # Set general values # ----------------------------------------------- # assign buttons to function1 # syntax: function = "name" # name may be "A+","A-","A0","B+","B-","B0","CENTER" UP = "A+" DOWN = "A-" STOP = "A0" SWITCH = "CENTER" mode=1 # start with function number... watchdog = False # "True" or "False": Stop motors when loosing remote connection remoteTimeout =10 # hub waits x seconds for remote connect after starting hub remoteName = "" # connect this remote only # Color and brightness of Hub LEDs LEDconn = Color.GREEN*0.3 # if Hub connected, color * brightness LEDnotconn = Color.RED*0.5 # if Hub is not connect, color * brightness LED_A = Color.GREEN*0.3 # Remote Profil_A, color * brightness LED_B = Color.RED*0.5 # Remote Profil_B, color * brightness # ----------------------------------------------- # Import classes and functions # ----------------------------------------------- from pybricks.pupdevices import DCMotor, Motor, Remote from pybricks.parameters import Port, Stop, Button, Color from pybricks.hubs import CityHub from pybricks.tools import wait, StopWatch from pybricks.iodevices import PUPDevice from uerrno import ENODEV # ----------------------------------------------- # function 1 / drive motors # ----------------------------------------------- def function1(): vmax = profile[mode].vmax vmin = profile[mode].vmin accdelay = profile[mode].acc step = profile[mode].step global v if CheckButton(UP) and not CheckButton(STOP) : for x in range (1, step + 1): v = v + 1 if v > vmax : v = vmax if v > 0 and v < vmin: v = vmin if abs(v) < vmin: v = 0 drive() wait (accdelay) if v==0: break # further acceleration if button keeps pressed while autoacc == False and CheckButton(UP) : wait (100) # avoid changing direction when reaching "0" while v == 0 and CheckButton(UP): wait (100) if CheckButton(DOWN) and not CheckButton(STOP): for x in range (1, step + 1): v = v-1 if v < vmax*-1 : v = vmax*-1 if v < 0 and v > vmin*-1: v = vmin*-1 if abs(v) < vmin : v = 0 drive() wait (accdelay) if v==0: break # further acceleration if button keeps pressed while autoacc == False and CheckButton(DOWN) : wait (100) # avoid changing direction when reaching "0" while v == 0 and CheckButton(DOWN) : wait (100) if CheckButton(STOP): v = 0 drive() wait (100) class setprofile(): def __init__(self,pr): self.vmin=pr[0] self.vmax=pr[1] self.step=pr[2] self.acc=pr[3] profile = [0,0,0] profile[1] = setprofile(Profil_A) profile[2] = setprofile(Profil_B) # ----------------------------------------------- # function 2 # ----------------------------------------------- ''' def function2(): if CheckButton(UP): timer[1].set(3000) if timer[1].check(): print("Do something") ''' # ----------------------------------------------- # general program routines and classes # ----------------------------------------------- # ----CheckButton ------------------------------------------- def CheckButton(x): try: button = remote.buttons.pressed() if x == "A+" : x = Button.LEFT_PLUS if x == "A-" : x = Button.LEFT_MINUS if x == "A0" : x = Button.LEFT if x == "B+" : x = Button.RIGHT_PLUS if x == "B-" : x = Button.RIGHT_MINUS if x == "B0" : x = Button.RIGHT if x == "CENTER" : x = Button.CENTER if x in button: return True else: return False except: return() # ----delay ------------------------------------------- class delay: def __init__(self,id,time=0,watch=StopWatch(),busy=False): self.id=id self.time=time self.watch=watch self.busy=busy print ("Init Timer",id) # set a timer def set(self,x): if self.busy == False: self.busy = True self.watch.reset() self.time = x print("Timer",timer[1].id, "set to",x) #check if timer is reached, then return "True" def check(self): if self.busy == True: if self.watch.time() > self.time: self.busy = False self.time=0 print("Timer",timer[1].id, "stopped") return(True) else: return(False) # ----drive ------------------------------------------- def drive(): global vold global v print (v) if vold != v: # for each motor 1,2 for x in range(1,3): # set speed and direction s = v*round(motor[x].getDir()) # real motor commands depending on motor type if motor[x].getType() == "Motor" : motor[x].obj.run(s*motor[x].getSpeed()) # in 2.7 if motor[x].getType() == "DCMotor" : motor[x].obj.dc(s) if v == 0 and motor[x].getType() != "---": print("stop",x) motor[x].obj.stop() #if motor[x].getDir() != 0 and motor[x].getType() == "DCMotor" : motor[x].obj.dc(s) vold = v # ----portcheck ------------------------------------------- def portcheck(i): # list of motors, 1 +2 contain string "DC" devices = { 1: "Wedo 2.0 DC Motor", 2: "Train DC Motor", 38: "BOOST Interactive Motor", 46: "Technic Large Motor", 47: "Technic Extra Large Motor", 48: "SPIKE Medium Angular Motor", 49: "SPIKE Large Angular Motor", 75: "Technic Medium Angular Motor", 76: "Technic Large Angular Motor", } port = motor[i].getPort() # Try to get the device, if it is attached. try: device = PUPDevice(port) except OSError as ex: if ex.args[0] == ENODEV: # No device found on this port. motor[i].setType("---") print(port, ": not connected") return ("---") else: raise # Get the device id id = device.info()['id'] # Look up the name. try: # get the attributes for tacho motors if "Motor" in devices[id] and not("DC" in devices[id]): motor[i].setType("Motor") motor[i].obj = Motor(port) #new in 2.7 # if motor[x].getDir() != 0 and motor[x].getType() == "Motor" : motor[x].obj.run(s*motor[x].getSpeed()) # in 2.7 devs_max_speed = {38:1530,46:1890,47:1980,48:1367,49:1278,75:1367,76:1278 } dspeed = devs_max_speed.get(PUPDevice(port).info()['id'], 1000) motor[i].obj.stop() motor[i].obj.control.limits(speed=dspeed,acceleration=10000) motor[i].setSpeed(dspeed/100*0.9) # and set type for simple DC Motors if "DC" in devices[id]: motor[i].setType("DCMotor") motor[i].obj = DCMotor(port) except KeyError: motor[i].stype("unkown") print(port, ":", "Unknown device with ID", id) wait(100) print ("--") print(port, ":", devices[id], motor[i].getType(),motor[i].getSpeed(),motor[i].getAcc()) # ---- device ------------------------------------------- class device(): # store the device infos for each motor def __init__(self,port,dir): self.port = port self.dir = dir self.type="" self.speed=99 self.acc=99 self.obj="" def setType(self,x) : self.type = x def setSpeed(self,x): self.speed = x def setAcc(self,x) : self.acc = x def getType(self) : return self.type def getPort(self) : return self.port def getDir(self) : return self.dir def getSpeed(self) : return self.speed def getAcc(self) : return self.acc # ----------------------------------------------- # globals # ----------------------------------------------- v = 0 vold = 0 #remoteConnected = False # ----------------------------------------------- # Ininitialize # ----------------------------------------------- hub = CityHub() #define timers timer = [0,0,0] timer[1] = delay(1) timer[2] = delay(2) #define motors motor = [0,0,0] motor[1] = device(Port.A,dirMotorA) motor[2] = device(Port.B,dirMotorB) # get the port properties portcheck(1) portcheck(2) # ----------------------------------------------- # remote connect # ----------------------------------------------- hub.light.on(Color.RED) print (hub.system.name()) try: remote = Remote(name=remoteName,timeout=remoteTimeout*1000) except OSError as ex: hub.system.shutdown() # ----------------------------------------------- # main loop # ----------------------------------------------- while True: # --check if remote is connected --------------------------------- try: button = remote.buttons.pressed() hub.light.on(LEDconn) remoteConnected = True except OSError as ex: hub.light.on(LEDnotconn) print("Remote not connected") remoteConnected = False if watchdog == True: v=0 drive() try: # reconnect remote remote = Remote(timeout=1000) wait(100) print("Remote reconnected") remoteConnected = True except OSError as ex: print("Remote not connected") if CheckButton(SWITCH): mode = mode+1 if mode > 2: mode = 1 print (mode) if mode == 1 : remote.light.on(LED_A) if mode == 2 : remote.light.on(LED_B) while CheckButton(SWITCH): button = remote.buttons.pressed() wait (100) if mode == 1 : function1() if mode == 2 : function1() wait(10)

I don't know what you mean. My idea is: flash HUB_A once(!) with the desired public program, which has some parameters (ports, buttons, speed etc), all stored in system.storage The programmer serves also a website (I use a Excel-Macro) to configure, pressing the button "Finish" all values and a small program are written to the clipboard. Then - connect a second hub to the browser - insert clipboard - run program which does nothing but sending the parameter-string to HUB_A where it can be read in main loop and stored. So: Flash only once, configure as often as desired.

Hi all, when starting with python and the program “motor control” I started to consider a kind of structure to be reused in other projects and all be parametrized easily. And so decided to use following structure: Parameters Function Routines and classes Main As an example, a simple program to start and stop all kind of motors on all ports of a city hub (without any code of classes) v = 30 dirMotorA = 1 # Direction 1 or -1 dirMotorB = -1 # Direction 1 or -1 START = "B+" STOP = "B0" function: if CheckButton(START): drive(v) if CheckButton(STOP): drive(0) wait (100) # ----------------------------------------------- # classes and routines # ----------------------------------------------- def CheckButton(x): class delay: def drive(): def portcheck(i): class device(): class (remote): # Ininitialize motor = [0,0,0] motor[1] = device(Port.A,dirMotorA) motor[2] = device(Port.B,dirMotorB) portcheck(1) portcheck(2) # ----------------------------------------------- # Main # ----------------------------------------------- while True: remote() function() wait(10) As you can see all parameter are at the beginning, "function" is the actual “user program”. All other is something that would normally be located in libraries, but as far as I know it is not possible in Pybricks – or am I wrong? Where is the benefit? There are routines to detect motors, determine their types, handle .dc and .run depending on what is connected, reconnect the remote, timers and so on, which could be the easily reused by others . Would it be reasonable to expand the idea and write such classes to be shared by many users? And even users who have no experience in python they should be able to change the parameters according to their needs.