Home > Robots > Make:it Robotics Starter Kit – Binary Part 2

Make:it Robotics Starter Kit – Binary Part 2

In the last post we started analyzing the bitwise operations in the lineFollow.ino sketch. We looked how the sensor readings are interpreted to make the robot go forward.

In this tutorial we are going to continue our analysis in looking how the lineFollow.ino program interprets when the black in under the left sensor.

By again referring to the output from our readOptical.py Python program when the third and fourth sensor readings are 0x00 and 0x100. (refer to the readOptical.py program if you need a reminder.

We will again start at the top of the for loop again:

optValues = [0xff, 0x100, 0x00, 0x100, 0xff, 0x100]

for elem in optValues:

sensor _in = 0x0
action1 = 0x3
action2 = 0x3
sensorValue1 = 0xff
sensorValue2 = 0x0

0x0 & 0xf00
0x0 = 0b0000000000000000
0xf00 = 0b0000111100000000
if 0x0 & 0xf00 == 0
inside if sensor_in & 0xf00 == 0
0x0 & 0xff
sensorValue1 = 0b0000000000000000
& 0b0000000011111111
sensorValue1 = 0x0

The sensor_in value is 0x00 and we again perform an AND & operation with the value of 0xf0. As we said before we are checking if sensor_in data is an 8 bit or 16 bit value. Of course 0x00 is an 8 bit value as shown above, (all zeros). So the & AND operation returns a 0x00. So sensorValue1 is equal to 0x00.

Since sensorValue1 is equal to 0x00
we execute the if statement

if (sensorValue1 == 0x00)

inside sensorValue1 == 0x00
0x3 & 0xfe
action1 = 0b0000000000000011
& 0b0000000011111110
action1 = 0x2

Now here is an interesting bit, notice that from the past loop action1 was 0x3, so we now AND & action1 with 0xfe, notice the bit mask, 0xfe has all eight bit set to 1 with the exception of the bit 0 position. So when we AND & the two values we get action1 = 0x2. As we said, the sensor values have special meanings, In this case we are setting up our action for a right turn.

Since sensorValue1 is not equal to 0xff we skip the next if statement.

sensorValue2 is equal to 0x00 so lets jump inside of the if statement.

if (sensorValue2 == 0x00)

inside of sensorValue2 == 0x00
0x2 | 0x02
action1 = 0b0000000000000010
| 0b0000000000000010
action1 = 0x2

Since action1 is now equal to 0x2, when we OR & with 0x02 we of course get a value of 0x02.

The last if statement of course returns false so we skip it.

We now can move on the the second set of if statements:

if(action1 != action2)
if (action1 == 3 )
if (action1 == 1)
if (action1 == 2)
if (action1 == 0)

Since action1 is equal to 0x02 the “turn Right” command is given.

Let’s jump back up the the top of the if statement and look as the next sensor_in value if 0x100.

sensor _in = 0x100
action1 = 0x2
action2 = 0x2
sensorValue1 = 0x0
sensorValue2 = 0x0

0x100 & 0xf00
0x100 = 0b0000000100000000
0xf00 = 0b0000111100000000
if 0x100 & 0xf00 == 0
inside elif

0x100 & 0xff
sensorValue2 = 0b0000000100000000
& 0b0000000011111111
SensorValue2 = 0x0

Take note of the values of action1, action2, sensorValue1 and sensorValue2. As before they will influence the values when we run through the if statements again.

sensor_in is now equal to a value of 0x100, as we noted before this is a 16 bit number, so when we evaluate the first if statement the else if statement will be true.

After processing the AND & operation, sensorValue2 now contains the value of 0x00.

Again as we process the reminder of the if statements, we set the values of sensorValue1 and sensorValue2. As a result sensorValue1 and sensorValue2 have the values of 0x00 so action1 final result is 0x02.

Now as in the last time we processed the second sensor value, action1 and action2 both contain the same values, so the motor control if statement is skipped and no motor commands are given.

At this point the robot is moving back towards the black line. So are last set of values in the readOptical.py program simulate this situation. Both sensors read values as though sensor1 and sensor2 return white values.

You can refer to the first time we ran through the if statements when the sensor values were 0xff and 0x100 to see the results.

Again keep an eye on the previous values of sensorValue1, sensorValue2, action1 and action2 as these values determine whether the motor if statements are executed or not.

Now lets take a look at the second readOptical.py results where we have the following sensor values set in the optValues array:

optValues = [0xff, 0x100, 0xff, 0x1ff, 0xff, 0x100]

We start out again assuming the robot is straddling the black line, then as the black line curves in a circle we then assume the right sensor goes black. The readOptical.py program then processes the if statements and ends up with the third set of values again simulating the robot straddling the center line again.

Open up your readOptical.py output file that we saved earlier and let review the if logic again.

Since we have already discussed the logic of both sensor1 and sensor2 being white, simulating the robot straddling the center line, you can review this code on your own by looking at the earlier analysis.

Let us now look at the second set of values when the right sensor is black.

Again keep an eye of the previous values of sensorValue1, sensorValue2, action1 and action2.

sensor _in = 0xff
action1 = 0x3
action2 = 0x3
sensorValue1 = 0xff
sensorValue2 = 0x0

0xff & 0xf00
0xff = 0b0000000011111111
0xf00 = 0b0000111100000000
if 0xff & 0xf00 == 0
inside if sensor_in & 0xf00 == 0
0xff & 0xff
sensorValue1 = 0b0000000011111111
& 0b0000000011111111
sensorValue1 = 0xff

Third pass through the loop using a sensor_in value of 0xff.
Note we have run through our logic before with sensor_in being set to 0xff, the result of action1 is still 0x03, but because action1 and action2 values are set to the same values, the motor if statement does not execute this time. So no motor control is sent to the robot.

Now we run through the loop for the forth time where sensor_in value is 0x1ff.

sensor _in = 0x1ff
action1 = 0x3
action2 = 0x3
sensorValue1 = 0xff
sensorValue2 = 0x0

0x1ff & 0xf00
0x1ff = 0b0000000111111111
0xf00 = 0b0000111100000000
if 0x1ff & 0xf00 == 0
inside elif

0x1ff & 0xff
sensorValue2 = 0b0000000111111111
& 0b0000000011111111
SensorValue2 = 0xff

As before, sensor_in is set to a 16 bit number so we execute the else if logic.

sensorValue2 value is now set to 0xff. So now sensorValue1 and sensorValue2 are set to 0xff.

if (sensorValue1 == 0xFF)

so the above if statement is executed.

inside of sensorValue1 == 0xff
0x3 | 0x01
action1 = 0b0000000000000011
| 0b0000000000000001
action1 = 0x3

action1 is now set to 0x03.

The next if statement is then executed:

if (sensorValue2 == 0xFF)

0x3 & 0xfd
action1 = 0b0000000000000011
& 0b0000000011111101
action1 = 0x1

As a result of the AND & operation, action1 is now set to a value of 0x1.

Since action1 and action2 are different, the motor logic if statement is executed and as you can see the motor instruction of “go Left” is executed.

The third set of values are the same as before and give instructions for the robot to “Go Foward” If you want you can review the logic on your own.

So we have now evaluated all of the logic that controls the robot in the lineFollow.ino program.

How to we proceed from here?

Should we care very much why the engineer designed the motor driver/senor the way he or she did. Not really. Now that we understand what the logic is doing, in future projects that use the sensors we now know how to use this logic to read and interpret the sensor1 and sensor2 data.

If in the future we want to design our own driver board then we can look into why the engineer designed the board the way he or she did.

But now you have enough knowledge to write new programs to use the sensor data with your robot.

In future blog posts we will continue to look at working with the Make:it Robotics Starter Kit.


About these ads
Categories: Robots
  1. Richard Turner
    July 21, 2014 at 4:33 am

    Thanks for explaining this logic in detail! Could you explain why anyone would write the code this way? It seems like a very non-intuitive way to do this logic and it’s hard to read, but I guess there must be some compelling reason to do things this way…

    • July 21, 2014 at 4:46 am

      Hello Richard, Yes I agree this logic is non-intuitive. I would have done the logic on the mirco-controller, that lives on the driver board, and just had the read_Optical() method return a 0, 1, 2, or 3. But there is one possible reason for this logic. Performing bitwise operations in most cases takes up less CPU cycles than complex number comparisons. Since Radio Shack is not providing us the source code that runs on the driver board. Then we can only guess. Also sometimes bare metal programmers think in these terms, which may seem non-intuitive at times, but the more we start working at the bit level the more it makes sense.

      Thanks for the post.


  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 51 other followers

%d bloggers like this: