UI Suggestions & Mac Bug?

[bcfletcher]

i'm a coach for an FLL team and we just switched from Lego Spike this weekend. We got fed up with the poor documentation, inconsistent behavior, and incoherent API from Lego. Lego really should just abandon Spike and fund y'all. ;)

the ability to run the "web app" without an internet connection made the switch possible. great idea!!!

the kids managed to get all our code moved over in a day and they are much happier!

some suggestions:

1. could you add a GUI setting to automatically clear the output window, when the "play" button is pressed. we frequently forget to do it and makes debugging a run a bit harder
2. could you add something like "------ time stamp -----" to automatically appear in the output window for each run
3. file management suggestion. the hub menu idea is cool. have you considered having a "special" type of file that would be the equivalent of the C header file that is automatically included with each program if they put an include command in their source. this would allow a common setup code across all missions.

basically something

include "team2_header.py"

for the Mac Bluetooth Bug?

On a Macbook Pro (M2 based) & Macbook Air (M3), if i have a Bluetooth mouse connected when trying to connect to a Spike Prime hub I get the following:

An unexpected error occurred. Please consider reporting this so we can make a better error message.

Failed to execute 'getPrimaryService' on 'BluetoothRemoteGATTServer': GATT Server is disconnected. Cannot retrieve services. (Re)connect first with device.gatt.connect.

if turn off the mouse, connect the hub, and reconnect the mouse it works. just kinda odd.

btw, we have a similiar problem with Lego Spike application as well.

[dlech]

Thanks for the suggestions!

if turn off the mouse, connect the hub, and reconnect the mouse it works. just kinda odd.

Other Mac users have reported similar issues. Not really sure there is anything we can do about this one other than work around it by disconnecting other Bluetooth devices like you have already figured out.

[bcfletcher]

i just temporarily disable the mouse as well. not a big deal but kinda odd.

[laurensvalk]

i'm a coach for an FLL team and we just switched from Lego Spike this weekend. We got fed up with the poor documentation, inconsistent behavior, and incoherent API from Lego. Lego really should just abandon Spike and fund y'all. ;)

😄

file management suggestion. the hub menu idea is cool. have you considered having a "special" type of file that would be the equivalent of the C header file that is automatically included with each program if they put an include command in their source. this would allow a common setup code across all missions.

basically something

include "team2_header.py"

I think you could achieve something like that with the import statement:

team2_header.py:

from pybricks.parameters import Direction, Port
from pybricks.pupdevices import Motor
from pybricks.robotics import DriveBase

# Set up all devices.
left = Motor(Port.A, Direction.COUNTERCLOCKWISE)
right = Motor(Port.B, Direction.CLOCKWISE)
robot = DriveBase(left, right, 56, 128)
gripper = Motor(Port.C, gears=[12, 36])

Then in any other file you can do:

from team2_header import robot, gripper

# Then you can do:
robot.straight(500)

[bcfletcher]

thanks. i see what i did wrong. i had them in a setupRoot() function in team2_header and even by declaring them global they still wouldn't import. but just moved setupRobot's items in the core of the header .py file it works and i can import them now.

[bcfletcher]

a couple of more questions

1. if i set "control.limits()" torque value to max for a motor will it actually have it real effect. or are commands like run_angle always going to use the max torque. the reason i ask, that we are light and moving things on the FLL course and we want to ensure we are getting the max torque out of the motor.

2. it is my understanding that run_angle moves X number of degrees relative to the start position of the motor and NOT to the that angle of motor and wheel if there were aligned at the 0-0 alignment point. testing seems to indicate the former. but in either case we are running into issues with run_angle (for attachment) not being consistent. sometimes off by a centimeter or more and it seems to be speed related. for example, we have found around 150 speed for run_angle seems to be the most accurate and smoothest. go faster or slower and you get inconsistent results. slow speeds below 100 are very choppy movements. i'm i missing something? we trying to move an attachment that is 22 cm long via a Spike Prime Med Motor with the axles about 12.5 CM off the ground we are running dual sets of parallel gears (20) on motor and gear(28) above the 20 and attached to the arm attachment. the dual sets of parallel gears is intended to reduce slippage went light objects at the end of the 22CM long arm. the start is behind the motor (basically a 7 beam attached to the top of the hub by the big button)

thanks

[laurensvalk]

The maximum is the default. Reducing the torque can be helpful in some fragile designs where you want the motor to stall rather than push through.

For running to target angles, use run_target.

The motor is not well suited for speeds below 150 degrees per second (15% of rated speed) due to the relatively high mechanical friction.

[bcfletcher]

thanks on the torque question.

well that definitely explains the very jerky motion for the attachment at below 150 especially at around 50

I will try the run_target command