vascolp

I agree with you... Maybe only a reference to the shock absorber with tight coils?

You are pretty close! You can get two or three more with this query on bricklink: bricklink

Hi everybody, When I saw this thread some days ago I played a litle with the idea, trying to do it with the parts I have. Yesterday I continued playing and did this (careful noisy!) : The parts: One drawback might be the usage of a String with End Stud and Bar 1L, 13L Overall. I have one that I got in some used lego lot... I didn´t now they were so expensive. Hope you like it!

Cool! I am currently living with the 14 bytes of the remote but only with a lot of enconding. 128 or 256 bytes seems enough for most cases I think.

There are lots of examples. You can, for instance, peek this zetros example and remove the stuff related with steering and locking. Since you want the motors in the opposite direction, change the creation of one of the motors to: drive_motor2 = Motor(Port.B, Direction.COUNTERCLOCKWISE) You could also try my Remote Bla Bla which allows you to configure a hub without a mobilephone. But you will need a TechnicHub even to configure a CityHub (not enough memory on the CityHub...).

Ok thank you. That seems indid the correct approach. I will start to use those values. Currently only on beta version, right?

Cool, thats an improvment! I just tested for the two motors I have at hand: I get: pybricks: 47 - Technic Control+ XL Motor:1525 76 - Technic Large Angular motor: 970 The values I used were 90% of philohome no-load characteristics, which are: 47 - Technic Control+ XL Motor: 1980 (330*6) 76 - Technic Large Angular motor: 1278 (213*6) What is the rationale of your values? Note, I am not telling that my rationale is better (on the contrary as I have no way of mesuring speeds). Just trying to learn. Thanks!

Good question! I think there is no generic solution for that. I do it like this (using excelent Philo stuff!): # Mode _bla_STP_SPEED assumes maximum speeds for each type of motor. # There are lots of motors, each one with its own characteristics, which makes it a bit difficult # to have a general purpose thing... # I got no-load speeds in https://www.philohome.com/motors/motorcomp.htm, multiplied by 0.9 # and got a list of maximum speeds per device. If the device does not match... it uses 1000deg/s (why not?). # # 1 Powered Up Medium Motor # 2 Powered Up Train Motor # 38 BOOST Interactive Motor # 46 Technic Control+ Large Motor # 47 Technic Control+ XL Motor # 48 SPIKE Prime Medium Motor # 49 SPIKE Prime Large Motor # 75 Technic Medium Angular Motor, gray # 76 Technic Large Angular motor, gray devs_max_speed = { 38:1377, 46:1700, 47:1780, 48:1230, 49:1150, 75:1230, 76:1150 } I got the above list of id numbers somewhere from pybricks github stuff, but I can´t find it right now ... You can get that id number from a port by doing: PUPDevice(Port.A).info()['id'] So, to get a device maxium speed on Port A I do: s=devs_max_speed.get(PUPDevice(Ports.A).info()['id'], 1000) Hope it helps!

That is strange. In my experience, doing: m1.control.limits(speed=2000) before calling run() should work. Try also changing the acceleration, if I remember the default is a bit slow m1.control.limits(speed=2000, acceleration=2000) Have fun!

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) Cool to see it alive! The approach described by @gyenesvi is definitely better... in fact thats what I use too.....

@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!

As a first approach you could try trunc(angle/90)*90. It requires: from math import trunc Good luck!

5: 3 6: 2 9: 4 19: 10 24: 6 30: 1 Incredible quality of all entries, congratulations to all!

Thank you!

I Everybody! This is an RC version of LEGO 42104 Race Truck. Motorization is controlled by pybricks program Remote Bla Bla, so controlling is done by the LEGO Handset, no need for a mobile phone device. It was fun to include a hub and two motors in such a small scale, although the driving motor is kind of outboard. At the beginning it feels a bit clumsy compared to the original set but one gets used to it. It's a cute little truck! Steering at this scale is a bit wobbly, but it works fine enough. I wonder how it would be with the Small Angular Motor for steering. Probably both motors could fit... but I don't have one. Steering motor is embedded in the chassis. Drive motor is outboard in the rear. Two configurations are presented: Simple Drive Mode: Drive motor with two modes:on and off Steped Drive Mode: Drive motor with seven power steps More pictures in bricksafe; Instructions in rebrickable; Remote Bla Bla in github; Some pictures: and a video: Have fun!