Search the Community
Showing results for tags 'pybricks'.
Found 10 results
-
I wanted to make a excavator as small as I could with PoweredUp and 8 functions, this is the result (so far). It's not based on any real life model. It uses 2 Technic hubs with Pybricks. One hub in the undercarriage and one in the superstructure. The hub in the base does the following: Drive with 2x L-motor (motors inside the tracks based on this design from crazy technic) M-motor for turning the superstructure M-motor for blade lift The hub in the superstructure has the following motors: 1 L-motor to lift the base of the arm 1 L-motor for the two-piece boom lift 1 L-motor for the stick (hidden in the first part of the arm) 1 L-motor for the bucket (M-motor would have been sufficient, but the wire is shorter of a M-motor, which would make it to the hub barely, this L-motor is in the second part of the arm) A little video with a basic demonstration of the functions: A few more pictures Interior can house a Technic fig. Easy access for a battery swap for the hub in the superstructure (on/off button is reachable from below, I might make a little mechanism at some point, but so far I like being able to just use my indexfinger to turn on the hubs). A deeper look below the bodywork: A few shots of the arm positions: Folded Maximum height All LA's at maximum extension results in a bucket being level to the ground Maximum reach Ideally it would reach the ground in this case, but 7 studs from the floor was the best compromise I think with how the boom stands when upright. In order to reach the ground I only need to turn in the "two-piece boom" LA about 0.5 studs in this case. The blade sadly is unable to lift the model. It's a wormgear on a 8T gear. Maybe it would be able to if I replace the M-motor with a L-motor. I am currently considering it, since it would fit in the undercarriage, but where the extra wire length of the L-motor was a boon for the motor in the arm, it might be too much to cram in the undercarriage. At one point I had a mini-LA in the undercarriage for the blade, but I wasn't satified with the kinematics of the blade and the general look of the attachment point of the LA. That mini-LA mounting point would have been about 2 studs above the desired (current) height of the blade. Here's an image of an earlier version of the undercarriage with the mini-LA: It was too far forward to be ideally functional, but I had very limited options to move it further back, wires (from one of the L-motors that handled drive) were in the way and/or I was sacrificing structural integrity, both not what I wanted. Rear view of the underside: In the final version the wires near the end of the the undercarriage are secured below some bars I inserted into some half pins. As you can see near the turntable I placed a bar accross the entire width of the hub so it wouldn't ever get caught on the turntable. Besides the thing with the blade, there's another issue I still want to tackle. If the arm is at "maximum reach" and I turn the superstructure 180 degrees (facing backwards), the 12T bevelgear on the turntable will skip. This is pretty much the only scenario in which it does this since I moved the whole superstructure backwards 1 stud (it would do it any position of the arm before at times). I am considering a few options to fix this like the good old, but still in production (at least until 2021) Lego weight bricks or perhaps add another kind of support (like a wheel) bel;ow the superstructure that can run over a closed off front and rear of the undercarriage (in which case I will need a mechanism to turn on the hubs). There's also another little issue with the turntable, which wobbles a little in certain spots of turning. It would even do this without a superstructure on top. Swirling the turntable a bit in hand and then putting it back would make it go away for a while, but it's not a permanent fix. Funny enough I found this problem with another turntable before I even started working on a superstructure and replaced it for this one which didn't have the problem, at first at least Maybe a slightly better balance with the rear would help with this problem as well, but adding those weight bricks for example would mean adjusting the body work and I like how it looks now A video will have to wait a bit as I want to brainstorm a bit more about these issues. I do consider these issues pretty minor though. The wobble I don't really mind. A buddy suggested teflon spray to tackle that, but since I am not really losing any cargo while it wobbles, it's not a big deal to me. The skipping 12T bevelgear for a maximum reach arm turning to the rear of the model is a pretty niche situation I think (would an operator of an excavator normally even do this except for fun?), but I never like a skipping gear so I would avoid that scenario if I can't fix it. The blade not being able to lift also annoys me a little. It's still doing what I wanted it to do: act as a bulldozer in time of need, but still. The blade isn't even needed to prevent the model from falling over, but I still think it should be able to lift the model, but I can't think of a solution in the given space and desired blade kinematics besides slapping in a L-motor and hoping it does have enough power to move it. As always, thanks for reading and looking at my pictures -
I'm busy with automating a LEGO railway crossing and have therefore written the code below. This code works fine, but motor D starts only when motor A is finished. Are there possibilities to start both motors at the same time? #!/usr/bin/env pybricks-micropython from pybricks.hubs import EV3Brick from pybricks.ev3devices import (Motor, TouchSensor, ColorSensor, InfraredSensor, UltrasonicSensor, GyroSensor) from pybricks.parameters import Port, Stop, Direction, Button, Color from pybricks.tools import wait, StopWatch, DataLog from pybricks.robotics import DriveBase from pybricks.media.ev3dev import SoundFile, ImageFile # Initialize the EV3 Brick. ev3 = EV3Brick() sensor_1 = UltrasonicSensor(Port.S1) motor_A = Motor(Port.A) motor_D = Motor(Port.D) # parameters speed = 6*165*10 # [deg/s] rotation_angle = 24*90 # gear ratio 24:1 dis_track_1 = 65 # [mm] t1 = 10*1000 # [sec] while True: if sensor_1.distance() < dis_track_1: # close railway crossing ev3.light.on(Color.RED) motor_A.run_angle(speed=speed, rotation_angle=-rotation_angle, then=Stop.HOLD, wait=True) motor_D.run_angle(speed=speed, rotation_angle=-rotation_angle, then=Stop.HOLD, wait=True) # wait 10 seconds wait(t1) # open railway crossing motor_A.run_angle(speed=speed, rotation_angle=rotation_angle, then=Stop.HOLD, wait=True) motor_D.run_angle(speed=speed, rotation_angle=rotation_angle, then=Stop.HOLD, wait=True) ev3.light.on(Color.GREEN) -
It's not a scale model of a real life model, though @nico71 mentioned it looked like a Kraz in the comments of Mahjqa's video and I do see the resemblance. It features the following functions: Drive with a L-motor to the rear axles (no AWD). Steered front axle with a L-motor. M-motor for dumping the load with a LA. All axles have pendular suspension with the front axles using actual springs and and at the rear the 2L rubber liftarms to "dampen" the pendular axles a little bit (idea stolen from this MOC/WIP from Jundis). Movement of these rubbers is limited to prevent tyres rubbing the chassis when an axle is tilted. Working headlights Self locking tailgate from @ludov (I don't know if he came up with it, but I did steal it from him ) (center axle also has a thin white liftarm under the tyre at the rear) The self locking mechanism from Ludov works like this: LBG is the bed, yellow is the chassis and white is the lock. The bed is connected to the chassis at the end of the yellow connector and the lock can tilt 1 stud ahead of that which means that it drops further down than the bed would. Thanks for watching and reading. Hope you like it
-
Seeing a delta robot in real life finally made me try to built one myself. As it's not only a model but (more or less) complicated robotics as well, i'm learning a lot. But first, here's a clip of the current state: (Some day i will learn proper lighting, filming and editing. But not during this project) The project started with a proof of concept, just to get a feel for the mechanics at play. Here i understood how the twin rods on each arm remove all rotational degrees of freedom by only allowing parallel movements. As i was pondering whether to revive my old RCX or investing in used mindstorms, i remembered the existence of pybricks. And oh boy is it great! I was prepared for an evening of IDE installs and debugging, but everythinig just worked All it needed was a bluetooth dongle, a Windows restart and the browser (although i prefer the offline program to stay independent) I had the Control+ hub LED showing a rainbow not even 30 minutes after i started this endavour With this proof of concept, the next step was to actually build the delta robot. Although the end goal is to pick up parts with a pneumatic grapper, i concentrated on the movement platform for now. The result is very ... prototype-y. The whole assembly is held only by the + holes in those three Technic Beams in the very center: The motors just sit on the Technic Pins of the frame assembly, being held there by bent Technic beams I geared down the motors 3:5 for increased accuracy of the angle measurements and to give the mechanics more space to move: With the construction "completed" (i'll rebuild it once i feel like i know what i'm doing), there was nothing to do but maths. To move the platform to a specific point, each lever has to be in a specific point, with quite complex dependencies. There are two calculations you might have to make: Forward Kinematics: given the angle of each lever/motor, what is the position of the effector in space? Reverse Kinematics: given a specific point in space, what angle does each lever/motor have to be to get the effector there? Fortunately, i found this super interesting github repo, where someone much smarter than me implemented all the calculations in Python (and much more). I copied his reverse and forwards kinematics code directly into pybricks. But the different math libraries used made me uncertain of the results. So i tried to understand the calculations myself, for which i highly recommend this tutorial on a (defunct) robotics forum. Trying to test my code, i stumbled upon a problem i haven't been able to solve: i can't get reliable absolute angles of the XL motors. Upon startup the reported motor.angle()s are always different. According to the documentation, there is a way to reset motors to their absolute values with motor.reset_angle(), but only if they support it. So it seems the XL motors only show the differential angle? The documentation regarding those motors is very sparse. In one of the best collections of lego motor data, it is said that they have "an absolute encoder". Internally, they look as if they would support it, but i can't find anything about this (hall sensor?) IC online. @Pybricks, can you confirm or deny whether it's possible to get the motor position of an Powered Up L motor without manual calibration? Right now i implemented a manual calibration routine, which is a little bit annoying because i have to lift the whole robot in the air for it to work. Well, back to testing my kinematics code. The first test that came to mind was moving on a constant level. To detect deviations from the plane, i put a pen in the middle that would draw the shape i programmed, with the intensity of the line showing the quality of the movement. Fortunately i found this small, ten year old pen, that fit inside the effector quite easily: Only after doing my first test did i realise that i effectively built a printer Here's some more artwork: The latest setback were empty batteries from all my testing. Based on a model i can't find any more (sorry!), i designed and printed a dummy battery with an USB-C PD trigger board set to 9V. Now i can supply the energy straight from a wall plug. Much more economic with all the debugging i have to do. So, what's next? Implement smooth movement: have the hub calculate the next movement during the current one and understand where this start-stop behaviour comes from Understanding the behaviour of track_target() and run_target() together with multasking and coroutines seem to be the best bet here. Build a pneumatic gripper (and buy/steal/accuire the motor for it) It has to be fast acting and work with one motor allone. Finally a legitimate reason to use an airtank Find something to grip and move that fits in the relatively small action radius I was thinking of something along the lines of Tower of Hanoi, with different colored stacks of pulley wheels (although they might be to big) -
It is a bit embarrassing to say, but I started this model back in November... 2022. It took a lot more work to get the tall lifts to work and for the whole model to run reliably. In the video I show all of the mistakes and learnings made along the way. I have tried to make it as entertaining as possible, and I hope, that you enjoy it. The model started with me wanting to see how many trains can loop or pass through the same point at the same time. A shortage of space was coming up early, and the modified loops required a lot of additional speed for the trains to clear reliably. But with increased speed, also came increased friction, and if you look closely, you can see how much the trains have deposited of red ABS on the sides of the loop tracks! The roller coaster is activated using the "color distance sensor" from LEGO Boost. This sensor is great at communicating when it can be activated, and in my field test, visitors had an easy time figuring out how to interact with the model. Some children stayed for quite some time and activated the roller coaster whenever the light shined green. Unfortunately the model was not yet reliable when it was exhibited, so it required me to be on-site at all times. This latest version should be much better for public display. Only time will tell. If it turns out to be a success at event, then I would like to make it even more complicated with more trains in the "knot". Do you have any good ideas to how to add trains without risking collisions?
-
Hey Guys. I have been working on this project on and off since September of 2021. It is not my first MOC, but the first I care to show off here as I feel it is of a sufficient standard. Small Powered Up Shunter - Pybricks Control The brief was originally a clone of @BrickPirate's Small PF Shunter, and I was indeed using Power Functions parts in the beginning. As there were no instructions or files available, I reverse engineered what I could and went on from there. Then I decided I didn't want the smallest shunter ever, just the smallest on my layout. I also liked a more rounded styling and incorporated that into the design. The colour choice was pretty much determined by what I had to hand after designing a previous MOC (An Emerald Night clone in dark azure with a custom tender and 2L PF motors in the boiler). The white was to somewhat hide the Powered Up Hub in plain sight. The side covers are shamelessly ripped straight from the aforementioned MOC. I put a couple of round times with holes on the front long hood to allow the hub's light and power switches to be accessible. Previously I was removing tiles to access the power switch. Now I can use an axle or whatever I have to hand to power on and off. But there was a little unused space in the rear electrical box hood, so I made a little starting pin which can hide inside if I'm ever anywhere without a technic axle to hand! It just pops in the hole, then a couple of presses later the hub is powered on and the Pybricks program is started. The pin then gets stowed in the rear again until it is time to switch off. I originally had this on PF with a train motor in place, which I decided was just too fast and uncontrollable for slow shunting work. So I decided to put in a Powered Up linear motor. The medium was the only one which was able to fit. The square profile helps with fitment as it is only connected to the chassis physically by the axle to the drive gears. Otherwise it just sort of rests in there. The sided and rear short hood hold it in place against the back of the PU Hub. The wiring is a mess as it has nowhere to go but up in this configuration, but there's no room for a Minifig, so not too much of a sacrifice. The drive software is actually from another Train Tech thread. Control your trains without smart device - with Pybricks courtesy of @Lok24 With the custom profile they designed I can now move around the layout at reasonable speed pulling a consist, and then with a press of the centre button on the PU controller, I can switch into super low speed shunting mode. The benefits of the linear motor here are that the Hub will control voltage to keep the loco moving at the desired speed according to load. Plus the gear drive sounds a little bit like cooling fans spinning so I can pretend a little bit! Overall I'm quite happy with it for now, but I will probably end up changing out a few more things as time goes on. If I can get the motor mounted horizontally I may be able to get the drive line top a 4WD version, but I'm not holding out any hope. Poor little guy could really use 4WD! It can get stuck on points and does slip quite a bit if I load it up with too many pieces of rolling stock. I have custom traction bands on in place of the standard Lego ones for more grip but it does struggle for it sometimes. Thanks, hope you enjoy the pictures. I'll see if I can get a little running video together later on.
-
For all the C+ nerds out there, here is a quick demo for using the PoweredUp remote directly with the Control+ Technic Hub using PyBricks. This is the code I'm running on my motorised 42110 Land Rover but can be used with any model using 2 drive motors and 1 steering motor like the 42099 4X4 X-treme Off-Roader set. The code has two control modes: Bang Bang mode simply acts as an on/off controller similer to how the PowerFunctions remote worked in that it turns the drive motors on while the button is pressed and then turns them off when button is released, The steering motor also goes to full lock while the button is pressed and returns to centre when released. Precision Mode acts as a speed controller for the drive motors and provides 10 speed steps in either direction and increments to steering motor by 10° on each button press to give 8 angle steps. The red stop buttons act as emergency stop buttons and the green centre button is the control mode select. I have published the code to my Github account should you wish to download it and try it for yourself. Please make sure you configure the "User Definable Setting" and the " Initialize Motors" sections to suit your needs before running the code. This code is released under the MIT licence, so feel free to download, use, edit and share this code under the terms of the MIT licence, full licence details included in the repo. You can download the code here: https://github.com/MxWinters/PyBricks-Remote-Technic-Hub -
Hi everybody! I present to you Remote Bla Bla. Remote Bla Bla is a Pybricks (https://pybricks.com) program for a LEGO PoweredUp TechnicHub and a LEGO PoweredUp Remote Control where you first define how each device answers to remote control button actions (config mode) and then you play with your MOC/Set using the defined configuration (play mode). The configuration is saved so that you can turn off the hub, change batteries if needed, go back to your hub and everything is there. Just play. If the configuration is not what you want, you can go back to config mode and reconfigure the behavior. Keep in mind that this is a computer with an input device of 7 buttons and an output device of just two LEDs. This is a Star Trek like interface, a real YDSWIG interface: you don't see what you get. However, once you learn it, you will notice that it is simple. No screens attached! It is working with the latest release of pybricks (v3.1.0). Documentation here. Get it from here. Example usage video: Zetros controlled by Remote Bla Bla: Hope you like it, tell me what you fill about it. I will try to publish some usage examples later. PS: this is a pure software MOC, maybe it should be in the LEGO Mindstorms and Robotics Forum... but I have the feeling that most interested people are here in LEGO Technic Forum. Admins, tell me what you think. VascoLP -
Hey I purchased 60198 City cargo train set and I run may train either with the remote or with my smartphone powered up application. For me powered up has much more potential when used with pybricks. So I tried to use my city/train hub with pybricks to write some programs to run my train. Unfortunately, I got stuck on installing firmware for pybricks (bootloader). I followed guidelines from their webpage, so was holding green button till light started blinking in purple and then clicked "Install Pybricks firmware" button in Pybricks code webpage opened in my browser. Light on hub is blinking red/green/blue and there is shown progress in % (Pybricks code webpage) after it reaches 100% error message occurs: "Hub took too long to respond" and hub led blinks red/green/blue in infinite mode - you need to put off batteries to stop it. On Github pybricks/support I found whole topic regarding that error message "Hub took too long to respond" and probably there is solution to that problem but I am beginner at Python programming so don't know how to solve this problem. Should I write some kind of input file to get through that issues with bluetooth or other? They put some code file there but I totally do not know how to use it. Here is link to that support page: https://github.com/pybricks/support/issues/256 Any help welcome :) Regards
-
Hello, I want to learn PyBricks that seems to be a MicroPython Version. I'm novice here and want to find Information on Basics of the Language. For example : from mindstorms import MSHub, Motor, MotorPair, ColorSensor, DistanceSensor, App import hub as hb from mindstorms.control import wait_for_seconds, wait_until, Timer from mindstorms.operator import greater_than, greater_than_or_equal_to, less_than, less_than_or_equal_to, equal_to, not_equal_to import math So when I need some Functions of Library math, then I have to include them by import. But what is then difference to from mindstorms import MSHub ? And what is intention of from mindstorms.control import wait_for_seconds ? What is difference to from mindstorms import MSHub ? What commands are still included and has not to be imported ? Where can I find a Table/List/Overview about this ? Where can I find a Table/List what Modules are available for import and what they contains ? Sorry for this Newbe Questions, Jo
