[Bug] ev3 loop time issues with v3.X #1035
Comments
dlech
added
bug
|
This is due to pybricks/pybricks-micropython#146.
Originally posted by @laurensvalk in pybricks/pybricks-micropython#146 (comment) So thanks for opening this issue, @kai-morich :) |
|
I also noticed other strange behavior in a more complex program used for WRO 23 season when using v3.3b instead of v3.2. |
|
this test programm #!/usr/bin/env pybricks-micropython
from pybricks.hubs import EV3Brick
from pybricks.ev3devices import Motor
from pybricks.parameters import Port, Direction
from pybricks.tools import wait, StopWatch
from pybricks.robotics import DriveBase
ev3 = EV3Brick()
left_motor = Motor(Port.C, Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.D, Direction.CLOCKWISE)
robot = DriveBase(left_motor, right_motor, wheel_diameter=62, axle_track=195)
stopwatch = StopWatch()
# drive forward, e.g. with line / wall follower
print('a', stopwatch.time(), robot.distance())
robot.reset()
print('b', stopwatch.time(), robot.distance())
while robot.distance() < 100:
print('c', stopwatch.time(), robot.distance())
robot.drive(200, 0)
print('d', stopwatch.time(), robot.distance())
wait(10)
print('e', stopwatch.time(), robot.distance())
robot.stop()
print('f', stopwatch.time(), robot.distance())works well with v.3.2.3 and produces this output but is basically unusable with v3.3.0b3 and produces this output even with adding some longish |
This adds an extra check to make sure the motor poll timer hasn't fallen too far behind. Before this change, if calling the motor process was blocked for too long, it would cause the motor contiki process to never yield until the wall clock caught up. This would also cause motor updates to be called with a time delta of 0 which probably caused unexpected conditions in some of the calculations. We can avoid this by checking to see if we have a condition that would trigger the unwanted behavior and reset the timer to a larger interval. This could cause a hiccup in the observer calculations but is a significant improvement over the alternative. Fixes: pybricks/support#1035
This adds an extra check to make sure the motor poll timer hasn't fallen too far behind. Before this change, if calling the motor process was blocked for too long, it would cause the motor contiki process to never yield until the wall clock caught up. This would also cause motor updates to be called with a time delta of 0 which probably caused unexpected conditions in some of the calculations. We can avoid this by checking to see if we have a condition that would trigger the unwanted behavior and reset the timer to a larger interval. This could cause a hiccup in the observer calculations but is a significant improvement over the alternative. Fixes: pybricks/support#1035
|
Hi @kai-morich Can you please try pybricks-micropython-build-2735.zip and see if it fixes the issue? |
|
thanks for the fix, works again! |
This adds an extra check to make sure the motor poll timer hasn't fallen too far behind. Before this change, if calling the motor process was blocked for too long, it would cause the motor contiki process to never yield until the wall clock caught up. This would also cause motor updates to be called with a time delta of 0 which probably caused unexpected conditions in some of the calculations. We can avoid this by checking to see if we have a condition that would trigger the unwanted behavior and reset the timer to a larger interval. This could cause a hiccup in the observer calculations but is a significant improvement over the alternative. Fixes: pybricks/support#1035
|
FYI, build 2735 had some issues. I've made a 2nd attempt. See pybricks/pybricks-micropython#161 (comment) for latest builds. |
This reduces the load on the rest of the program. See: pybricks/support#1035
This reduces the load on the rest of the program. See: pybricks/support#1035
|
with build-2738 runs much smoother than build-2735 |
This reduces the load on the rest of the program. See: pybricks/support#1035
|
We've also made pybricks/pybricks-micropython#164 which should improve the control even more. |
|
Build for testing: pybricks/pybricks-micropython#164 (comment) (includes both changes) |
|
build 2756 has a new issue:
|
This reduces the load on the rest of the program. See: pybricks/support#1035
That program doesn't seem quite right: from pybricks.hubs import EV3Brick
from pybricks.pupdevices import Motor
hub = EV3Brick()
left_motor = Motor(Port.E, positive_direction=Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.F)Which hub is this? EV3 has no Can you share the program that reproduces an error on EV3? |
|
I remember to have seen EPERM also with v2.0.0 when i tested #1056. For that old version I moved the set_speed() to the beginning of the program. with stop() before set_speed() the new version works. |
#!/usr/bin/env pybricks-micropython
from pybricks.hubs import EV3Brick
from pybricks.ev3devices import Motor
from pybricks.parameters import Port, Direction, Color
from pybricks.robotics import DriveBase
from pybricks.tools import wait
hub = EV3Brick()
left_motor = Motor(Port.C, Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.D, Direction.CLOCKWISE)
robot = DriveBase(left_motor, right_motor, wheel_diameter=62, axle_track=195)
def set_speed(speed):
robot.settings(speed, speed*8, speed//2, speed*5 )
# drive forward with line / wall follower controlled turn_rate
hub.light.on(Color.YELLOW)
robot.reset()
while robot.distance() < 100:
robot.drive(300, 0)
wait(10)
# stop
hub.light.on(Color.GREEN)
#robot.stop() # <---
#wait(100) # <---
# drive back
hub.light.on(Color.RED)
set_speed(100)
robot.straight(-100) |
Yes, back in 2.0.0 changing the settings was not allowed while driving. This is allowed now. So we can skip that issue then. |
|
That leaves us with:
Is the following better? Can you describe bumpy drive speed? |
This reduces the load on the rest of the program. See: pybricks/support#1035
|
2763 works again bumpy: never reached normal speed. accelerated + deacellerated 2-3 times with 1 second period |
|
Could I kindly ask for video? Thanks in advance. |
|
ok |
|
Can you modify the following program to reproduce your issue? from pybricks.ev3devices import Motor
from pybricks.tools import wait
from pybricks.parameters import Port, Direction
from pybricks.robotics import DriveBase
from pybricks import version
print(version)
# Initialize.
left_motor = Motor(Port.C, Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.D, Direction.CLOCKWISE)
robot = DriveBase(left_motor, right_motor, wheel_diameter=62, axle_track=195)
# Allocate logs for motors and controller signals.
DURATION = 6000
left_motor.log.start(DURATION)
right_motor.log.start(DURATION)
drive_base.distance_control.log.start(DURATION)
drive_base.heading_control.log.start(DURATION)
#
#
# Add some code here to make some moves that reproduce your problem. For example:
drive_base.straight(500)
drive_base.straight(-500)
#
#
drive_base.stop()
# Save data logs.
print("Saving data on the EV3...")
left_motor.log.save("servo_left.txt")
right_motor.log.save("servo_right.txt")
drive_base.distance_control.log.save("control_distance.txt")
drive_base.heading_control.log.save("control_heading.txt")
print("Done")This will produce a few text files on your EV3. If you want to share them here, we can find out what is going on. |
|
sorry, too many test programs. bumpy happened with the second test program: #!/usr/bin/env pybricks-micropython
from pybricks.hubs import EV3Brick
from pybricks.ev3devices import Motor
from pybricks.parameters import Port, Direction
from pybricks.tools import wait, StopWatch
from pybricks.robotics import DriveBase
ev3 = EV3Brick()
left_motor = Motor(Port.C, Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.D, Direction.CLOCKWISE)
robot = DriveBase(left_motor, right_motor, wheel_diameter=62, axle_track=195)
stopwatch = StopWatch()
# drive forward, e.g. with line / wall follower
print('a', stopwatch.time(), robot.distance())
robot.reset()
print('b', stopwatch.time(), robot.distance())
while robot.distance() < 100:
print('c', stopwatch.time(), robot.distance())
robot.drive(200, 0)
print('d', stopwatch.time(), robot.distance())
wait(10)
print('e', stopwatch.time(), robot.distance())
robot.stop()
print('f', stopwatch.time(), robot.distance())bumpy.mp4will test the other programm and then add logs to the bumpier one |
|
build 2756 looks incomplete: older + newer builds are not bumpy |
|
Thanks. I can reproduce one form of "bumpy" behavior. It looks like some loops are still taking too long.
|
|
👍 |
|
I think it was a glitch that this was automatically closed. There are still some issues as shown in the plot by Laruens. |
laurensvalk
changed the title
|
There is some commentary here or there that there are plans to try to get ev3 back to supported status in the next release of pybricks. However I'm told in #1215 that this is no longer the case. I wonder if we should add a warning to the console to make this clearer on initialization if someone is using a firmware that is not only not-yet-supported, but also actively never-gonna-be-supported. For example #1075 suggests that getting a v3 firmware onto an ev3 is a thing that someone might want to do, but given there are no plans to make v3 work on ev3, it probably doesn't actually make sense for people to go through the trouble of testing it. If this makes sense to people I could send a pull request. |
|
Instead of modifying the build, I think we can just add a note to those (somewhat outdated) instructions. And it looks like you have done so, so thanks for that! It would certainly be nice to see the EV3 version continue to be supported. See also https://github.com/orgs/pybricks/discussions/1171#discussioncomment-6516689 for additional context. |
|
Sure, that makes sense. And I totally understand the constraints involved with no supporting v3 on ev3 -- y'all have a limited amount of time to spend on the project and it definitely makes more sense to spend it on whatever is being used most today. It does look like the |
|
I would also highly appreciate if EV3 would be supported again by v3.3 since I have a lot of 3rd party sensors and add ons for it! Also communication between different hubs EV3 <-> Spike, … would be very nice! 👍 |
|
Any chance to get this fixed vor v3.3? |
|
No, this is not planned for V3.3 I'm afraid. We don't seem to have enough EV3 users / sponsors / volunteers at the moment to work on this. I would rather work on a revised firmware (either bare metal or non-SD-card-Linux), and get all the new features supported there, instead of patching the existing 2.0 edition that seems to work well enough for most users. That way, the EV3 edition can eventually blend in with the rest of Pybricks (including web IDE) instead of treating it separately. Although not actively requested here on Github, this is requested a lot by people/teachers who would like a good and simple solution for EV3. Then the stable 2.0 edition with vscode and all ev3dev iOT capabilities can continue to exist with its existing documentation, and hosting / support from LEGO Education, without ever making any breaking changes. |
Keeping 2.0 version stable and to add EV3 to the code.pybricks.com family would be very nice. I have the EV3 still running as linux host, but it's just running for fun. |
That would be an awesome solution but sounds like way more work and might also take longer than getting the current version running again even if not "officially" supported. |
|
I don't think there's a quick fix/hack available if that's what you're asking. The current iteration of motor drivers were designed for bare metal systems with simple timing, so it is not expected to work as-is on EV3 (Linux). That is to say, this isn't just some random bug. This was intentional / by design: the drivers have been a huge step forward on all platforms that have ongoing releases. And nothing is really broken on 2.0 either, it just didn't get all the new features. While it's probably technically possible to revise the control algorithms for non-rt systems, it doesn't seem worth investing a lot of time that could be used elsewhere. Perhaps taking a step back, what are the main use cases for V3.3? Is it only certain drive functions? Could they be implemented using a Python class? Due to the nature of the hardware, control precision is quite good on EV3 in 2.0, both for single and dual motors. So it shouldn't be too hard to implement things like curve with a radius, and make them non-blocking with the wait=False paradigm used elsewhere. |
|
I like the What is the latest version you can seriously recommend for EV3? When were the new motor drivers introduced? In V3.3 or earlier? I used V3.2 quite succefully, besides bug #1056 that happened sometimes when reversing the direction. |
I would recommend the official version hosted by LEGO Education, so Pybricks 2.0.
These features were introduced alongside the new drivers in 3.3.
👍 Rest assured, we won't forget about EV3. Just trying to keep expectations realistic 😄 |
looks like some initialization is still ongoing, when the program is started
the issue does not occur with v2.3.2 or with prime-hub at v3.3.0b3 or v2.3.2
The text was updated successfully, but these errors were encountered: