Guidance for Rookie FLL team on transitioning to Pybricks

[harikun77]

We have a team of 6th graders for the next FLL season (2023-2024). The team has been on the rec league for the past 2 years and thinking of transitioning to challenge/qualifiers this year. Has been exposed to Spike Block programming with knowledge of developing custom blocks for Gyro (Turns and Moving Straight). Came across Pybricks and thought this would be a good time to transition as I believe PyBricks has been more responsive and accurate for some of the pre-defined blocks that are available as modules. (Compared to what is available from LEGO)

Wanted guidance on examples / codes from any veteran teams on how to organize the modules / code.
For eg:
(1) The team had split the Code that was loaded into different memory slots last year based on the "Runs". The team had 4 runs with Attachment/Positioning changes. I understand that there are multiple ways of doing this on Pybricks as a single program by detecting specific button presses or using a menu to assign letters or numbers for the Runs
(2) I see that the latest Beta has GyroDriveBase which seems to include accurate Gyro measurements on making sure the Robot moves straight or turns (including accel/decel code). If the team maintains the Robot center of gravity and makes sure the attachments dont create unnecessary drags, would just using the Gyro Drive base suffice?
(3) How is the code organized? A main program and individual "Runs" as separate programs that is called? And any custom "My Blocks" that is also called separately or either in the main program?

Wanted to see if this can be a good challenge for the kids during summer while we wait for the challenge kits to be shipped in August. If possible, I was thinking of having the kids write their code using Pybricks of the previous years Run to get familiarized and assess accuracy.

Any advice and guidance appreciated. If there are code examples from previous year that teams are willing to share, it would help a ton on guiding the team on the right path.

-Harikun

[thehomelessguy]

So we were a first year team (exploding toaster supernova) and used Pybricks. Had 400 points programmed but only got 375 in our best run. Still won the robot game at our state event but didn't understand the rest of the competition (being our first year) so did not place/move on.

Anyways yeah you will have to program some sort of UI. One of the creators of Pybricks does have a nice demo code here in the GitHub discussions, that is a good place to start. I can also share some of our code if the kids agree (they are a bit possessive of it). You should probably program it so it automatically loads the next run at the end of the 1st so that only a single button has to be pressed between runs to start the next one (saves several seconds).

In terms of the gyro we did not use it this year. Our robot was well balanced and didn't need it. Also the gyro only does straight and tank type turns (to my best understanding) and not curves which often can be very useful. Still we will probably use the gyro now that it is available but we were able to do pretty precise driving without it.

I highly suggest you write some remote code. Being able to use the Lego Bluetooth remotes to control your robot while you design attachments for the various gameboard missions is immensely helpful. Attached is a brief video demo of what I mean.

Finally also consider buying some of the 4 port technic hubs and extra large angular motors from Bricklink. For example we made copies of our modular attachment robot using the very cheap technic hubs for the kids to experiment with/build attachments sets for. Since they only have 4 ports and not 6 these did not have light sensors but this was not a problem as they werw used mostly in remote control mode. Here is also a photo showing 'Toasry" our bot and his slightly less capable technic hub cousin Crostini.

We are also working on creating an Edublocks (edublocks.com) type interface for Pybricks. Still very much a work in progr as but if we get it done you will be able to do block style coding with the full power of Pybricks (it really is that much better than the Lego software). I think it will be extremely popular once it is cobbled together.

[thehomelessguy]

Video of remote controlled bot:

https://photos.app.goo.gl/H1eUAYvZ1vTRyDuA8

Video of our state competition (may need to rewind a bit our run starts at about 4:36:00)

https://youtu.be/I4g1R-PBdCY

