Robot Logic: State the Purpose!

Thanks for joining me today! Several readers have asked me what my little experimental robot is supposed to do. This is actually a very important question to which there are three potential answers:

1. It runs around the house, bumping into stuff, beeping, and generally looking cool.
2. Nothing really. It’s basically a self built “roomba” except that it doesn’t vacuum.
3. “It’s complicated”

The rest of this rather long post will be dedicated to elaborating answer number 3.

The robot as it is now is too small for most practical 20140510-005applications,  however it is an open-source device which means you can change stuff. The upshot of this is that it’s fairly easy to modify it to change what it can do. This could then be applied to a larger, more powerful version which actually could do something useful (like perhaps fetch you a drink). Aside from being easier and less expensive to experiment on, it’s generally more practical to have a chihuahua sized robot running around the house bumping into things, then say an R2D2 sized robot doing the same thing.

So what do I mean, when I say it’s easy to modify? First let’s take a look at what our little robot can do now:

Physically he has three inputs
Right and left “whisker” sensors to let him know he’s bumped into something
Infrared sensor that lets you send simple signals to him with a universal remote control

He also has three outputs:
Right and left motors to make him move
A small speaker that lets him make beeping sounds

He has an Arduino Uno controller that ties it all together. It “listens” for the inputs, and based on pre-programmed logic, responds by controlling the outputs. A simplified example of this is that when one of his whiskers gets bumped, he will beep, back up, turn right or left, and continue on his merry way.

What can we modify? Just about everything!

We could:

  • Add another input: such as another sensor – maybe a feeler that lets him know he’s getting too close to a stairway. Maybe something more sophisticated, like a light sensor to let him know if the room is light or dark
  • Add another output: Such as some cool flashing lights
  • Or we could change the programming so that he does different things based on the inputs he receives.

Lets tackle the easiest option first: change his programming

When we compile his basic program, we get the message “10.618 Bytes (of a 32.256 Bytes maximum)”. This means he still has some space left for more complicated programming.

Let’s change a few things things in his program and see what happens. Before we begin, some deeply philosophical commentary. Although I am not an expert programmer, tinkerer, mechanic, machine tool operator, etc, I do like to experiment, and have gained a few valuable skills over the years. In my opinion one of my most useful skills is that I am quite good at “not making things worse”. This may seem trivial, but it has saved me a lot of frustration.

20140510-003Here are a few specific hints:

  1. Try to only do a thing that you know you can undo
  2. If possible, only change one thing at a time so that if something doesn’t work, it’s easy to tell what doesn’t work
  3. Before you start changing anything take a minute to think what could happen that would be “bad”, and see if you can guard against it. For example having a vehicle fall off a wobbly jack and squash you like a bug would be bad. In this case, I thought that if I goofed something up, and his drive motors activated, the robot could go charging forward and fall off the couch with the USB cable still attached. This is why you’ll notice I put a small box under him so no matter what happens he can’t move.

Since the creator of the program was nice enough to leave a few remarks in the code, it’s pretty easy to tell what’s what. Let’s go to the portion of the code that controls what the robot does when his “whiskers” are hit. In the original program, what he does when the right whisker is hit is the mirror of what happens when the left whisker is hit, except for a different type of beep. I will change the right value a little, and add a second beep. The changed values are highlighted in green.

if (pbLeft == HIGH) { // If left whisker hit
int tones[] = {NOTE_C4, NOTE_B3, NOTE_C4};
int toneDurations[] = {4,4,4};
makeTone(tones, toneDurations, sizeof(tones)/sizeof(int));
pbLeft = LOW;

if (pbRight == HIGH) { // If right whisker hit
int tones[] = {NOTE_D6, NOTE_C3};
int toneDurations[] = {4,4}; // smaller number = longer tone
makeTone(tones, toneDurations, sizeof(tones)/sizeof(int));
delay(750); //was 1500, changed this to make it different from left
makeTone(tones, toneDurations, sizeof(tones)/sizeof(int)); // added second beep
pbRight = LOW;

So, compile it, upload it, and see what happens. It should spin less to the left, since I cut the value from 1500 to 750, and it should make an extra couple of beeps. (Note that the numbers are time in milliseconds; e.g. 1500 milliseconds = 1.5 seconds)

Curiously enough, the beeps work, but the spinning is not noticeably different. After some head scratching, I realize I have violated rule 2. Even though everything works, it turns out that second beeping that I added had the side effect of counteracting the other thing I was trying to do:  Extending the delay before he stops spinning and starts doing something else: 750 milliseconds + the time it takes to beep =~ 1500 milliseconds which was the original value! So, to correct this, move the beeping down a line (wait until after he starts moving forward to beep).

if (pbRight == HIGH) { // If right whisker hit int tones[] = {NOTE_D6, NOTE_C3}; 
int toneDurations[] = {4,4}; // smaller number = longer tone reverse(); 
makeTone(tones, toneDurations, sizeof(tones)/sizeof(int)); delay(500);  
delay(750); //was 1500, changed this to make it different from left 
makeTone(tones, toneDurations, sizeof(tones)/sizeof(int)); // added second beep pbRight = LOW; 
Serial.println("pbRight");  }

So, now we have changed his programming a little, and it does what we expect it to. We know we can change something and we know how to change something. Next time we can look at why we might want to change something. Cheers for now!

8 thoughts on “Robot Logic: State the Purpose!”

  1. I know nothing about the tech side — that’s all Greek to me.
    I just think it’s cool and adorable. and if you can design one that will bring me coffee, I’ll be happy. 🙂
    Can’t wait to see more.


Speak your mind - here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.