Pybricks support and general discussion
License: MIT License
If you are looking for help with anything Pybricks, you are in the right place.
Click the link below for the discussion group. Use this to share your project, request features or ask for help.
➡️ Pybricks support and general discussion ⬅️
If you think you found a bug, first try searching to see if it has already been reported. If in doubt, just open a new issue.
➡️ Pybricks bug tracker ⬅️
Looking for documentation or example code?
How can I copy (& paste in another place) the text from the output/log window?
CTLR+C don't work.
The pybricks.com website references:
Move Hub (BOOST)
City Hub (Powered Up)
Control+ Hub (TECHNIC)
I think Move Hub is part 88006, City Hub is 88009. Is that correct?
What part is "Control+ Hub"? I cannot find anything like that on the Lego website.
I have used MicroPython fairly extensively on ESP8266 -- REALLY excited to find this project! Any thoughts on when you may have some sort of release for non-EV3 devices?
Attempt to import the Font class fails.
from pybricks.media.ev3dev import Font
Console Output:
ImportError: no module named 'pybricks.media'
This was with Release 1.0 downloaded from Lego Education. Perhaps this module wasn't in that release?
Subscribe to this issue to be notified of new features and bug fixes during the initial v3.0 beta period.
Changes are published on https://code.pybricks.com as soon as they are merged.
See #29 for the v3.0 roadmap.
I tried to use 88005 Light from Pybricks, but it seems that the device is not supported.
https://www.lego.com/en-us/product/light-88005
LEGO official applications, e.g. Powered Up app, support it. I think it's almost the same as DCMotor. The IO Type ID is 0x08 as follows:
https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#io-typ
Originally posted by @devinbreise in #17 (comment)
I'm testing turn() on RobotDrive using settings() with a set turn_velocity around 250 and adjusting the turn_acceleration parameter. My goal was to discover, for the robot I'm testing, at what threshold of turn_acceleration the turn() maneuver becomes inconsistent (due to wheel slippage). This is an experiment we take FLL teams through all the time, though usually with varying rates of velocity instead of acceleration because the (steep!) acceleration curves are fixed in the MindStorms blocks. Code looks like this:
self.drive.settings(turn_acceleration=maxAccel) self.drive.turn(360) self.drive.stop() self.hold() #this calls hold() on the two drive motorsThe call to hold() is to "lock" the motors in case there is any residual momentum.
What is surprising to me is that I can't seem to "break" it. As I increase the turn_acceleration value, I do see a shorter and shorter time to complete a turn(360) but it seems to cap out at a certain level, while it is still showing a high degree of accuracy. I thought perhaps the underlying Motor.control.limits were creating this cap, so I set the acceleration value there on both drive motors to a very high value, but that didn't seem to affect this cap.
So the good news is that the software is exhibiting a remarkable combination of speed/precision (360 degree spin in ~1.5 seconds with 1-2 degree accuracy with a medium sized robot). Very impressive.
But I feel there is still something in the software prohibiting me from getting it to the point where it loses accuracy. Perhaps the pid settings on the two wheels?
This is the 3th time in the past few hours I ran into this issue :(
This morning I tried flashing Pybricks to my Technic hub and halfway the progressbar would stop (the led still flashed Red Green Blue).
I removed the battery and retried only to have the same endresult :(
I flashed the official lego firmware back onto the hub and confirmed that it worked befor I retried to flash PyBricks again. This time it sucseeded. Unfortunately it would complain my motors weren't connected. This is other issue might and not be related but because of it I tried to flash Pybricks again and again the flashing stalls and seems to never finish...
Due to the experiences from the past I'm now flashing the original firmware and will try to flash pybricks after it finishes.
In the meantime the lego firmware flashed correctly and pybricks is flased as well.
Not sure what is heppening but it seems that flashing isn't as reliable as it should!?
I tried to use two separate instances of Chrome, trying to connect to two different Technic Hubs simultaneously (both already with Pybricks on board). With the first instance, I can connect to the first Hub, while the second cannot "see" the second Hub.
This might be by design but if it is it isn't clear in the documentation.
Xaxis = Motor(Port.A)
Xaxis.run_until_stalled(360,Stop.COAST,15)
This results in:
The requested operation is not valid in the current state:
--> Check the documentation for required conditions.
--> Check the line in your script that matches the line number given in the 'Traceback' above.
while Xaxis.run_until_stalled(360,Stop.COAST,16) works as expected.
Describe the bug
If I read the i2c memory - I get inconsistent results. If I read the memory buffer from the NXT ultrasonic sensor beginning (00) or from 2 bytes in (02) I should get the same value for bytes 2..10 - right? thanks (note reading 0x42 does indeed give me the distance, but reading 2 bytes from address 0x40 does not).
To Reproduce
go to the REPL and type
address=0x02 >> 1
device = I2CDevice(Port.S4, address)
device.read(reg = 0x00, length = 10)
b'V1.0\x00\xff\xff\xff\xff\xff'
device.read(reg = 0x02, length = 10)
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
Expected behavior
the second string I think should start with a decimal point not FF
Screenshots
none needed
I'm currently doing a project that involves calibrating a older color sensor that doesn't have support for it. I'm planning to store the raw data in a csv file. Pybricks does support data logging, but you must create a new file every time the program runs. If you could give the log or DataLog class an argument that states if it's writing in a pre-existing file, it would be a lot simpler to store larger amounts of data.
Not sure if this is a "bug" or just a fact of life...
When switching modes on a color sensor, it appears to take about 20ms for readings to become accurate.
This code was run on an EV3 (self.lightL is a ColorSensor object):
left = self.lightL.color() #force color sensor into COLOR mode
wait(500) #wait a little bit
timer = StopWatch()
timer.reset()
while timer.time() < 1000:
print(str(timer.time()) +":"+str(self.lightL.reflection()))Here is the output:
0:79
14:79
18:79
22:14
26:14
37:14
40:14
47:14
etc.
Not sure if there is "correct" behavior here...maybe just some notes in the doc.
I want to use autocomplete functions for coding of EV3Micropython, but can't use.
Is there are way to do it on VSCode?
I tried to take a look at gc performance on an EV3 today, only to discover that gc.set_debug() doesn't appear to be a part of the MicroPython implementation as seen here and here. The good news is that it appears possible to enable/disable and force collection when you want, nice things to have for embedded controllers written with a GC heap...
Do you happen to know if a window into the GC performance (how often it is running, ellapsed milliseconds, etc.) is possible in this environment?
I tested a Lego robot with a 95mm axle track and caster wheel on the back using the default limits() (currently distance_control (349, 698, 100) and heading_control ((349, 698, 100)
I was able to get the robot to reliably follow a fairly irregular line (the one that extends into base on this season's CityShaper mat) with velocity 50 and a p coefficient of 1.5 applied to a raw reflected light sensor reading. Faster speeds are possible, but the sharpest corners won't make it. For a straight line, it would be possible to increase the velocity somewhat.
self.drive.drive(50, (self.lightL.reflection() -65) * -1.5) #65 to account for offset light sensor relative to axle trackObservations:
--the oscillations due to the proportional control are fairly significant. The loop seems to want a integral control. However, it is comparable to MindStorms performance.
--the loop rate is very fast (measured about 1.3ms per loop), but the drive doesn't seem to be responding that quickly. Movements from side to side appear to be something more like 200ms. Here is a video: https://drive.google.com/file/d/1CX54gm24_DL3t5Zx-Q3sONnfOJakDFdR/view?usp=sharing
I'd be very interested on thoughts regarding loop rate versus drive response.
Our lab will be using multiple EV3s and multiple PCs. To help the kids keep track of which programmer is connected to which brick, we would benefit from a kid-friendly way to rename the bricks in the Bluetooth address space. We have found the instructions below, but we would prefer not to teach the kids sudo... ;)
Current workaround: In an SSH terminal, run sudo ev3dev-config, the go to Advanced Options and select Hostname. There seems to be a bug after this where the menu program disappears. Just press ENTER and it will come back. Then you can type in the new name.
Question
I want to use Absolute-IMU sensor from mindsensors.com on pybricks.
I tried to use it using Ev3dev class, but "RuntimeError:Unknown Error" was occured many times.
Sometimes, the connection was successful and get values when I reconnect the cable to the sensor port.
Please tell me how to connect the sensor correctly.
Context
The codes I tried is here. The compass sensor from Hi-Technic could get the value normally, but IMU sensor from mindsensors.com cloud not connect.
from pybricks.iodevices import Ev3devSensor
sensor = Ev3devSensor(Port.S1)
while True:
val = sensor.read('COMPASS')
print(val[0])
wait(500)
I am trying to use the Mindsensors NXTMMX (motor multiplexer) with the EV3 using micropython. The NXTMMX is powerd and plugged into S1.
The EV3 sees ports in1:i2c3:M1 & in2:i2c3:M2 but I am having trouble declaring motors to those ports.
Here is the beginning of my code;
#!/usr/bin/env pybricks-micropython
# from pybricks import ev3brick as brick
from pybricks.ev3devices import (Motor, TouchSensor, ColorSensor,
InfraredSensor, UltrasonicSensor, GyroSensor)
from pybricks.parameters import (Port, Stop, Direction, Button, Color,
SoundFile, ImageFile, Align)
from pybricks.tools import print, wait, StopWatch
import struct
# Declare motors
left_motor = Motor(Port.B)
right_motor = Motor(Port.C)
lift_motor = Motor(Port.A)
grab_motor = Motor(Port.D)
reach_motor = Motor(Port.in1:i2c3:M1)What do I need to do to be able to utilize the motors at these ports?
Describe the bug
When using stop()/brake() or Stop.COAST/Stop.BRAKE, a motor sometimes won't stop.
It appears to keep going at the last active duty cycle value.
Workaround
If you use the default hold()/Stop.HOLD, this does not occur. Because the control loops keeps updating the motor.
To Reproduce
It seems to be very rare and not deterministically reproducible. If anyone has a script that reproduces this all the time or most of the time, that would help.
This has also been reported by @johnscary-ev3 in #7 (single motor with threading) and @devinbreise in #16 (drive base).
Expected behavior
The motor should coast or brake when we ask it to.
The Button Parameters Class does not seem to work in Release R3 compared to original LEGO release of micro-python.
Now when I use "Button.LEFT_UP" to get the code for a button pressed in IR remote I get this error,
File "/home/robot/EVE3RSTORM/main.py", line 412, in
TypeError: unsupported types for add: 'Button', 'Button'
Line of Code with error:
if butt_sum1 == Button.LEFT_UP or butt_sum1 == Button.LEFT_UP + Button.RIGHT_UP or butt_sum1 == Button.LEFT_UP + Button.RIGHT_DOWN:
After some investigation it looks like this statement to get the pressed buttons from the IR remote:
InfraredSensorPort = Port.S4
ir =InfraredSensor(InfraredSensorPort)
buttons = ir.buttons(chan)
now returns a list of literal button names instead a list of integer button codes as before.
Is this and intentional change or a bug?
Now that #34 has been fixed, something similar occurs on Android.
The bluetooth button appears to reach the connected state and it stays gray. After a while, it gives up:
I got the same error when initiating firmware update, but that did eventually succeed.
I tried to read the values of the SPIKE Prime ultrasonic sensor with the Control+ Hub but the results are inconsistend and/or don't make sense.
I understand that there is a bug in reading the sensor values in a loop (#36) and this might be related to that, but it's another issue.
Code:
hub = CPlusHub()
ultraschallsensor = UltrasonicSensor(Port.A)
print(ultraschallsensor.distance())
while True:
wait(100)
I ran the program mutliple times and moved my hand in front of the hub and the prints in the console don't seem to be consistent. It goes as far as reading higher values if the hand is closer to the sensor.
No matter what I tried, when trying to set any limits I get an EPERM error.
My motor is initiated as follows: motor = Motor(Port.A, gears=[8, 40])
I tried the following combinations to set limits:
motor.control.limits(30, 60, 100)
motor.control.limits(160, 320, 100) # Reported default
motor.control.limits(30, 60, 50)
motor.control.limits(60, 120, 50)
They all fail.
EDIT: I just noticed this message in the Documentation: "At the moment, only the Control+ Hub is ready for beta use." This issue may be "By Design" for now...
Describe the bug
I am unable to update my City Hub to Pybricks. This happened when the firmware on my City hub was old (last used around December 2019), and again after updating the firmware in the Powered Up app.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
5a. Flashing to begin
Actual Behavior
5b. Red error box (with rounded corners) indicating that the hub is not compatible.
Error Text: "Sorry, we don't have firmware for this hub yet."
System Info
Windows 10, 1909, Intel i7-9700K, 32gb RAM.
Chrome Dev: Version 85.0.4168.3 (Official Build) dev (64-bit)
Screenshots
Question
I was wondering whether there's support on multitasking.
Context
Independent unit of task similar to EV3-G.
Screenshots
NA
Thank you.
Question
The run button is never active after the bluetooth activation (and the bluetooth button is not active again but I don't know if it's normal or not) ==> not sure if the bluetooth connection is successfull or if another issue after
Context
I'm using a macbook air with Mac OS Sierra (10.13.6) and Chrome 80 (as requested). The flashing of the hub was successfull (when I press after the green button one motor is turning very shortly). Then I try to connect Bluetooth. Icon is changing on chrome (Tab associated with a bluetooth device) but the Run button is not active
Screenshots
Question
When I use balenaEtcher to burn the new stable 2.0 release to my microSD, I get an error about the image. Do you know why this would be happening? I've used the same method for other updates before and it was always fine.
Context
Install the new stable 2.0 release on my microSD.
Screenshots
First of all I know this is alpha software so the documentation is not upto standard yet :)
I noticed that the program I used last week didn't include any from pybricks..... import lines.
As a reaction to Laurens his earlier reply about the duty limits for stalling. I tried to use the pid() command but it seems I need to import something for it but the current state of the documentation doesn't make it very clear for me when I need to import what :)
As this is more like support than beta testing I'll put the few support issues I run into into a single question, hope you agree this is best in order to avoid cluttering the issues :)
Looking at the documentation of pid() I think the usage is as follows for only retrieving the currently set values:
Zaxis = Motor(Port.C)
Zaxis.Control.pid()
print(kp, ", ", ki, ", ", kd, ", ", integral_range, ", ", integral_rate, ", ", feed_forward)
but this results in : AttributeError: 'Motor' object has no attribute 'Control'
How can I drive 2 motors at the same time? I wonder if there is a function to drive 2 motors simultaniously making sure they both arrive at the set location (angle in my case) at the same time?
Or at least the ability to issue a run_target() without waiting for it to finish.
Now I'm going to enjoy my sunday :p Thanks in advance!!! And keep up the good work! Hope I can show off my lego 8094 plotter driven by PyBricks soon :)
Some testing with some "medium" motors on an FLL robot using the Motor class turned up the following observations:
Maximum angular velocity seemed to vary between 1280 and 1345 degs/sec2 on the two motors I tested. Both of these were slightly loaded with some downstream gear assemblies, but interestingly the one that was slightly more loaded achieved the higher angular velocity
Being able to specify the gear train is really great. The stronger FLL teams I have coached come to understand gear ratios and the speed versus torque tradeoffs, but they seldom if ever bother to encapsulate the math, so they end up with "rules of thumb" for how many "degrees" or "rotations" they need to move the motor to drive the armature at the other end of the gear train. This API allows for both. However, it is quite common these days for teams to swap out armature systems (with different gear trains) in the middle of a match, within the context of a "master control program". As the API now stands, it appears that one must create a new object of class Motor to change the gear ratio. A "setter" method for a new gear train seems like it would be useful here.
The run_until_stalled() method is very intriguing. This is something that the teams I have worked with tend to write in order to reliably "reset" an arm to a known (stalled) position. However, what really caught my attention was the duty_limit parameter. Occasionally I've seen teams develop very high torque armature for specific situations. These designs can be tricky to stall due to the torque they generate, so this appears to be an ideal solution. However, a little testing with something the kids built last season seemed to indicate I'm doing something wrong or its not actually working. Using an arm that moves at a .07 ratio relative to the motor, I measured the same ~1.5 pound-inches of torque with both of these calls.
self.lower.run_until_stalled(100, Stop.HOLD, 100) self.lower.run_until_stalled(100, Stop.HOLD, 1)Perhaps the extreme gear ratio is to blame? Regardless, by using another convenient aspect of this API (Motor.control.stall_tolerances()) I was able to approximate the intended behavior by adjusting the speed threshold up to about 50% of the commanded speed.
Describe the bug
I have a program that loops checking two color sensors, a sonic sensor, and gets IR button inputs.
While doing this it also moves a scan head motor using a generator (yield) function like in the Gyro demo program.
This program runs fine for a long time like an hour and then suddenly stops and causes the EV3 system to crash. Only can get it back with a hard reset.
I am using wifi connection but only an occasional print statement. No multi-threading in this app only that generator function to yield back control between motor moves spaced 1 sec apart.
I suspect some sort of memory leak but get no errors from the system.
Has this been seen before? Any ideas on how to diagnose this?
Thanks.
Was trying to find acceleration thresholds and found this:
This code (drive is an object of type DriveBase):
print("Default:"+str(self.drive.settings()))
self.drive.settings(10, 20, 30, 40)
print(self.drive.settings())
self.drive.settings(turn_acceleration=40)
print(self.drive.settings())Produces this output:
Default:(100, 200, 90, 180)
(10, 20, 30, 30)
(10, 20, 30, 30)
While I have lots of software development experience, I am only doing robotics with EV3 for fun with my kids. And I have no idea what PID is and the quick google results did not give me the tight intro I was looking for.
(I am a chemist and physicist by training, so the Calculus explanation will do. ;-)
Question
I understand I need to use a USB Wifi dongle to get Wifi access with pybricks.
NetGear WNA1100 Wireless-N 150 seems to be the one supported from ev3dev site but can we use a newer and smaller NetGear dongle?
https://www.ev3dev.org/docs/networking
Context
I have been using Bluetooth for my wireless connection but it seems to have very limited range on two PCs I have tried and drops the connection when robot is moving around.
So I am thinking Wifi would be better. Is that correct?
Screenshots
The random module it's not present?
import random
...
...
...
Traceback (most recent call last):
File "main.py", line 5, in <module>
ImportError: can't import name random
In the 'autonomous running' mode, there is a way to read the input buffer from the nRF UART Service?
I can "print" on this service, so I can send data to other device... but if i want to receive some byte from the 'external world'?
Pybricks 1.0 was all about bringing Pybricks MicroPython to EV3.
This came out early 2019. It's super exciting to see people using this actively.
An epic number of users! According to Visual Studio Code, anyway.
If you're one of those, click 👍 on this post so we know you're here! 👋
Pybricks 2.0 was all about improving the EV3 experience.
To make it absolutely solid, tested, fully-featured, and FLL-ready.
It's ready now (:rocket: :tada: )! It's available in ev3dev and in the official LEGO EV3 MicroPython release.
Pybricks 3.0 will add support for Powered Up!
MoveHub()CityHub()CPlusHub()Pybricks 4.0/5.0 will be ... ?
In other words, what might we do one day, in a galaxy far away, but certainly not right now?
This is all super cool too, but it's better to stay focused on making the essentials really good first.
There are also a few things that are just not possible due to hardware limitations:
Other than that, the sky is the limit!
Writing some code to determine maximum drive_speed for a particular robot, needed to poll DriveBase.state() in a tight loop. Didn't really need the other 3 return values.
distance() and angle() have separate accessors. It might make for cleaner code in some situations to have the other two as well.
I tried to load the firmware with a custom main.py, following the steps explained on the documentation (drag the new .zip file on 'flash firmeare' button).
After drag the zip file, the flash firmware button don't work anymore, with no reaction to click.
https://docs.pybricks.com/en/latest/pupdevices.html#pybricks.pupdevices.ColorDistanceSensor.remote
There is not option to manage the speed of the LPF1 motors?
Disclaimer: My perspective on this is that of an FLL Coach. While I'll admit to a bit of tinkering with an EV3, 99% of my effort in this space is through the work of the 30+ FLL teams I have coached from 3rd graders to middle school world champions. So apologies in advance for the skewed perspective.
First off, let me say a big THANK YOU for doing this. This is exactly what I have been looking for for years. We start kids in FLL as early as 3rd grade and by the time they have been doing it for 3+ years, they often outgrow the MindStorms/LabView environment. Its not that the next lessons can't be taught there, its just not optimal. So having this level of control over things like acceleration (both straight and angular!) is really great. The kids will be able to dip their toes in the water of actual physics computations and, for their efforts, have a much improved level of control over their robot's odometry. In addition, Python is a great choice to transition them into the world of text-based programming, and get them ready to move to Java in FTC after that. So please keep up the great work. I have at least one team that is learning Python as I write this and counting on competing with this library next season.
There are 3 typical use cases I see in FLL for DriveBase:
Basic Movement: Driving a robot around a board using a series of discrete movements where the robot comes to a stop between each movement. This is the starting point for most teams and most of what you see in FLL. The kids think: "I need to move my robot forward this much, then I need to turn it that much, then I need to move forward again". In MindStorms, they code that as 3 blocks and behind the scenes, a PID controller uses some very aggressive accel/decel settings to try and keep the wheels from slipping too much, but success is heavily dependent on inertia.
Sensor Controlled Movement: Driving a robot using real time feedback from sensors. This is "line follow", "closing to a certain distance from an object" using an ultrasonic sensor, controlling heading using a gyro sensor, driving to a line, etc. In MindStorms, anything involving proportional control gets out of hand very quickly as they kids must use the looping constructs and "data wires" to make it work. Only the teams with devoted programmers who have a few years under their belt pull this off.
Smooth Movement: Sequencing a series of movements with smooth accel/decel curves between movements as needed. Currently, this is world-class level functionality in FLL. While it can be done in the the MindStorms environment, it is either highly imprecise (sequencing blocks without the "brake" value set) or highly advanced (teams that essentially write their own PID level controllers and master acceleration curves).
Given those use cases, here are my initial thoughts on DriveBase:
---I LOVE how the robot can be "configured" with its wheel_diameter and axle_track. This is a great opportunity to teach some basic geometry to the kids and then let them move on to higher order problems.
---Use Case 1 : Basic movement
------straight(), turn(), and settings() seems squarely aimed at this. I love that both straight_acceleration and turn_acceleration can be specified. This is a great opportunity to teach some basic physics and have the kids experiment with robot designs to discover what sort of acceleration their robot can tolerate before wheel slippage becomes a factor.
------I typically talk to the kids about straight movement, turns (radius turns) and spins (spinning in place). As I understand it, radius turns are missing in this part of the API. Perhaps those could be added? I get that such a turn can be specified with a combination of forward and angular velocity, but this is pretty advanced for FLL teams. We could try to coach them through the relationship between forward velocity on an arc, angular velocity, and radius, but I'd much prefer to see this math encapsulated in this class. Perhaps a method in this section could take radius measurement as an input?
------It's typical for teams to vary velocity from one movement to another depending on the level of consistency they need out of the specific movement. I wonder if the straight_speed and turn_rate parameters could be included as inputs on the movement methods themselves (e.g. straight(distance, speed))
---Use Case 2: Sensor Controlled Movement
------drive(), stop(), distance(), angle(), state(), and reset() seem to be aimed at this use case. It wasn't initially apparent to me that subsequent calls to drive() would "automatically" enact the specified acceleration curve to handle differences in velocity, but once that came clear, I do like it. Perhaps some notes in the doc.
------I haven't tested this yet, but I am wondering about how the acceleration curve will play with a higher level PID (or just P) controller calling drive(). For example, to follow a line (or go straight with a gyro), we will typically teach the kids the idea of real-time proportional control based on a sensor reading. Using this API, I presume they would code up a tight loop that will call drive() and adjust the turn_rate parameter proportionally to the amount of deviation from their intended course. In MindStorms, there is no software controlled angular acceleration curve to my knowledge, so the motors will simply be instantly commanded to the new rate of angular velocity. Here, depending on the turn_acceleration set, it might not. Not sure if that would be a problem. Similar issue for approaching an object and slowing down proportionally based on distance from the object. Some options:
---------Provide an explicit way to disable the acceleration curves. Perhaps this is just setting the acceleration numbers to arbitrarily large values?
---------Find a way for the kids to "plug in" their sensor reading directly to the drive control. Not sure exactly what this would look like, but imagine if they could provide a sensor as a parameter to a drive() function in way that would control velocity and/or angular velocity with a "built in" PID. Essentially the same thing you are now doing with the motor encoders.
---Use Case 3: Smooth Movement
------I've tried some experiments using sequential calls to drive() while polling distance() and angle() in between to try to generate a series of precise movements that do not including stopping between them. The first "oops" here was realizing that if I want to roll the robot forward at a certain velocity (e.g. drive(250,0)) and then make a radius turn while maintaining velocity, I have an acceleration problem. It appears that the next call to drive (perhaps drive(250,50)) detects that my "forward velocity" is already 250 so no acceleration curve there, but my current angular velocity is 0, so it must "ramp up" the angular velocity, resulting in an arc that looks more elliptical than circular. My workaround is to set the angular acceleration limit to a very high number.
------I'm not sure how to stop. I haven't tried calling straight() after a call to drive(speed,0). Perhaps that is the plan? My workaround is to call drive() with a very slow speed, let it decelerate for a specific set of encoder clicks, and then call stop() and brake().
------I'm not sure how far you want to go with this, but it occurs to me that you could potentially expand the straight() and turn() API to enable "optional" stops. My FTC teams tend to code something like drive(max_velocity, end_velocity, distance). In this implementation, the initial velocity is sensed, the end_velocity can be zero or non-zero and the distance is used to compute an initial acceleration phase (if needed), a cruise phase (maximized, but none if there is no room for it) and a deceleration phase (if needed). For example:
drive(250, 250, 1000) #accelerate from stand still, cruise at 250, don't decelerate
drive(100,100,1000) #slow down, cruise at 100, don't decelerate at end
drive(250, 0, 1000) #speed up, cruise at 250, come to a smooth stop If you added an ability to specify a radius, I think it would be relatively complete. Given something like drive_radius(max_velocity, end_velocity, degrees, radius), I could see code like:
drive(250, 150, 1000, None) #accelerate from stand still, cruise at 250, decelerate before the turn
drive(150,150, 90, 100) #Make a 90 degree 100mm radius turn to the right at speed 150
drive(250, 0, 1000) #speed up after the turn, cruise at 250, come to a smooth stop---Misc
------It wasn't clear if the acceleration parameters passed to settings() are the same as the acceleration parameters for distance_control.limits() and heading_control.limits(). Does setting one change the other?
------I was a bit mystified by the EPERM runtime errors until I clued in to the "You can only change the settings while the robot is stopped. This is either before you begin driving or after you call stop()." statement in the docs. I presume that was what that was about.
------I have not played around the PIDF coefficients yet, but in my initial tests, the defaults seem good so far. Most importantly, a balanced robot drives straight. :)
------I think I have seen some intermittent situations where even after calling stop() one of the motors continued to trundle along. This could easily be explained by bus issues (poor connections on the EV3 are a perpetual issue) but I'll keep an eye out and see if I can reproduce
I'd like to start a thread here to gather knowledge about simulators that might be used with Python (ideally Pybricks) based robots. Many FLL teams are, of course, not meeting physically right now, and their coaches are looking for ways to keep the learning going.
This one (https://www.aposteriori.com.sg/Ev3devSim/index.html) is quite simple, doesn't do much with physics, but does get the job done. It supports programming against the Python EV3DEV API. Maybe someone wants to do the Pybricks version?
These folks in Canada (https://www.virtualroboticstoolkit.com/) have gone much further, but currently don't support Python. However, they tell me it is on their road map "soon". Maybe they would partner with Pybricks to produce that.
What else are folks aware of in this space?
Looks like when I do a sound file playback and a motor fixed angle move at the same time, the motor can go crazy at high speed and not stop at requested angle.
My application is multi-threaded and so sound playbacks and motor moves can happen at same time.
This worked fine in earlier LEGO release of micro-python.
Is this a bug?
Thank you for creating pybricks for the EV3. I am really pleased by the possibilities of writing code in Python.
Question
I am trying to use the EV3 Color Sensor for navigation. But I cannot figure out how I should write my if-statement based on the color output from the sensor.
Context
I have placed my robot on white piece of paper, and the color sensor is detecting a white color.
This is verified by print (str(colorsensor.color())) which outputs: Color.WHITE
However if I try to write an if-statement: if colorsensor.color() == "Color.WHITE": it evaluates as false.
What am I doing wrong?
Best Regards, Carsten
I am using the Gyro to do angle controlled turns.
There is a section of code below of 90dg Left Tank turn that can use Gyro if Available.
Mainly this works fine and is not sensitive to slow Drifting of the Gyro since I reset its angle to 0 just before each turn.
However I have noticed that sometimes the Gyro Drift rate suddenly increases and it become not usable. Drift rate seems to increase over time or can be high from the start if you move the Gyro during start up of the system. Only way I have found to fix this is power off/on reset of system.
So, is there a way to do the equivalent of the power off/on reset with software command?
Thanks.
#90dg Left tank turn using gyro if available
def left_tank_turn(BC_turn_speed, motorB, motorC):
global GyroAvailable
global Rotation_angle_90dg_tank_turn
if GyroAvailable:
gyro.reset_angle(0)
while gyro.angle() != 0:
gyro.reset_angle(0)
wait(50)
motorB.run(BC_turn_speed/2)
motorC.run(-BC_turn_speed/2)
while gyro.angle() > -89:
wait(10)
motorB.stop(Stop.BRAKE)
motorC.stop(Stop.BRAKE)
else:
motorB.run_angle( BC_turn_speed/2, Rotation_angle_90dg_tank_turn, Stop.BRAKE, False)
motorC.run_angle( BC_turn_speed/2,-Rotation_angle_90dg_tank_turn, Stop.BRAKE, True)
This code throws the EPERM error:
DriveBase.straight(100)
Motor.dc(50) #one of the DriveBase motorsYou can only change the settings while the robot is stopped. This is either before you begin driving or after you call stop().
This statement from the docs continues to perplex me a bit. The use case was using straight() and turn() to have a robot approach a line, then switch over to dc() to effectuate a "tank drive" control to square on the line using two light sensors on the front of the robot. If I call stop() after the call to straight() then all is well, but it seems odd... Here is what the use case code looks like:
self.drive.turn(45)
self.drive.straight(320)
self.drive.turn(-45)
self.drive.straight(150)
self.drive.stop() #Even through the robot is "stopped", code will fail without this call
self.drive.square_on_line()Preamble
Hi everyone! I just discovered this great project and I'm thinking about switching to pybricks for my ffl-team.
Question
Has anyone tried to to parallelize code execution with pybricks? I tried to use multiprocessing but until now with no proper results. Maybe someone can give me a hint on how to accomplish this?
Context
My use case is that I want to get a tool motor in the right position while approaching a target at the same time.
For me at least, it seems that run_until_stalled is a nice way of resetting your robot when it is in an unknown state. It would be nice if I could run all resets at the same time, but I need to be able to not wait for the stall to happen to achieve that.
Question
Is it possible to play a sound file while doing something different?
Context
I want to make a little menu on my brick that you can navigate through with the buttons. I want to play a click sound each time, a button is pressed. But in this case playing the sound file takes enough time to add unnecessary delay.
The documentation only tells about speaker.play_file(soundfile), but is there something like speaker.play_file(soundfile, awaitEnd) ?
What would be your solution to this?
Very often I get the message:
Traceback (most recent call last):
File "main.py", line 6, in <module>
OSError: [Errno 19] ENODEV:
A sensor or motor is not connected to the specified port:
--> Check the cables to each motor and sensor.
--> Check the port settings in your script.
--> Check the line in your script that matches
the line number given in the 'Traceback' above.
I'm 100% sure all 3 motors I have are connected to the correct ports but still Pybricks complains that they are not connected correctly.
I have verified with Powered Up app that all 3 motors are functioning as desired eliminating the posibility for faulty connections.
The Code I'm using is very simple and straightforward:
from pybricks.pupdevices import Motor
from pybricks.parameters import Port, Stop
from pybricks.tools import wait
# Define the XYZ axis motor ports
Xaxis = Motor(Port.C)
Yaxis = Motor(Port.D)
Zaxis = Motor(Port.B)
# Say hello :)
print("Lego 8094 says hello!")
# First, we'll move the dial to zero.
Xaxis.run_until_stalled(90,Stop.COAST,10)
I had this same issue last week and I got it working again by reflashing the official Lego firmware and reflash PyBricks again. Not sure if this actually fixed something or that it was coincidence that it started working again.
EDIT: reflashing the firmware didn't help...
I uploaded the demo program (for the record, the first time I tried it pybricks complained that my motors weren't connected to the hub, after reflashing it worked):
# Initialize hub and sensor
hub = CPlusHub()
# We'll use two motors. One is a dial to
# set the speed of the other motor.
motor = Motor(Port.C)
dial = Motor(Port.A)
# Say hello :)
print("Hello, Pybricks!")
# First, we'll move the dial to absolute zero.
dial.run_target(500, 0, Stop.COAST)
while True:
# Set the speed based on dial angle
speed = dial.angle()*3
if abs(speed) < 100:
speed = 0
motor.run(speed)
The single print("Hello, Pybricks!") works fine. But I tried to print the value of speed inside the while loop:
while True:
# Set the speed based on dial angle
speed = dial.angle()*3
if abs(speed) < 100:
speed = 0
print(speed)
motor.run(speed)
This also works but when I press the stop button the hub doesn't stop and both the start and stop button are greyed out. I have to remove the batteries and reconnect to take control again.
I suspect the loop is too fast, when I insert a wait(10 to reduce the speed of the loop it works fine:
while True:
# Set the speed based on dial angle
speed = dial.angle()*3
if abs(speed) < 100:
speed = 0
wait(10)
print(speed)
motor.run(speed)
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.