FLL Challange Team Code and Trials

[TheWendyPower]

The FLL Challenge team that I work with has started using Pybricks for their game code. You can see the current year's game HERE. Their season isn't over, as they are heading to Texas for the FIRST Championship in April. They finished writing their functions last week, and we have started working on writing missions.

Here is their robot POW, with a drop-in energy cell gathering attachment (an attachment they use for many missions).

This is an upgraded version of the chassis. Before the wheels were further back, like this:

This change was only made after we were having very inaccurate turns. Wheel diameter and axel track were measured using calipers. We figured, after a little testing, all the weight up front is part of the inaccurate turns. The team flipped the motors to put them closer to the center of the robot and that helped. Unfortunately, it isn't centered enough. They can't completely rebuild the robot this late in the season. This is where the turn by gyro is going to make a HUGE difference in turn accuracy.

Because they currently can not count on the same turn degree every time, with the current robot build, they may have to go back to LEGO Python. Even though the robot is being lined up in the same place (using a jig) the robot isn't being consistent.

What we lose if we have to go back to LEGO Python:

• importing other documents
• multitasking
• custom menu
• amazing startup speed
• smoother overall running robot

Ultimately, the team doesn't want to go back to LEGO Python, but if they can't get consistency there isn't going to be much of a choice. When doing testing at home with my kids, we didn't see these issues. However, we had a much smaller front-wheel drive robot and no attachments. The biggest reason for posting this here is wondering if you have any suggestions to help. I do have the team's robot at home with me, and my kids who are on the team can do some testing with it. I'm happy to share any more information you might need.

Another suggestion, which I have mentioned to @laurensvalk on Mastodon and am more than happy to help with is readability in dark mode. So much of it is currently the same color. The light mode has a good variation, which is something we miss from coding in VSCodium.

[dlech]

Re: Texas, congratulations on making it to the top!

Re: gyro, we we will hopefully have something easy to use later this year, but not before your competition. There are some experiments with a Python implementation for getting a yaw angle in #675 that you might find useful.

Re: dark mode, happy to take a pull request to improve it. We are currently using a theme called "tomorrow night eighties" from monaco-themes. We could tweak some of the colors in that theme or consider a different one.

The Pybricks Code source code for it is here: https://github.com/pybricks/pybricks-code/blob/6fd9bafe609c4175fd42f56baa3052b1e56c2133/src/editor/Editor.tsx#L66-L70

[TheWendyPower]

Thank you! The kids are super excited and are looking forward to the experience.

The colors don't have to be bright like the theme we have been using, just more of them. I actually like the muted colors that are in the theme Pybricks is using for dark mode. I will check out both of those resources.

[dlech]

One more trick that you will need for this:

With the cursor in the program, press F1 to bring up the super secret command palette and type in inspect to find Developer: Inspect Tokens. Select that option, then you can move the cursor around and see the names of tokens. It looks like the reason most things are the same color is that most things are identified as identifier.token. So we might need some sort of regular expression or other rules to differentiate between these and other identifiers (we don't have semantic tokenzation like the Pylance extension in VS Code, so we might be limited a bit in what we can do).

[laurensvalk]

Thanks so much for sharing your story. We do hope your students will want to continue with Pybricks 😄

And perhaps to help with that.... we've just published an experimental but easy-to-use gyro solution here: #989

We originally wanted to get complete gyro support ("6D") and drivebase integration all at once, but maybe we're setting the bar too high. If the solution in #989 makes 90% of people happy, we should probably go ahead and merge it.

[TheWendyPower]

At this point, all the team needs is what is in #989. I shared the LEGO version of their turn-by-gyro in that thread as well. They really want to stick with Pybricks, they are loving it and are utilizing the ability to import.

[thehomelessguy]

I will say if you build your robot around the fact that pybricks doesn't have gyro support you can make it work extremely well. We are getting 400 points in 2:25 using pybricks. Too late for this year but looking at their robot I think most of the problems are mechanical and arise from certain design choices. Here are some suggestions:

1. Need to support the wheels externally as they can wiggle quite a bit otherwise. Look at either the lego ADB plans or some of the more advanced plans off the prime lessons website.

2. The DriveBase from pybricks doesn't do well when things drag or are asymmetric. We tried having a box that held our project model and 3 barrels to drag to the middle for the power to x. It worked fine for that but threw off our accuracy enough we couldn't reliably place the looped barrels on the hooks during the same run as we'd be off by +/- a centimeter when lining up. We had to redesign our attachment so that the box was held off the ground and then dumped when it got to the correct spot.

3. A bit counterintuitive but we found using only one centrally placed caster is generally better as sometimes they can have different rolling resistances.

Not at all related but one of the things we really like about pybricks is that you can use technic hubs as "blind" versions of the robots. You can create extra bots pretty cheaply (I found a seller selling technic hubs for $18 and large angular motors for $16). Here is a picture of both our actual competition spike bot and one of our technic hub "copies" (we have enough that each kid gets one to work with/experiment on). Note they are both naked without any of our slide on attachments. We wrote our code modular enough that it runs on either version of the robot but as it lacks light sensors the technic hub can't do everything (we use line following/squaring in our 2nd run) but it can fully do 4/5 of our runs just fine. If such was legal we actually could compete with a technic hub and probably score 300+ points.

It also makes a great development platform when paired with a bluetooth remote (less than 10 bucks on bricklink/ebay). https://photos.app.goo.gl/2NsmXeuHAXZwCcu99
Our team basically just takes a base robot, one of the mission models and then builds attachment sets, testing their functionality in real-time with the remote. Later we write the code once they have something that works. Very hands on and the kids seem to enjoy it.

[TheWendyPower]

Thank you so much for sharing what your team is doing, and some tips for building improvements. I love the idea of testing with a remote. This is only our second year as a team, and there is still so much to learn.