EV3 w/ 3.3.0b5 Feedback

[shoringit]

Since I'm knee-deep in figuring out pybricks, I figured I might as well go all in and also look at v3.3.0b5. I'm working on evaluating moving to MicroPython from EV3-g for a school robotics team that I coach. I've taken this last season's robot, and successfully replicated it using pybricks v2, so that's definitely a good start. Then, I took that working code and tried to port it over to v3.3.0b5, using dlech's instructions. I have it working without too much work. I haven't done any in-depth testing or tuning, but I have the basic functionality working so I consider that a major win. I also like that I can switch back and forth between v2 and v3 using this method....

While I've been reading / learning, I've noticed quite a bit of interest in making the EV3 more active in future releases, and I whole-heartedly agree. To this end, I figured I'd give the developers on here some feedback for what I found working well and not so well... At this point, I plan on keeping the kids on v2 (due to reasons you'll see below), but I definitely see promise in switching to 3+ once some quirks are worked out and some of the newer features are updated for use on the EV3 (again, see below).

So, you know what I have been testing with, here's the robot specs:

• Sensor Port 1: Mindsensors ToF distance sensor
• Sensor Port 2: EV3 color sensor
• Sensor Port 3: EV3 color sensor
• Sensor Port 4: Empty
• Motor Port A: EV3 Medium Motor (gripper)
• Motor Port B: EV3 Large Motor (right drive)
• Motor Port C: EV3 Large Motor (left drive)
• Motor Port D: 2 Custom lighting circuits driven off the motor outputs (driven as a DC motor)
• The two large motors are driving tracks.
• The two color sensors are used as a differential line follower (keeps the line in between them)
• The ToF sensor is used to detect objects that we want to pick up.
• A 2nd EV3 module is used as a "remote" via Bluetooth - there is bidirectional communication (remote sends some commands, and the robot sends back status to be displayed on the remote's LCD)

With all that established, here is what I've found lacking / not working so far:

1. Loss of threading. I knew this was gone in V2, and it's a big loss to me. I was able to get things working without it, but they don't work as well as they did in v2 using the threading. The main issue here is that I had all the bluetooth receiving done in it's own thread so that commands could be acted upon nearly instantly. Now, they have to wait on some things.... If there's a way to put threading back (even if that means it's for EV3 only), please do. Using threading is way simpler than any other method for accomplishing this, which is important when you're trying to teach this stuff to 6th graders...

2. There seems to be either a bug or just a lack of documentation regarding robot.heading_control.limits(), robot.heading_control.pid(), etc. I am getting ValueError: Invalid argument errors when I specify what appear to be valid values. Specifying the defaults, work, but making them very large and I get that error. I'm guessing I'm exceeding a limit somewhere, but it's not clear at all what/why.

On this subject, I've seen people mention drastically different movements between V2 and V3, and after looking at the default PID differences, it's probably why... The v2 defaults are: kp (200), ki(600), kd(2), integral_range(6), integral_rate(1), feed_forward(0) where the v3 defaults are: kp (18708), ki (0), kd (2), integral_deadzone (2), integral_rate (3).

4. If I issue the command robot.stop(Stop.BRAKE), I get the error TypeError: function takes 1 positional arguments but 2 were given

And now with the bad out of the way, I'll focus on the good. I really like the robot.curve() function. For my use cases, that's the main advantage I've found so far. As a result, I don't see enough benefit for me to move to V3 over V2, especially when I lose threading...

So, based on what I've seen so far, I would recommend the following additions/changes to make V3+ more EV3 friendly:

1. Add back threading, even if it's only for EV3's.

2. Add the ability to specify an external gyro (Lego or aftermarket - I have this one for instance) for the GyroDriveBase() function. I helped the kids try and write this functionality in EV3-g (including PID control) this year, and it ended up being too much for them. Having it in one function like this would have saved us hours of work and made a much better end result...

To summarize: great job!!! While I don't see much need to move up to v3 for the EV3 yet, I'm blown away by the increased capability that we're going to have this year over using EV3-g language we used last year. The kids are going to have a learning curve, but they were held back by the capabilities of the language last year and that shouldn't be a problem this year...

Thanks,

Danny

[laurensvalk]

Thanks so much for your feedback! Glad to hear you are having fun with Pybricks 😄

I don't remember at the top off my head why threading has been disabled. As an alternative to threading, there will soon be cooperative multitasking as well. See https://github.com/orgs/pybricks/discussions/1166#discussioncomment-6495939 for an example. It's not completely implemented for EV3 yet, but it could be at some point.

As you may know, we released Pybricks 2.0 for EV3 together with LEGO Education. I think we're seeing a lot of people interested in a properly supported upgrade to 3.0 for EV3, but LEGO Education may not know about it. Here is one way to let them know: https://legoeducation.atlassian.net/servicedesk/customer/portal/3/create/51

[BertLindeman]

Entered

I have my EV3 running pybricks 2.0 on linux.

It would be so good to have the EV3 run pybricks V3.

And of course  at linux buster (or newer version)

So glad the EV3 is running pybricks.

[laurensvalk]

Thanks! For what it's worth, I think the LEGO solution is officially known as "Python for LEGO Education MINDSTORMS EV3", or sometimes just "EV3 MicroPython" for short.

These may be the names that customer service may know them by, when asking for updates :)

[shoringit]

I sent Lego Education a note about interest for v3 support and this was their reply:

Hi xxx , thanks for your feedback and suggestion! With LEGO® Education Mindstorms® EV3 retired, we are not actively developing EV3 MicroPython. We recognize our friends at PyBricks continue to develop and improve EV3 MicroPython builds. We currently do not have plans to partner with PyBricks to make an updated version. Our focus is on improving SPIKE™ Prime and Essential products.

Thanks for taking the time to write to us!

[BertLindeman]

Response to me was:

thanks for your feedback and suggestion! With LEGO® Education Mindstorms® EV3 retired, 
we are not actively developing EV3 MicroPython and have no plans to revisit this in the future. 
Our focus is on improving SPIKE™ Prime and Essential products. 
That said our friends at PyBricks are still active and updating builds for EV3 MicroPython. 
See https://github.com/orgs/pybricks/discussions/370 .

Happy building and coding!

Sadly.

Bert

[shoringit]

I had an idea today. It may be crazy and not possible - I don't know enough about Python yet to make that determination. So, I figured I'd mention it here in case it's not as crazy as I think it probably is.

My idea is that I continue to use v2 for most things, but use v3 for the DriveBase function. My thinking is that my main.py file would have the normal pybricks-micropython shebang. In the imports, have something like from drivebase3 import Drivebase3. In my folder, have drivebase3.py that has the pybricks-micropython3 shebang and the import contains the from pybricks.robotics import DriveBase. Then some code that would create a DriveBase3 class that would redirect to that DriveBase. I don't know what the constructors in that file would need to look like to make this work, or if it would work at all with the end result using both interpreters. As I said, my Python experience is too limited...

Like I said, it's probably a crazy ideas, but if there's a way to get my cake and eat it too, I'm all for it....

Thanks,

Danny

[dlech]

ImportError: no module named 'threading'

We have not packaged micropython-lib for pybricks-micropython3. Use the _thread module instead.

[dlech]

TypeError: function takes 1 positional arguments but 2 were given

This is one of the few breaking changes between v2 and v3. Change motor.stop(Stop.BRAKE) to motor.brake().

[dlech]

ValueError: Invalid argument

This one is tricky because the allowable values of the limits take into account the geometry of the drive base. The speed, when converted to speed of rotation of the rotor of the motor must be between 1 and 2000 deg/s. The acceleration, when converted to the rotational acceleration of the rotor of the motor must be between 50 and 20000 deg/s^2. And similar for the torque.

We could probably add more helpful error messages that list the actual min and max allowable values.

In the meantime, to troubleshoot, you could leave each value out one at a time to see which one is causing the error and then do the math or use trial and error figure out what the allowable values are.

[shoringit]

Thanks for the tips. I'll try those.

Yeah, I did some trial and error. I think it's largely caused by the giant differences in the default PIDs (which results in much different accelerations and speeds). Better error messaging would be very helpful though.

Thanks

Danny

[shoringit]

Regarding _threading, it did the trick. This code now works under v2 and v3 for anyone that finds this in the future...:

#!/usr/bin/env pybricks-micropython3

from pybricks.hubs import EV3Brick
from pybricks.parameters import Button, Color
from pybricks.tools import wait, StopWatch
import _thread

ev3 = EV3Brick()

def BlinkyThread() :
    while True :
        ev3.light.on(Color.GREEN)
        wait(1000)
        ev3.light.on(Color.RED)
        wait(1000)

t1 = _thread.start_new_thread(BlinkyThread, ())

while True :
    ev3.speaker.beep()
    wait(5000)

[jakeoldboy]

Hi all:

I have played with Micropython-pybricks 2 on my EV3; however, I would like to use pybricks v3 on my EV3 so that I could write some python code that would be closer to what kids use on Spike Prime. That way I could write tutorial examples to mentor students at my daughter’s public charter school. It would also benefit students that take home some of the schools old EV3 to practice programming at home with about the same version that they use at school on their Spike Primes.

so my question is what is the status of pybricks v3.x working well enough to use on Lego EV3s? Also what parts or features 1) work well enough to use on EV3s, and 2) what doesn’t work well enough to use on EV3s?

Thanks for any updates!
JakeOldBoy

[laurensvalk]

I would like to use pybricks v3 on my EV3 so that I could write some python code that would be closer to what kids use on Spike Prime. That way I could write tutorial examples to mentor students at my daughter’s public charter school. It would also benefit students that take home some of the schools old EV3 to practice programming at home with about the same version that they use at school on their Spike Primes.

This is the direction I'd like to go in as well. That is, to make it "like Spike" instead of continuing the Linux-based approach.

I think the ev3dev-based Pybricks 2.0 is really good for what it is (ev3dev Debian Linux, WiFi, Bluetooth), but those asking for extra motor features may be better off using a more lightweight solution.

Unfortunately that's quite a long way off in a technical sense. It requires a bit of a different approach. We started exploring this in pybricks/pybricks-micropython#241