Menus, Blocks, and Setup code

[joshsloat]

My kids are struggling to combine block-based coding with a Python menu. We cannot figure out how to get mission-based functions (tasks) in blocks files – called from a menu coded in Python – to ever work correctly since the set up code in the block-based mission files doesn't seem like it's ever running.

Rather than importing entire files (since the import statement will run a program only the first time), we're attempting to call mission-based functions as suggested here.

So we have a have a menu.py that looks something like:

from pybricks.tools import hub_menu
from MissionOne import *
from MissionTwo import *

# Make a menu to choose a letter. You can also use numbers.
selected = hub_menu("1", "2")

# Based on the selection, run a program.
if selected == "1":
    runMissionOne()
elif selected == "2":
    runMissionTwo()

• runMissionOne is a Task in MissionOne.py
• runMissionTwo is a Task in MissionTwo.py

Both MissionOne.py and MissionTwo.py have the same set up block that configures a driving base and an attachment motor.

When selected via my menu, any print blocks in runMissionOne and runMissionTwo print to the console, so I know things are somewhat wired up. But the robot doesn't drive and motors don't turn. No errors are logged to the console, but I'm thinking that the set up block isn't running since I'm calling tasks in MissionOne.py and MissionTwo.py, as opposed to running directly from the program block as you would if you weren't using a menu. If I manually call runMissionOne from the program block in MissionOne.py, it works fine and the set up code appears to run to configure my driving base and motors. Please help! I know we're close, but it's just not clicking how to get the set up blocks to run doing things this way.

[BertLindeman]

Hi,

In your menu program you do

from MissionOne import *

The motor setup code doesn’t run because it's not executed automatically during the from ... import *.
Only definitions are imported — execution (like initializing motors) must be done explicitly.

I understand you do not want to do

import MissionOne 

because that only runs on the first import.

Have a look at the example in discussion 1387
The motor can be setup in the menu program and passed to the mission programs as argument(s)

Bert

[BertLindeman]

See another example in discussion 1344

[joshsloat]

Thanks, @BertLindeman. This makes sense, but just to confirm, there's no way to do mission tasks in blocks files, a menu in Python, and have set up code for the driving base, motors, etc. in a blocks-based file? If we want to go this route (which seems like it's the recommended way in the doc), we need to do all of our setup in a python file (like the menu) and then pass the python-created objects into the individual blocks-based files?

[BertLindeman]

have set up code for the driving base, motors, etc. in a blocks-based file?

Not that I am an expert.
But I would not know how to make a function block that contains the setup statements.

The setup for each mission would be just a small part of the complete mission I think.
And the setup part is most of the time stable.

Bert

[laurensvalk]

Rather than importing entire files (since the import statement will run a program only the first time), we're attempting to call mission-based functions as suggested here.

This example is actually running them on import, not calling functions. For most students, I would recommend keeping it simple that way. Everything will then work just like independent programs. Each with its own setup, which I think is what you are asking for?

[laurensvalk]

See also #2193, would love to get some opinions. Thanks!

[joshsloat]

@laurensvalk Since you only have 150 seconds to compete, every second counts! Last season, we wasted 45 seconds of our total time in quarter circles messing with menus and swapping attachments. We have a plan to deal with attachments, but are hoping to optimize where we can with the menu, as well.

Our goals:

• Do as much coding as possible in blocks because we have a very young team.
• Have a menu that is flexible and doesn't paint us into any known corners. Our eventual goal is to have a menu that either auto advances to the next mission menu option after completion (examples have been shared elsewhere on here for that) or pulls up the correct menu option based on a color sensor reading a color from LEGOs on an attachment. Either option would need ability to override with a more manual selection if things weren't working right in competition.

We're trying to take an iterative approach and we don't necessarily know yet how to accomplish what we want to accomplish, but also don't want to knowingly limit options. So when I read the following in your post, I thought it made the most sense to start with the least limited option, which would be missions as functions:

you might want to organize your code a bit differently in case you want to take this menu technique even further.
The import statement will run a program only the first time, even if you run the same import again in the same program. This is why programmers would usually write the “mission” as a function (a task) instead. You could import that function and call it from your menu program as many times as you like.

Our logic/intuition could certainly be flawed – just what made sense at first glance – why limit if you don't need to limit (but that is also introducing extra complexity as you've pointed out)?

Your example for building a menu from blocks could certainly work if we could find a way to mitigate the risks. And maybe I'm over-indexing on the import limitation, altogether. Any recommendations on direction knowing our goals now?

Re: data points on how many programs FLL teams need to run, I went to worlds this year and based on observations and discussions, the best teams in the world are averaging 7-8 runs. So 20 would seem extreme, but 10 would be more than reasonable based on my observations – leaves room for a couple of utility program slots as well (that you could use for things like motor resets, checking for gyro drift, etc) or even backup versions of runs (which I know some teams have).

Re: #2139, I would have to think some more on the specifics of the implementation, but in general, I think that not having a default blocks-based menu (ignoring the more complex stuff like I discussed above) that provides a basic ramp from SPIKE Prime slots (requiring essentially all teams to write a python menu) is one of your biggest barriers of adoption (alongside the block-based doc being a work in progress). And FWIW, we are absolutely LOVING Pybricks – you're crushing it – these are just the biggest unmet needs I've identified as a new team working on making the switch.

[laurensvalk]

Thanks @joshsloat, I totally agree that a menu and better starter guides are needed.

I think #2193 is the quickest way for us to get 5 easy to use slots. Users won't need to make a menu or use Python. It's not 20 slots, but probably still better than 1, at least for now.

[joshsloat]

@laurensvalk Agreed 💯. And if you need more than 5, you're probably in a position to be able to do something more custom in Python anyway.

Assuming you had a main menu Python file that set up your driving base, sensors, etc, and then passed those objects in to blocks based mission files via parameter... I was thinking, the other downside of the import approach (vs mission functions) is, let's say you have 5-7 imports – one to support each run (so multiple missions per blocks file, but one blocks file for each run) – you have 5-7 set up blocks that likely each need to do the exact same thing (since the driving base config would rarely change between runs). So when you need to tweak your driving base config, you're having to do it in 5-7 files instead of one.

Would you recommend setting up something like a library that would essentially be a factory for creating the driving base, motors, sensors, etc that would be available to the mission blocks files via import? Perhaps along the lines of https://github.com/orgs/pybricks/discussions/1344#discussioncomment-7915027

[laurensvalk]

That could work. As you might have seen, there are two distinct approaches discussed in that link:

1. Creating general purpose drive functions where you can pass in an object
2. Importing a previously initialized object to use in a drive base

These are not mutually exclusive and can be combined, depending on what you'd like to do.

I think you called the second one library.py in your approach. That is fine, though library is usually used to describe technique 1. Technique 2 is more like using a common config file.