Lok24 Posted January 29, 2022 Posted January 29, 2022 (edited) 29 minutes ago, Pybricks said: The main issue is that the City Hub, Move Hub, and Technic Hub do not have dedicated storage space for this kind of thing. There should be at least the 14 bytes for the hub name (i.E. "Pybricks Hub" somewhere ? ( I think the remote as well has no dedicated storage? And there it works!) Edited January 29, 2022 by Lok24 Quote
Pybricks Posted January 29, 2022 Author Posted January 29, 2022 It's not a matter of whether it's possible, but whether it's recommended . We always strive to make Pybricks 100% safe for everyone. This means that we use motors, sensors, lights, storage, and so on, within the same limits as the original application or firmware. If LEGO supported storing user code or data on the City Hub/Move Hub/Technic Hub from their apps, perhaps we will allow it as well. If you want a small hub with dedicated storage, you can also consider using the Essential Hub. Quote
Lok24 Posted January 29, 2022 Posted January 29, 2022 (edited) 13 minutes ago, Pybricks said: We always strive to make Pybricks 100% safe for everyone. This means that we use motors, sensors, lights, storage, and so on, within the same limits as the original application or firmware. Perhaps a missunderstanding? The LEGO Powered Up app allows the user to change the name of the hub and store it permanently. Or does your reply belong to another topic in this thread? Edited January 29, 2022 by Lok24 Quote
Pybricks Posted January 29, 2022 Author Posted January 29, 2022 Quote The LEGO Powered Up app allows the user to change the name of the hub and store it permanently. You can't set it from within the user program. Just like updating the firmware, changing the name occasionally is totally fine. But allowing users to do it in a loop that can run thousands of times per second is a different story. As I've mentioned before, perhaps you can consider alternatives. We've opened a dedicated discussion for preserving data using a low power mode here. Quote
Lok24 Posted January 29, 2022 Posted January 29, 2022 Hi, thanks for that , sounds interesting. But "low power mode" means what? The complete idea is useful only when working even when batteries had been removed . Quote
Pybricks Posted January 29, 2022 Author Posted January 29, 2022 Since it's just an idea at this point, it's probably better to follow the link mentioned above for further discussion and questions about the low power mode. Quote
vladoniki Posted February 9, 2022 Posted February 9, 2022 Is there a way to convert program made in Lego PoweredUp app to Pybricks (I can not type programs like code), any tool/app? Thanks! :) Quote
Pybricks Posted February 18, 2022 Author Posted February 18, 2022 Do you mean converting any program automatically, or just this one in particular? This example code be translated as: from pybricks.pupdevices import Motor, ColorDistanceSensor from pybricks.parameters import Color, Port from pybricks.tools import wait # Initialize the devices. motor = Motor(Port.B) sensor = ColorDistanceSensor(Port.A) # Repeat forever. while True: # Wait for the sensor to see red. while sensor.color() != Color.RED: wait(10) # Wait 0.1 seconds. wait(100) # Run the motor backwards at 500 degrees per second, for 120 degrees. motor.run_angle(-500, 120) # Wait 0.1 seconds. wait(100) # Run the motor forward at 500 degrees per second, for 120 degrees. motor.run_angle(500, 120) I would encourage you to try out some of the examples in the documentation, and modify a few values and commands to learn how it works. Theoretically, we could develop a block language for Pybricks. But since the Powered Up app has something like that already, we will probably focus on other priorities. Quote
shroomzofdoom Posted June 21, 2022 Posted June 21, 2022 (edited) Hello everyone. I was a bit hesitant to install pybricks at first due to my somewhat primitive programming skills. But I'm ALL IN and have installed on all 8 of my compatible hubs! I love the PUP remote, the fast startup, the fact that I don't need my phone---- it's SOOO much easier than coding with the MS and PUP apps! Suggestion: someone asked above about downloading code. It's not perfect, but I cut/paste into Notepad++, format the files as .py and keep them on my C drive. Now for the favor... I've built a sequential 4 speed transmission to control an off road truck. For shifting, I'm controlling the orange Chiron selector with a small angular motor (45607). It drives great, but now I'd like to add the ability to display the current gear (1, 2, 3, 4) on the hub matrix display using: hub.display.char("1"), hub.display.char("2"), etc I've tried various methods such as reading the motor's encoder in the main loop and I've also tried implementing display changes from within the shifting subroutine. I'm bumping into issues because of the inexact readings from encoder (-87, -267, -184, -448) and for example, the 4>1 and 1>4 shifts because of the sequential nature. I've isolated just the shifting stuff from the main program and deleted all my failed code. I can include the whole piece of code if you think it would help but figured this would be easier to read. Any suggestions or direction would be greatly appreciated. Thank you kindly for any suggestions! # a program to use motor with rotation sensor to control a 4 speed sequential transmission from the PUP remote # display '1' on the prime hub matrix display while in first gear (0 deg) # display '2' on the prime hub matrix display while in second gear (90 deg) # display '3' on the prime hub matrix display while in third gear (180 deg) # display '4' on the prime hub matrix display while in fourth gear (270 deg) from pybricks.pupdevices import * from pybricks.parameters import * from pybricks.tools import wait from pybricks.hubs import PrimeHub remoteControl = Remote() shifting = Motor(Port.A) hub = PrimeHub() #initialize shifting motor to zero position so I start in first gear and display '1' on the hub matrix display shifting.run_target(300,0,then=Stop.BRAKE) hub.display.char("1") while True: pressed = remoteControl.buttons.pressed() angle = shifting.angle() # upshift by turning the shifting motor 90 degrees each time RIGHT button is pressed if Button.RIGHT in pressed: shifting.run_angle(1000, 90, then=Stop.HOLD, wait=True) angle = shifting.angle() print("Angle ",angle) # downshift turn the shifting motor 90 degrees each time LEFT button is pressed elif Button.LEFT in pressed: shifting.run_angle(1000, -90, then=Stop.HOLD, wait=True) angle = shifting.angle() print("Angle ",angle) else: shifting.brake # wait for 1/10 second to allow the shift to finish wait(100) Edited June 21, 2022 by shroomzofdoom Quote
vascolp Posted June 21, 2022 Posted June 21, 2022 As a first approach you could try trunc(angle/90)*90. It requires: from math import trunc Good luck! Quote
gyenesvi Posted June 22, 2022 Posted June 22, 2022 The above approach can work (note that the same thing could be achieved by simply taking the integer part of the division, that's what trunc does I believe: int(angle/90)*90, and then you don't need imports). However, I would use a completely different approach for gear shifting. In your approach, you are reading the motor position and doing +/- 90 degree shifts, which works in theory, but in reality it could have errors which accumulate after successive shifts. Instead, you could just tell the motor where to move exactly, because you know that. At least you could know that if you know what gear you are in, and where you want to shift. And that would also solve your other problem at the same time. So the key is you should maintain a program variable for your current gear, that would run from 1 to 4. Then you know that if you press the right button, you want to increase the gear, and if you press the left button, you want to decrease the gear (simply increment / decrement the variable). You can also add logic that you can not shift up from 4 or down from 1. You can initialize this variable to 1 for example. After that, you can easily calculate the angle you need to aim for: angle = (gear - 1) * 90. And then with a different command that should exist in Pybricks, you need to send the motor to the given absolute position given by angle. That way errors don't accumulate, no need for reading back the motor position, and you have the info to display the current gear too. Note that at startup, you should send the motor to angle 0 to be in sync with the initialized first gear, no matter where it was left off the previous time. Hope this helps! Quote
vascolp Posted June 22, 2022 Posted June 22, 2022 @gyenesvi is correct in everything! That means, don´t use run_angle() use run_target(). Notice the following. run_target() will choose the best path. So, for instance, when you turn it on, if your gearbox was left on 4th gear, the run_target() will probably run from 4th to 1st (instead of 3rd, 2nd, 1st). If you have a physical limiter to avoid jumps from 4th to 1st this might be a problem… On the other hand, if you have a physical limiter, you can use the run_until_stalled() method with a negative speed to go back to 1st speed and then do a reset_angle(0). This will set the zero to the current position, so you do not need to care with absolute zero of your motor, which might be useful sometimes. Lots of stuff to play with! Quote
gyenesvi Posted June 22, 2022 Posted June 22, 2022 3 hours ago, vascolp said: Notice the following. run_target() will choose the best path. So, for instance, when you turn it on, if your gearbox was left on 4th gear, the run_target() will probably run from 4th to 1st (instead of 3rd, 2nd, 1st). If you have a physical limiter to avoid jumps from 4th to 1st this might be a problem… I'd say if you have a physical limiter, and you can only shift up/down with two buttons as you described, then the problem does not exist, because you won't be even able to try to go from 4th to 1st (unless you explicitly program it in a way that incrementing 4 becomes 1). So given that, you'll have to go through 3rd and 2nd to get to 1st. On the other hand, if you want to go from 4th to 1st, then you probably built it without a limiter :) so the problem does not exist again. I guess it's best if the software logic matches the built hardware, then things become simple, and no need for heuristics. 4 hours ago, vascolp said: On the other hand, if you have a physical limiter, you can use the run_until_stalled() method with a negative speed to go back to 1st speed and then do a reset_angle(0). This will set the zero to the current position, so you do not need to care with absolute zero of your motor, which might be useful sometimes. So this trick would only be required if you have a build with limiters that you cannot / don't want to change and have buttons that allow changing directly to any gear. Quote
shroomzofdoom Posted June 22, 2022 Posted June 22, 2022 (edited) On 6/21/2022 at 2:36 PM, vascolp said: As a first approach you could try trunc(angle/90)*90. Thanks for the lead @vascolp! This approach took me further than I could've gone on my own and I really appreciate it. Rather than clutter up this thread with code blocks I hosted the snippet on an external site I recorded it with the terminal in the background so you can see how it worked out. I had some accuracy concerns with this approach. Although I'm pretty sure the accuracy has a lot to do with my garbage coding skills and the memory used to keep printing the results to the terminal: angle = shifting.angle() tangle = trunc(angle/90)*90 When I took the print function out, it worked better but I still have the problems that @gyenesvi mentioned. 11 hours ago, gyenesvi said: So the key is you should maintain a program variable for your current gear, that would run from 1 to 4. Then you know that if you press the right button, you want to increase the gear, and if you press the left button, you want to decrease the gear (simply increment / decrement the variable). You can also add logic that you can not shift up from 4 or down from 1. You can initialize this variable to 1 for example. I figured it would be something like this but I was struggling with the exact implementation. This gets me pointed in the right direction. A million thanks! There's a reason that I buy MOCs from you, rather than the other way around. 2 hours ago, gyenesvi said: I'd say if you have a physical limiter, and you can only shift up/down with two buttons as you described, then the problem does not exist, because you won't be even able to try to go from 4th to 1st (unless you explicitly program it in a way that incrementing 4 becomes 1). So given that, you'll have to go through 3rd and 2nd to get to 1st. Not sure why I didn't think of this solution, thank you for the suggestion! I am going to redesign the location of the shifting motor to include a physical limiter to prevent the shift between 1 and 4. The transmission is rock solid and there is no slipping, however the backlash that occurs during this shift is significant (lots of power) and will likely lead to destruction while I am button mashing. BTW the truck is a modified 42070 chassis, slightly elongated to accommodate massive 11.5cm wheels. No center diff (of course) and all drive axles are fully locked. I'm using 4 Technic L motors for power, meshed through 16t gears. I was sure to use no axle longer than 7M to support high torque. A Technic angular motor for steering, and the Technic/Education small angular motor to shift. Edited June 22, 2022 by shroomzofdoom Quote
vascolp Posted June 22, 2022 Posted June 22, 2022 2 hours ago, gyenesvi said: I'd say if you have a physical limiter, and you can only shift up/down with two buttons as you described, then the problem does not exist, because you won't be even able to try to go from 4th to 1st (unless you explicitly program it in a way that incrementing 4 becomes 1). So given that, you'll have to go through 3rd and 2nd to get to 1st. Careful. The problem does exist as I described… not while playing but at initialization time, if you just do a run_target(0) and it happens to be in 4th. It is not difficult to avoid it, though. For instance do this at initialization: d.reset_angle() # Set initial angle to absolute 0 if d.angle()<0: # Go to absolute zero always in backwards direction d.run_angle(-300, 180, Stop.COAST, True) d.reset_angle() d.run_target(300, 0, Stop.COAST, True) 22 minutes ago, shroomzofdoom said: I recorded it with the terminal in the background so you can see how it worked out. I had some accuracy concerns with this approach. Although I'm pretty sure the accuracy has a lot to do with my garbage coding skills and the memory used to keep printing the results to the terminal: Cool to see it alive! The approach described by @gyenesvi is definitely better... in fact thats what I use too..... Quote
Polarlicht Posted June 23, 2022 Posted June 23, 2022 (edited) @PybricksRan into a problem with the CAT. You know i was finally anle to install the code couple of days ago. Today got my rc controller from a train set. I turn the cat hub on, turn the RC on but nothing happens when i press +or -. Hub blinks blue, RC blinks white. Works fine with the Volvo Dumper. Edited June 23, 2022 by Polarlicht Quote
Lok24 Posted June 23, 2022 Posted June 23, 2022 With a pybricks program? Or just hub and LEGO RC? And how do you connect the RC with the Volvo? Is this a new FW which allows that? Quote
Polarlicht Posted June 23, 2022 Posted June 23, 2022 (edited) Yes, with the premade pybricks code. Got my RC Controller today (lego train controller). Reinstalled the software on the hub with the cat programm. But still hub and controller won't find each other. Volvo: i turn its hub on, press the green button on the remote and turn the hub on a second time, and it works great. I do the same with the cat, but does not work Edited June 23, 2022 by Polarlicht Quote
Lok24 Posted June 23, 2022 Posted June 23, 2022 9 minutes ago, Polarlicht said: Yes, with the premade pybricks code. Ah, never heard of that; where did you find it? Quote
Polarlicht Posted June 23, 2022 Posted June 23, 2022 What? This is the pybricks qa! not about the lego software! Quote
Lok24 Posted June 23, 2022 Posted June 23, 2022 Yes, just fond it, here: https://pybricks.com/projects/sets/technic/42131-cat-bulldozer/ Quote
Polarlicht Posted June 23, 2022 Posted June 23, 2022 yes i used this code, but maybe there is a typo somwhere? I don't know. Somebody the same problem? Quote
Lok24 Posted June 23, 2022 Posted June 23, 2022 yes, it's a strange behaviour, code seems ok for me, sometime it connects, often it does not. Quote
Polarlicht Posted June 23, 2022 Posted June 23, 2022 I reinstalled it several times. Even reinstalled the lego software again and then pybricks again... Quote
Polarlicht Posted June 23, 2022 Posted June 23, 2022 2 hours ago, Lok24 said: yes, it's a strange behaviour, code seems ok for me, sometime it connects, often it does not. Maybe i messed something up with the code! I had a pre-filled code site for the volvo. That worked fine. I did not had this for the CAT. I copied the code to the code site myself. I had indentation errors or something at first. Than i removed all unnecesary spacing, and i was able to install it on the CAT, with no errors. But it does not work. Please, is there a way someone could just give me a pre-filled code site on pybricks for the CAT? Please!!! Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.