David Lechner

Yes indeed. This is what I tried to do in the EV3 Classroom example I posted, except it tries harder to make sure each motor runs exactly one rotation.

Try this for screenshot: https://1drv.ms/u/s!ApX9UuctkzDDkCqdHnBh8L229mjh Und auf Deutsch: https://1drv.ms/u/s!ApX9UuctkzDDkCmCjsYH67HJsbRM The same thing will happen with the EV3 Lab software if you try to use Move Steering or Move Tank with 4 motors at the same time. The second block with 2 motors will interrupt the first block with the other two motors.

Can you use broadcasts to make the actions run in parallel? hmm... I can't upload the rest due due to upload size limit.

Cool. Nice to see you figured out the send() method for generator functions too! Link seems broken. Here is a new one: https://github.com/arturomoncadatorres/lego-mindstorms/blob/main/base/charlie/programs/drum_solo.py

Perhaps you could try logging the data and graph it. A visualization may provide some insight as to what is going on. This is EV3, but you get the idea... https://www.ev3dev.org/projects/2016/08/07/Mapping/

There is a limitation in the EV3 firmware that makes it so that only one pair of motors can be used at a time. When the second block with ports B and D starts, it stops the motors on ports A and C and replaces them with B and D. You can try using the single motor control blocks instead.

It sounds like you understand pretty well how the sensor works. Basically, if you don't have a single, large, flat, perpendicular surface, then you get lots of noise and lost signals as you have seen. Ultrasonic sensors are really for measuring distance, not detecting arbitrary objects. If you are into hardware hacking, the ultrasonic sensor comes apart and has a pin header to allow connecting other hardware. Maybe you could add better sensor such as a camera or lidar. Example: https://ceeoinnovations.github.io/projects/Backpacktest.html

Have a look at to see how to calibrate the motors.

Your understanding as described in 1) is correct. You will have to make your own replacements for blocking (long-running) functions that use yield instead. For example, wait_for_... is replaced with while not ...: yield. Writing code this way does take some getting used to, but it does have one nice advantage over threads. Threads can switch at any point, so extra locking mechanisms are often needed synchronize threads to avoid concurrency issues. But with generator functions, we know that a function will only pause at the yield keyword, so many of these concurrency issues are never a problem to begin with. I don't know of anything will code completion for the Robot Inventor yet. (But it is on our roadmap at Pybricks.)

The Python that runs on SPIKE Prime and MINDSTORMS Robot Inventor is actually MicroPython rather than regular Python. And it doesn't have threading enabled, so threads are not an option for the MINDSTORMS Robot Inventor hub. One common way to do this in Python without threading is to use generator functions as coroutines. Here is an example for SPIKE Prime I made a while ago: https://gist.github.com/dlech/fa48f9b2a3a661c79c2c5880684b63ae

Pybricks runs on MicroPython, so regular NumPy for Python won't work with it. If you are using Python 3 on the EV3, you can install NumPy with: sudo apt update sudo apt install python3-numpy There is a numpy-like library for MicroPython at https://github.com/v923z/micropython-ulab but you will need to compile it yourself. Pybricks 3.x will also have a basic Matrix class, but EV3 isn't the focus of the 3.x release, so some things may be broken. You can find daily builds of the `pybricks-micropython` executable for EV3 at https://github.com/pybricks/pybricks-micropython/actions?query=is%3Asuccess+branch%3Amaster+workflow%3ABuild. (Click on a build then scroll down to "Artifacts" and download "pybricks-micropython".

For brick-to-brick communication, see https://pybricks.github.io/ev3-micropython/messaging.html

There is no Python involved in EV3 Classroom.

I used the same program as in your blog post with motor on port A and color sensor on port 3. But also with additional motors on ports C and D. Same firmware and EV3 Classroom version.

I was able to reproduce this bug. I also had additional motors plugged in and I was surprised to see that the motor on port C moved instead of the motor on Port A. So I think what is happening here is that the motor block is using the port from the sensor block (3 = C) for some reason (since the sensor block is "in" the motor block, so to speak). But the workaround you came up with to move the sensor reporter block outside of the motor block does indeed fix it.

Looking good.

Python tip 1: The range function provides the next number in each iteration of the loop, so instead of count = 0 for x in range(10): print(my_list[count]) count += 1 You can write: for x in range(10): print(my_list[x]) which leads to... Python tip 2: Lists are iterators, so instead of using for x in range(10): print(my_list[x]) You can do this: for item in my_list: print(item) Python tip 3: You can use the print function to print to a file print("stuff", file=my_file) This will automatically add the newline. Putting this all together with open("my-file", "w") as f: for item in list: print(item, file=f) The title also mentioned backwards: with open("my-file", "w") as f: for item in reversed(list): print(item, file=f)

I think display.rotation() is equivalent to the "set orientation to" block rather than the "rotate orientation" block.

Where is the thumbs up button? That is a really nice looking plane.

The port numbers are 100 times the brick number plus the port number (convert letters to numbers for output ports). So ports on the 2nd brick should be 201, 202, etc. Only the input and output ports can be used directly in daisy-chain mode, not the display, sound, buttons or lights. But you can write programs that use message blocks to send messages between EV3s to accomplish the same thing.

This could be done quite simply with any programming language. Using MicroPython/Python as an example, you could use the `print` and `input` functions to print to a terminal window and read user input. If using the ev3dev-browser extension for VS Code, be sure to set "interactiveTerminal": "true" in `.vscode/launch.json`, otherwise input won't work.

There is also a copy of the official LEGO docs for v2.0 at https://pybricks.github.io/ev3-micropython/

If medium motors have enough torque, you could use them instead. They are about 150% faster.

mindsensors sells cables with more flexible wiring http://www.mindsensors.com/42-connectivity

https://bricks.stackexchange.com/a/11417/3498