Skip to main content
Teacher Portal

Sequencing Challenge

  • Set up—The Builder and Driver should set up your map and robot the way you had it when you finished the Play section. Place the robot at the Start point. The Programmer should open the Recycle Run project in VEXcode IQ. The Recorder should review the task to make sure that your project is meeting all the requirements.

  • Review—The Programmer should run the project as is. While the robot is driving, the whole group should watch it carefully.

  • Troubleshoot—Is the robot moving the way that you expected it to? If not, where is it different? Are there missed steps? The Recorder should review the list of steps you created aloud with the group. As the recorder reads, the Driver should pick up the robot and move it along the steps; and the Programmer and Builder should check the code sequence to make sure it matches the steps that are being read. When you notice a missed step or incorrect block, pause the process to fix it.

    • Is that the correct block?

    • Are the parameters accurate?

    • Do you need to add more blocks?

  • Refine—Each time you fix a portion of the coding sequence, the Driver should return the robot to the start position, the Programmer should rerun the project, and the group should watch the robot to make sure the changes are doing what you expected them to. Repeat steps 3 and 4 until your project meets all the requirements successfully. Check in with your teacher to share your revised code and robot path.

Teacher Toolbox icon Teacher Toolbox - Speaking in Pseudocode

If students are having trouble getting their sequences to behave the way they intend for them to, there may be a disconnect between the idea and the code block. The comment strand of actions that groups created in the play section is really a pseudocode, and can be a more accessible way to work through sequence issues with students. Translating each step of a pseudocode into its component blocks is a useful skill, and one that students will continue to work on throughout their programming experiences.

What is pseudocode?
Pseudocode is an informal way of writing your computer instructions in plain English so it's readable by anyone who understands the problem. That's why it has the pseudo- prefix. It's like code because it is a series of actions or blocks within your project but it isn't in an actual programming language. It is in your everyday language so that you can use it to plan and organize the real code for your project.

Coding Challenge

  • Set up—The Builder and Driver should set up your map and robot the way you had it when you finished the Play section. Place the robot at the Start point. The Programmer should open the Recycle Run project in VEXcode IQ. The Recorder should add the obstacle block to the map in a central location. Check in with your teacher about your obstacle placement before moving on.

  • Review—The Programmer should run the existing Recycle Run project. The whole group should watch the robot as it moves, and the Driver should stop the project when/if the robot hits the obstacle.

  • Revise—Locate the point in the [comment] block list and the coding sequence when the robot met the obstacle. Use the [comment] blocks to amend the plan to navigate around the obstacle.

  • Rewrite—The Programmer should then amend the code sequence accordingly—removing, adding, or editing parameters of blocks to match the new plan. When the code changes are complete, rerun the project and watch the robot to see if it moves the way that you intended it to. If it does not, try to troubleshoot within your group before asking your teacher for help.

  • Troubleshooting—Is the robot moving the way that you expected it to? If not, where is it different? Are there missed steps? The Recorder should review the list of steps you created aloud with the group. For each step, as the recorder reads it, the Driver should pick up the robot and move it along the steps; and the Programmer and Builder should check the code sequence to make sure it matches the steps that are being read. When you notice a missed step or incorrect block, pause the process to fix it.

    • Is that the correct block?

    • Are the parameters accurate?

    • Do you need to add more blocks?

    Check in with your teacher to share your new code and robot path.

Teacher Toolbox icon Teacher Toolbox - Obvious Obstacles

In this challenge, where students place their obstacle will have a big impact on the level of difficulty of the challenge. When students check in with you about their block placement of the obstacle, make sure that it is not obstructing the map so much that there is no longer a solution, and conversely, that it isn’t so out of the way that the group doesn’t need to change anything in order to avoid it. The addition of the obstacle should require the group to change and/or add blocks to their code, or encourage them to design a new path altogether.

Efficiency Challenge

  • Set up—The Builder and Driver should set up your map and robot the way you had it when you finished the Play section. Place the robot at the Start point. The Programmer should open the Recycle Run project in VEXcode IQ. The Recorder should review the task to make sure that your project is meeting all the requirements.

  • What is code efficiency?
    If you needed to get 3 things from your kitchen, you would probably go get all 3 things in one trip, instead of making 3 separate trips. Why? Because it would be more efficient. Efficient means working something out without wasting any time, energy, or materials. So how does that connect to programming?

    Code efficiency means that a project is written to work well and quickly, using the least amount of work, or steps, properly, while still doing its job. It is important because it reduces the risk of a program not functioning well, and in turn, causing problems for other parts of a program that are running around it. The efficiency of a code can be a measure of quality, and when we write projects in VEXcode IQ block, we are often looking for the most “efficient” project as the preferred solution.

    Basically, code efficiency is a principle that means you want to write a code that accomplishes your goal using the fewest commands, or blocks, possible.

  • Rethink—With your whole group, look at the path you designed for your robot to travel. Is there a shorter route the robot could take? Is there a different way to meet the requirements more quickly?

  • Revise—Try to amend your code sequence to use 3 less blocks, while still meeting all the
    requirements. Use these questions to help you find places to revise:

    • If we remove this block, what will the robot do?

    • Is this block redundant? (Repeating something that doesn’t need to be repeated.)

    • Is there a single block that can do the work of two or three that are in your sequence?

    • Are there any blocks or sequences repeated over and over which could be replaced with a loop/repeat block?

    When the code changes are complete, the Programmer should rerun the project and the
    group should watch the robot to see if it moves the way that you intended it to. If it does not, try to troubleshoot within your group before asking your teacher for help.

    Check in with your teacher to share your new code and robot path.

  • Troubleshooting—Is the robot moving the way that you expected it to? If not, where is it different? Are there missed steps? The Recorder should review the list of steps you created aloud with the group. For each step, as the recorder reads it, the Driver should pick up the robot and move it along the steps; and the Programmer and Builder should check the code sequence to make sure it matches the steps that are being read. When you notice a missed step or incorrect block, pause the process to fix it.

    • Is that the correct block?

    • Are the parameters accurate?

    • Do you need to add more blocks?

Teacher Toolbox icon Teacher Toolbox - What is Code Efficiency?

In this activity, students are introduced to code efficiency. Students are trying to revise a code to use 3 fewer blocks. The fewer the blocks means that there are fewer places that a code could go wrong, and ultimately should result in less troubleshooting. Here are some questions you might ask to help your students frame their thinking around efficiency:

  • Can any of the distances in the parameters be combined?

  • Are there behaviors or blocks that are repeated? Why?

  • Is there a shorter path altogether?

Make sure that students check their projects each time they remove a block to make sure that they are still accomplishing the goal, just with a shorter code.