## Jun 8, 2007

### Email question from a student

I received an email earlier today from a 7th grade student in Utah. Here's the (edited) question:

"How can I program my robot to make more than 1 yes-or-no decision. I have a robot that looks at 3 different sensors but I'm only using sensor logic values and not numbers. The switch block only lets me do one True or False condition."

Great question! And I certainly understand why you're confused. Rather than email the answer, I figured I'd share this with others because if one person is asking, I'm sure there are others. So, here's one option (option #2 will be provided in a separate blog post):
I don't know the details of your robot, but let's just assume that your robot's 3 sensors are Touch, Sound, and Light. You've configured the trigger values for each sensor (For example, does the Light sensor detect a light value less than 20 - true or false?) and are using the logic data plugs to take the True or False response from each sensor.
You didn't state whether all 3 sensor logic values must all be True or all be False, so this example will show you how to make decision based on a mixture of logic values, okay? Let's look at the possible options that can be returned. I'm going to write down all the possible options that could come from 3 sensors in the following format: Light - Sound - Touch with a 1 indicating True and a 0 indicating False. For example, if the Light sensor is True, the Sound sensor is False, and the Touch sensor is True, then I would write 1 - 0 - 1. Got it?
Okay, next we need to look at all the possible options?

Light - Sound - Touch

0 - 0 - 0

0 - 0 - 1

0 - 1 - 0

0 - 1 - 1

1 - 0 - 0

1 - 0 - 1

1 - 1 - 0

1 - 1 - 1

Verify that I've got them all, but I think you'll find that that's it... I've provided everything from all False to all True and everything in between. Now, count them up. There are a total of 8 possible combinations.
Using this, I need to figure out how to program a decision-making procedure that can account for 8 possible combinations. And to do that, I'm going to use the Switch block that you talked about in your question. You are correct that the Switch block only provides 2 possible options when using a Logic value - True or False. What I think will surprise you is that you can place a Switch block inside a Switch block inside a Switch block. Yes, that's 3 levels deep. By doing this, you can check the status of each sensor, one-at-a-time - based on True or False response, another Switch block will be used to check the status of the next sensor (True or False). A final level of Switch block will be added to test the last sensor.
Take a look at the image I've provided here and you'll see how this is done. Starting from the left, you'll see the first Switch block (SB-1) with True or False path. Follow it and you'll see 2 new SBs (SB-2 and SB-3), one in the True path of SB-1 and one in the False path of SB-1. Follow these and you'll see 4 new SBs, 2 in the True path of SB-2 and 2 in the False path for SB-3. And because each of these SBs have a True/False path, you will find that you have a total of 8 possible paths that can be traced.
If this is confusing you, just trace each possible path with your finger and keep count. Use the circles in the right image to represent each switch - blue lines are True and red lines are False. If you're still confused, the best solution would be to duplicate my image in NXT-G and experiment - it'll make sense if you think about it for a while. Thanks for the question - and option 2 will be posted shortly. In that option, I'm going to show you a way to use logic values to determine if all sensors are True or all sensors are False.
Jim

Light sensor

Sound sensor

Touch sensor

Sometimes a problem just screams for a sequential solution. How about the following:

variable = 0

IF SENSOR_1 = TRUE
variable = variable + 1

IF SENSOR_2 = TRUE
variable = variable + 2

IF SENSOR_3 = TRUE
variable = variable + 4

Now you can do a numeric switch statement with the value of variable which can have values from 0 - 7.

Alex said...

I personally prefer decisions with state variables. Uses only linear chain of switches. In this particual case, notice that you have 8 possible states of sensor activations, and the list that Jim provides are these states' binary representation (000 = 0; 001 = 1; 010 =2, etc). Define a state variable state = 0. Then check all sensors consequitvely:

if touch is true; state = state + 1;
if light is true; state = state + 2;
if sound is true; state = state + 4;

(all this in G-NXT of course)

That is, add 1, 2 or 4 to state depending on the state of the sensor. This will build the appropriate state, from 0 (no sensor) to 7 (all sensors). Then you can use a numeric switch with checks between 0 and 7 to execute conditional code. No nested switches, easy code.

Cheers,
Alex

Alex said...

What can I say Dean - great minds think alike (and obviously at the same time :-)

Jim Kelly said...

Very cool, Dean and Alex. You've probably helped quite a few kids and adults with your nice simple solutions...

Both of you drop me an email when you can...

Jim

Brian Davis said...

Note there's at least one other aspect of Jim's code that could use a subtle warning. As shown (nested "flat view" Switch structures), you can't wire into and out of them. This would still work in one of two ways. One way would be to put Sensor blocks within all the various Switch structures (Jim's method would then use seven Switch structures and seven Sensor reading blocks, all which would need to be configured). A second would have just three Sensor blocks ahead of the nested Switch structures, but have those structures set to "tabbed view" and wire the sensor results to where they are needed. This would save you four Sensor blocks, but still use seven Switch blocks.

Alex and Dean's method is a little more memory-friendly: They would use only four Switch structures (although one would have multiple cases), and three Sensor blocks, for a significant memory savings, while still being able to address all of the possible states. also, they would need a number of Math blocks.

Jim's later solution cuts the number of blocks much further, and as long as the user only needs to know a single specific combination of sensor (all true in Jim's example, but using the right Logic blocks it could be other combinations as well).

Like Dean & Alex, in this case I *might* prefer a state-based solution *IF* I needed to select various courses of action based on a lot of different settings. But even then, you can trim the size a little bit more...

--
Brian Davis

Ok Mr. Brian (Smarty Pants) Davis, how would you make it a bit smaller? I've been scratching my head for a few days now and I'm starting to get (another) bald spot.

Brian Davis said...

MyBlocks. Essentially, your first approach uses the same code three times:

IF {some input is true}
add {some value} to a variable.

Both of the things in curly brackets can be wired inputs to a Myblock set to do this. The advantage is that instead of three Switch structures, and three Math blocks, you only have ONE copy that you use three times. There is an overhead associated with a MyBlock, but it's likely less than having the code placed three times in the program. I'd have to test for sure, but in a bigger program (where such an "increment on true" MyBlock might be used many many more times) it would likely result in a substantiall savings.

--
Brian "thinking like a graphic" Davis