Where to start? Before you can jump in and start creating your program, you have to spend some time figuring out what the program needs to do and how you plan to do it. This thought process, mapping out and thinking through the program logic is your design process. If you’re working as a member of a team, you will have to do this process as a group, and it can be a challenge for team members to agree on the best way to do things. Remember to be open to all ideas during the design process. An idea that seems a bit crazy could actually be the best solution to the problem at hand.

Choosing the Right Problem

The first step in writing good code is to make sure you understand the problem you are trying to solve. If you are on a FIRST LEGO League (FLL) team, you will have a series of missions your team is trying to complete to gain points. It’s a wise idea to sit down as a team and organize the tasks in order of difficulty,easier mission first and the harder missions last. Some teams might sort the missions by their value in points, but if you focus solely on the missions that give you the most points, you might find yourself spending way too much effort on a harder mission when you could have done some of the easier missions and scored more combined points.

If you look at the points-ordered list of missions in Figure 2-1, you see that “Bring the car to base” is worth the most points. But when you look at the list of missions ordered by difficulty in Figure 2-2, you notice that the “Bring the car to base” is the most difficult while the “Carry recycled parts to center” is easier, and if you’re able to do all six items, you get a cumulative score of thirty points.

However your team decides to order the missions, it’s important to have a road map of each mission you will attempt to complete with your robot. The goal is to design a program that cannot only solve a mission but that can do it consistently over and over. A program that can complete its mission every once in a while is not going to give you any awards; it will give you only headaches. Try not to get frustrated if the first solution you come up with doesn’t work as expected. During the design phase of your programs, you will make multiple attempts at finding the desired solution.

What you’re doing here is called Iterative design. This is a design methodology based on a circular process of designing, writing, testing, analyzing, and refining a program. Based on the results of testing the most recent iteration of a design, changes and refinements are made. This process is intended to ultimately improve the quality and functionality of a program.

Define the Problem

When starting, you need to fully understand the problem you are trying to solve. With FLL, the problem will be the mission you are trying to complete. Make sure you read and understand the game rules for each mission. Also, be aware of any changes to the rules before you attend your robot event. There is nothing worse than showing up to compete and finding out that you have been practicing with the wrong rules or that you have an improper understanding of the rules.

Many of the missions will have multiple steps involved, so break down the steps into simple-to-understand tasks. Don’t try to write them as a program right now; just list the steps in simple-to-understand language. Act as if you were explaining the mission to friends and you want to tell them what needs to be done to complete the mission.

If you were to break down a mission that involved a robot grabbing an item and returning with it to your base area, the list might look something like Figure 2-3. The process of “breaking down” a mission involves reading the rules and understanding each task required by the robot to complete the mission. Even though some of the tasks may seem insignificant or obvious, you will need to include them in your list. Every little detail is important at this point.

Having a simple list of tasks for a mission can make even the most complicated missions seem much less complicated. If any of your tasks are overly complex, you may need to break the task down even further. The goal is to keep things simple and easy to understand. For example, in Figure 2-4 you see a more complicated task list for a mission that involves locating a car on the game field and returning it to base.

In this list, you notice that one of the tasks is to “Grab the car.” To you this may seem simple, the logic being that the robot will use a claw attachment to simply grasp the car. But once you write the code for the “simple” task, you will find that it’s not as easy as you first imagined. The task of grabbing can involve some more complicated logic, such as:

• What state is the claw currently in? Is it opened or closed?
• Is it opened enough to fit the car?
• How do you close the claw attachment?
• When do you know that the claw actually has the car in its grasp?

Write Pseudo code

Once you have the list of tasks, it’s time to think about how to make them work. You are still not ready to write NXT-G code. What you’ll start with is called “pseudo code,” which is writing out, in human-readable form, how to do the tasks. You will still list out the commands needed to complete the tasks—you don’t need all the details that the computer cares about. Pseudo code is easier for people to understand than the NXT-G programming language. In Figure 2-5, the teammate’s pseudo code is being presented to her team members. Being easy to understand is important when you need to explain your ideas to other teammates and the technical judges at your event.

You can also use flow charts for more complicated solutions. If your tasks include lots of conditional logic, it helps to map out the possible paths the logic could take. A flow diagram can help you keep things in perspective and not get lost in the logic flow. Figure 2-6 is a sample flow diagram as presented to a team.

Mapping your code out in these forms helps you find any possible flaws in the logic before it gets to the actual code stage. Also, it allows you to work with your team and share different ideas and receive input from others to improve the solution.

Identify Possible Solutions

When working with a large team, it can be hard for ideas or solutions to be heard from everyone. It’s important to remember that teamwork is a big part of a successful team, and teamwork is judged in FLL. A good idea is to break into smaller groups (or even individuals) and work on your pseudo code to solve the current mission task.

