[Feature] Short term roadmap to multi program support

[laurensvalk]

We have an unreleased, reasonably practical solution to conveniently store multiple programs on the hub.

We haven't released it because it has some limitations and isn't quite as ambitious as some of our longer term plans.

But since this is such an essential and frequently requested feature, I'm beginning to think we should work towards releasing the simplified version for now. What are your thoughts?

What it does
Essentially the following. See here for more details.

It is a fairly minimalist UI, but it has some advantages:

• You can see everything in one glance.
• You can still see your program choice after you start.
• Fast. No fancy scroll animations.
• You can operate this with your eyes closed, or with the hub hidden. (Since it doesn't wrap around.)

Limitations

• Limited to 5 slots. (Naturally, you can still access buttons like you normally do to make more "menus" if you want)
• There is no additional UI in the Pybricks Code editor. Your code just goes into the slot that is selected on the hub.
• Secondary storage is not implemented. So if you make 5 giant programs you'll have a bit less RAM to operate. (On the other hand, this is no less than the current situation).
• The warning about "program too big" will not work correctly, since it doesn't know how much space is used.
• There isn't a UI to easily delete programs (or everything).

Implementation

• On the firmware side, it is mainly a matter of activating one build flag. Since we've made a lot of changes, we could branch this off of the last stable firmware.
• Perhaps we should add a UI to easily erase all data. Perhaps something like holding left and right while booting.
• On Pybricks Code, we need to revert adding the payload for program ID when downloading a program instead of always sending 0. In the current protocol, the payload is already optional, so this isn't breaking the protocol.

[laurensvalk]

@ggramlich

[ggramlich]

This looks good to me.
We were not actually missing this feature too much. I could imagine that we keep the main program on slot 0 and have some calibration oder measurement program on one of the other slots.

Is the slot selection persistent? We could handle both cases well, but need to know the behavior.

• After powering on the last selected slot is selected
• After powering on slot 0 selected

For the competition it is important that the team does only presses one button (potentially after powering on the hub) to start the program and not switch slots.

[laurensvalk]

I think we could pick either one. Happy to follow popular opinion 😄

Are you saying that teams are not allowed to switch slots during jury review? Then we should probably start at the last selected.

[ggramlich]

Are you saying that teams are not allowed to switch slots during jury review?

Yes. For WRO RoboMission you are only allowed to use one program. This is to make sure that the robot autonomously detects the randomized positions and you do not have one program variant for each possible randomization.
Also they had to adapt the rules for this season where any robot (not restricted to Lego) is allowed. So they basically say that you have to define one button (out of the multiple buttons that might be available - like left, right, bluetooth) and you may only press that button once to start the program. In the German competition there is an addendum for Spike Prime that you may switch it on, if it might be powered off.

See

• Point 12.3 of https://www.worldrobotolympiad.de/website/docs/wro2025/WRO2025-RM-Regelwerk.pdf
• https://www.worldrobotolympiad.de/saison-2025/faq#faq1549
• https://github.com/orgs/pybricks/discussions/2144

For FLL it is a completely different deal.

Then we should probably start at the last selected.

Not necessarily, we might always have our main program on slot 0 and like it, if that is preselected. But anyways, we can deal with both options.

[bcfletcher]

We typically use 7-9 programs in FLL with 7 thru 9 being alternatives if something goes wrong with a mission model. however, in cargo connect one of our teams used 3 variants of one mission for the colored cargo blocks... so it can vary a bit between FLL boards...

How About a slightly different variant.
Instead of a box at top either horizontal line at top or vertical line on left. That allows space for 0-9 thus 10 slots

Another option in lieu of the menu discussion ((pybricks/support#2180)) we have been having would be to add a new pybricks function to the hub.

Hub.set_slot()

With allowed values of a slot number “0-19” and optional different character to represent like “a-z”

Each program would define which slot it wants to go in.

This would largely eliminate need for hub_menu for FLL

We would then like a SendAll or “play button all” up capability to send everything in the UI to the robot in one push.
This addresses a major config management problem of not knowing what is really on the robot.

You might want one more command Hub.clear_menu() wipe the robot or a button on the GUI to do it.

[laurensvalk]

Thanks for the input. We don't necessarily have constraints on the UI, but we're just a bit limited on time and resources to implement bigger changes right now.

[laurensvalk]

If I might ask both @ggramlich and @bcfletcher : What is the biggest total program size your team has ever made?

If you used a menu, try loading the main program since this will include all your missions.

You can see the compiled size in the browser console (Press CTRL SHIFT I and choose the Console tab). For my test program it says 209 bytes for example:

[bcfletcher]

our submerged python code is here:

https://github.com/bcfletcher/lego_projects/tree/main/FLL/2024_Submerged_Pybricks_Code

the main library is few hundred lines. missions are a hundred or so at most though it depends

we try not to put too many missions in one task to reduce risk of something going wrong and blowing a lot of points, we sometimes have different implementations of same mission depending on value of mission and where robot could be if errored out on a task, we also have the kids in groups writing tasks, and lastly (and more importantly) multiple task programs makes CM much easier. we merge and load the via our hub_menu program by changing rev numbers on tasks that way we can go "back in time" easily to a previous task implementation if we need to.

i understand the time/resources constraints y'all are under and we really appreciate the work y'all are doing.

i actually gave a short talk on using Pybricks for FLL at the FIRST Chesapeake mentor conference this weekend. one of the points we made was how your block coding (BC) implementation provided a way to learn python to support migration from blocks to python so easily. people were saying "wow that is so cool!"

it's just the awkward and limited hub_menu integration that is the major drawback for using BC for FLL.

my plan as a coach is to BC mode to help kids transition from the "Scratch-like" world.

boyd

[laurensvalk]

Thanks! The number of lines isn't actually the most accurate metric when it comes to size of the compiled code. What is the value you see when following the steps above?