Finally I highly recommend finding a good way to store and organize your Legos. We went a bit overboard. I ended up bolting 4 harbor freight 42 inch tool cabinets together and buying toolbox organizers to sort everything (admittedly this has all of my family's Legos in it and is used as our build area when not doing FLL). Also past years mission sets/mats are only 100 bucks on andymark. Highly recommend buying all the ones you don't have just for the extra Lego pieces/ability to practice new things in the off season.

[laurensvalk]

Thanks for your response.

Just as a note: when you use the GyroDriveBase class, the gyro is used under the hood for all methods, including straight, turn, and curve.

[thehomelessguy]

Very cool. I have not tried out the gyro yet. I had assumed they just did it for straight/turn and not the curve method (as that is as bit trickier) but good to know you can use the gyro for everything.

[laurensvalk]

Thanks for considering Pybricks for this season!

(1) The team had split the Code that was loaded into different memory slots last year based on the "Runs". The team had 4 runs with Attachment/Positioning changes. I understand that there are multiple ways of doing this on Pybricks as a single program by detecting specific button presses or using a menu to assign letters or numbers for the Runs

Indeed. We are currently looking at ways to make this simpler for teams. See #1064 for what we are thinking about. On that list, idea 1 already works if you need something right now.

(2) I see that the latest Beta has GyroDriveBase which seems to include accurate Gyro measurements on making sure the Robot moves straight or turns (including accel/decel code). If the team maintains the Robot center of gravity and makes sure the attachments dont create unnecessary drags, would just using the Gyro Drive base suffice?

If your robot doesn't have drag or unbalance, you might even be fine with the regular DriveBase as the @thehomelessguy's teams did.

But indeed, you can use the GyroDriveBase to help compensate for non-idealities like wheel slip.

You can also take things into your own hands by reading the heading with hub.imu.heading and make your own drive routines, just as you would have to do if you used the LEGO firmware.

(3) How is the code organized? A main program and individual "Runs" as separate programs that is called? And any custom "My Blocks" that is also called separately or either in the main program?

By default, running a program with Pybricks Code will download that program to the hub, including anything that it imports. This lets you organize your code into as many submodules as you like.

This is technically "just one" program, but this is pretty flexible since it includes whatever it imports. This is what makes the menu code I mentioned above work: the main "menu" program imports each of the missions.

[thehomelessguy]

We will be posting our starter code that allows for runs to be organized well (each run is a separate instance of a class that hold the display data/etc.).

Our team is also exploring the position of developing a edublocks.org-esq interface to run on top of Pybricks so that teams like this could use block programming but still have it spit out the actual underlying python code to act as a bridge between Lego scratch and Pybricks. Very much a work in progress as we have a ton to learn to make this happen but it will exist someday.

[laurensvalk]

Cool! You might like to know that we have some plans for block coding as well. 😄

[thehomelessguy]

I would love to hear your plans for block coding (so that we don't dublicate any work). I think that it would be used very widely if such were available especially with the drivebase/gyrodrive base modules.

[laurensvalk]

There are roughly four steps to it:

• Allow parallel coding in Python, so that we can have multiple block stacks later on. See Multitasking pybricks-micropython#166
• Integrate a block language like Make Code or Blockly in Pybricks Code. We have working proof of concepts, but nothing very substantial yet.
• Develop the block coding paradigms we want to use. For example, we have some ideas on how to deal with motors, sensors, and parallel coding.
• Design/implement the blocks and their Python mapping. We have drafts for most blocks by now. If we go ahead with this, we plan to invite teachers/coaches/students to give feedback.

[harikun77]

Thank you @thehomelessguy and @laurensvalk for the suggestions.
Our team will definitely try it out during the summer.

@HomelessGuy > The starter code would be super helpful for the team to analyze and build upon. That should help the team to start with modifying the current block code they already have into pybricks while we wait for Aug1 release!

harikun

[thehomelessguy]

We are creating a github tonight and putting this seasons code up there as well as a cleaned up version. Just ask that the Morgantown Area Robotics/The Monongahela Cryptid Cooperative is credited if the code it used (MARS). Will send you the link as soon as it is done. It is very modular and should meet your needs. Even has code to create technic hub bots if that is desired as well as the remote code.

[MonongahelaCryptidCooperative]

See here for our code/a good modular starting point

https://github.com/MonongahelaCryptidCooperative/FLL/

[SrNersoSauro]

I believe it is from the "stop" setting that comes from extra_code.py.
If I remove it the multitasking block function works, if I put it in it gives the image error.
I wish they both worked :(

[MonongahelaCryptidCooperative]

You shouldn't been a multitask block. Yes it will break because the code is not written as async/multitasking. It's not really needed for FLL (unless you want flex and have the robot drive around while playing music).

Is there a reason you are using the multitask block? You really shouldn't need it at all.

Again all will be well once it is all one file and you will be able to use the multitask block no problem. But for now don't use it or if you do will have to change the extra code functions to work with async. But yes that is the problem. So either get rid of the mutli-task block or re-write the python code to be: def async ....

[laurensvalk]

Thanks for the screenshots. In that case I have good news.

• Within a few days, we'll release a beta version with a few new blocks. Once @MonongahelaCryptidCooperative update their code as they indicated, multitasking will work in their code too.
• There is now also a way for library writers, to make their code work both for single task and multitasking. (But it won't be needed in this case, as per the above).

[MonongahelaCryptidCooperative]

New version of the code is up at https://github.com/MonongahelaCryptidCooperative/FLL-Block-Code/tree/main

It is now a single file using the latest blocks in the beta version of Pybricks that was just released. Should work fine with the multitasking block although you shouldn't have to multitask unless you want to do something like play music while driving/displaying text strings/etc.

tested and works (initial code was posted untested and I actually found a bug on how the block interface parsed conditional states that only contained a comment block).

[MonongahelaCryptidCooperative]

Code is now commented/slightly improved. It does work with multitasking as well (added some rumble along with the beeping in RC mode when taking measurements). There is both an RC/XBOX version and a non-RC version.