Once everyone has his solution ready, come back as a group and present the solutions to the team. This is where having readable and easy-to-understand pseudo code comes in handy. Flow diagrams can be helpful as well, since they will give your teammates a visual idea of what you’re thinking.

Now that the ideas are being presented, it’s a good time to get input from other teammates. Don’t take any new ideas or criticisms personally. You are all working toward the same goal—having a dependable and well-thought-out program that will solve the mission effectively and consistently.

Sharing ideas in a free-form manner is sometimes called a “brainstorming session.” In such a session, there is no such thing as a bad idea. All ideas and solutions should be welcomed. This doesn’t mean that they will work, or even be feasible, but by sharing these ideas, the group might form new ideas and solutions. Again, remember not to take suggestions or criticisms personally—there are no wrong answers or dumb ideas in brainstorming sessions.

Create the Code

Now that you have a possible solution, it’s time to put it into action by creating real NXT-G code from your pseudo code. Once you get some experience with NXT-G, you’ll find your pseudo code becoming closer to real code as you use command names that are similar to the block names used in NXT-G. This will make the transition easier and the creation process smoother.

For example, let’s presume your pseudo code looks something like this:

1. Raise attachment arm up
2. Move forward 6 inches
3. Turn 90 degrees to the right
4. Back up 3 inches
5. Drop attachment arm down

The NXT-G blocks are very straightforward in this scenario. All of the tasks defined are “action” tasks, so most of the time they will involve using the Move or Motor blocks in NXT-G. Figure 2-7 shows some NXT-G code that might be generated based upon the preceding list of steps.

Now look at a more complicated list of tasks, such as:

1. Move forward
2. Stop when Touch sensor on port 1 is bumped
3. Drop attachment arm
4. Turn 90 degrees to the right
5. Move forward
6. Stop when Light sensor on port 3 sees Black
7. Lift attachment arm

With this list of code tasks, you can see that there are some “action” tasks as well as some “sensor” tasks, which involve touch sensors and light sensors. The NXT-G code in Figure 2-8 is an example of what your final program might look like.

Let’s look at an even trickier list of program tasks. This list involves “action”, “sensor,” and “conditional logic” tasks:

1. Move forward 3 inches
2. Turn 90 degrees right
3. Move forward
4. If Light sensor 1 sees a value greater than 50% turn right
5. If Light sensor 1 sees a value less than 50% turn left
6. When Ultrasonic sensor 1 detects object at 3" Stop

As you can see in Figure 2-9, the logic has grown more complicated and might be hard to read as NXT-G code. The code is easier to understand when you reference the preceding pseudo code.

It would be a good practice to include the pseudo code as comments in the NXT-G code; doing so will make it easier for you and team members to understand what the code is doing when you reference it later. Even though code that you write makes sense to you on the day you write it, in a week or so you may forget what the logic flow for the program was intended to be.

Test the Solution

When you run your new program on your robot, don’t get upset if it does something you didn’t expect. Rarely does the first attempt at any program work as you desire, and even the simplest solution might need some “tweaking” to get it just right. This is true for anyone who writes software programs of any type.

The best thing to do during testing is to run the new program multiple times and see if you get the same result each time. Even if it does what you expected, run it a few more times and see if the successful outcome repeats itself consistently.

If your program is not working as expected, observation is going to be your best tool in determining what is occurring with your program. Running a robot program over and over while making detailed observations is a very helpful debugging technique. A good trick is to, while the robot is running, verbally identify which NXT-G blocks it’s running as the robot goes through the program. Follow along while looking at the code on your computer screen (or while looking at a printout of your code).

Often the first reaction is to blame the robot for the code not working correctly, as in thinking that the actual robot hardware is defective or malfunctioning. This is very rarely the situation. Remember, the robot is a computer, and computers are only as smart as the programs they run. They do exactly what they are told to do. So if something is not working as you expected, it’s because you told the robot to do what it is doing and not necessarily what you wished for it to do. You might not have intended to tell the robot to do the wrong thing, but if you check your code carefully you will find that the robot is doing only what it was told.

Have other teammates look at your code as well. Often when we write code we have a hard time seeing the flaws in our own work. A second set of eyes might see a flaw in either the code or the logic itself that you missed.

In Chapter 4, we’ll spend time talking about lots of helpful tools and tricks for debugging your code when simple observation isn’t enough.

Summary

Working in a group to develop software can be challenging at first, but if you go into the process with an open mind, you will find that not only do you end up with better program ideas, you learn new ideas by seeing how others handle the same problems in different ways than you do. This kind of input can make you a well-rounded developer.

Remember, the key to good code is to keep it simple. This not only helps you and your teammates to understand how the code works, but it also leaves less room for error. What you want with code at a robot competition is code that works the same every time. Predictable and consistent results are a big part of a winning robot program.