This is the last post of; What is next?

I am sharing this post with ANTONIO

As part of the previous mentioned robot H9832B explanation, we must admit, the process of cleaning inside the duck: removing all cables, the motor, the speaker and the batteries was a lot of fun. The process of destroying and stripping our doll off,  gave a different value to the project, in other words, the idea of building a robot by the deconstruction of a small doll was fun. We had a lot of action along with the creation of the project.

To clarify what our H9832B project is; we relied on a scheme that was drawn on by our Professor William Turkel on 10/febrauary/2012.

figure 1

After Antonio and I talked about creating a robot that could be controlled by an Arduino platform, we went to talk to Professor William Turkel that ended up drawing the scheme of how it could be our design.

It was about being able to control the movements of the robot; in this case it is our doll, called H9832B duck, (Figure 1, to the right side of the image) by using a laptop which receives commands through internet, that is, through the application Twitter (Figure 1, to the left side of the image).

We wanted to control the robot with several engines (at the same time), in our case the “9 GR Servo”, and to do that, we started using a “Micro Mastro #1350, Battery”. This control of the six engines was done from its connection with Micro Maestro, and an external energy and programming system called Pololu Master Control Center.

figure 2 Antonio

After much time spent on understanding how to manage and program the “servos”, we realized that we really did not need to use Micro Maestro, because we could manage our H9832B duck by only using two “servos”. What really led us to use Micro Maestro was that we thought we needed more energy to move several engines which Arduino could feed. The truth is that it was a good experience in the sense that we learned how to move six servos at the same time and with different programming systems. Now that we have more knowledge, we can apply it for other future projects that we want to do.

Here you can download “Pololu Maestro Control”

All decisions we have been taking so far have been due to the ongoing work that my colleague, Antonio and I ,have been investing throughout this course. That means, while we were working with the programming systems of the various programs we were also working on the construction of the robot.

As we said before, we decided to use only two servos that were able to move all parts of the robot. Our first servo is able to move the two sides of the wings and the second servo is responsible for movement of the head and beak at the same time. We must also say that we have replaced the original duck’s eyes with two red LED lights, to give it a machine look.

The process of placing the engines and lights has also been fun. For the engines we have been able to attach them so that they fit well into the interior of the duck body by using threads and also, so they can rotate freely inside the body. Before the final placement of the engines we did many tests to make sure that they could move the parts we wanted. Each motor has a different movement, that is to say, we have programmed the angles according to fair movements without breaking anything. This work was not easy, particularly, the movement of the head for several reasons. We had to put two LEDs inside the head’s shell, one for each eye and this meant, looking for the perfect space for them to be able to move freely so that the parts would not affect the cables.

figure 3

The problem was we did not have much space inside the head’s shell as it was too small and also had a structural system that allowed to open and close its beak. Inside the head and after many attempts, we were able to place the two LEDs with their wires to feed the lights with energy. These two wires go out of the head and at the same time allow their rotary motion.

figure 4

After securing the light´s operation and the mechanism of rotational movement, we jumped to the next step, which was to tie the head to a servo by using a thread. This thread we could not tie it directly to the servo, because if we did, the servo would not be able to move the head. We had to tie the thread to the head, and then, pass the thread through a fixed part that existed already and then attach the wire to the motor; in other words we create a pulley system. At this point, and after seeing our system working, we started laughing because we were so happy we had succeeded.

figure 5

At this moment we had fixed a side wing to the one servo by a thread. This part was easier because we had more space inside the duck and therefore, the servo movement was not difficult. Tying the other wing was the last thing we wanted to do since that meant the complete closure of the entire body. After quite a bit of hard work and many programming errors, we finally could synchronize the different movements of the head, beak and wings. All this was done by connecting the various wires coming out of the duck into the Electronic Chassis Brick, and the Arduino UNO, while the Arduino UNO was connected to our laptop. The programming system that we use to speak from the laptop to the Arduino UNO is called WIRED.

Here you can download the software:

Finally, everything was fine and worked perfectly. At this time we were happy and therefore, we were seeking to bind our other wing and close the entire body. We started to check everything. Before finalizing, we have to tell you another important element of our project.

All we are doing with the programming systems is to control the movements of our robot through a Tweet that is sent to the account we have developed since the beginning of the project, this account is @H9832B and the commands are:

– @H9832B $wings$: upon receipt of this command to our account on Twitter the duck flaps his wings three times as we have programmed.

– @H9832B $head$: upon receipt of this command to our account on Twitter the duck moves his head and opens-closes his beak twice as we have programmed.

– @H9832B $everything$: upon receipt of this command to our account on Twitter the duck first moves the head and opens/closes his beak twice and then moves his wings three times as we have ,as well, programmed.

Regarding the lights we decided they should always be on, but in a blinking light mode.

But how can we know who has sent a tweet to @H9832B?

Since we don’t want to open our Twitter account all the time, to see who sent the orders mentioned above; we decided to use an LCD screen that we have been able to program. Thus, whenever we have an order for our H9832B duck, our LCD is able to read and show the information about the user that sent the order and what type of order was it.

video 1

The LCD screen was always going to be a part of our project, even before we switched to this one, as was mentioned in the previous post.

What is interesting here is that we have achieved programming the LCD screen to read long messages by making the messages flow in motion.

Now, back to what we were saying when we started to check everything; that is, the movements of our H9832B duck along with the LCD screen. So… here comes the moment of truth… the result was disappointing. We came down and there was an uncomfortable moment of silence, basically, it did not work. Soon, I began to think that for every problem there is a solution, and the truth is, that having an IT man, such as Antonio, as my colleague made the problem less severe. This is because, he always has a solution to all problems, and therefore it was good having him as my co-worker.

The problem that arose was that the screen did not work well; it was blinking too fast, leaving strange symbols and we did not understand what was happening. We thought that by having all items plugged in at the same time, there was not enough energy for everything. Quickly, we contacted Professor William Turkel asking for another Arduino UNO, and by which, perhaps having an Arduino for H9832B duck and another one for the LCD screen. It was a very stressful time of reflection.

What can we do now? It was Friday and there are only few days left for the final delivery and we could not afford to lose time.

But then of course, Antonio saved our project again. The problem was that our LCD screen was plugged into the Electronic Brick Chassis BUS2. This BUS2 was sharing a pin with D9, D10, D11, and D12, which where, were the robot’s wires were plugged in. So we decided to change the spot of the LCD screen from the BUS2 to BUS1, where it did not involve the pin robot cables. It was a very intense moment, seconds seemed minutes, and at this very moment, there was another surprise waiting for us but in the positive sense.

Finally, our H9832B duck was moving accordingly to the commands and the LCD screen was showing the messages perfectly. So yes, there was joy again!

video 2

In this section, we will be delivering the more technical aspects of our project, which is as follows.

The H9832B Duck is a robot that obeys commands sent from Twitter. In order to make it work, we had to face some technological and mechanical challenges. The first part of this post will talk about the technological issue(s).
Let’s start introducing all the components of the project:

– Duck:

figure 6

– Liquid Crystal Display:

figure 7

– Arduino UNO:

figure 8

– Arduino Sensor Shield V4 Electronic Chassis Brick :

figure 9

– Laptop:

figure 10

This project had two main modules. The first module dealt with sending the tweet from twitter to the computer. The second one was responsible for the execution of the command in Arduino.

figure 11


The first step to our project is to send a tweet to the duck. For this reason, we created its own account on twitter: @H9832B. Like every user, @H9832B, the account follows others, and in our particular case, “following” means that our duck accepts commands.

Every user can send tweets to the duck, but it only obeys those whom it follows. Following is the pathway by which other users are allowed to command the duck. The “following ones” do not necessarily have to be followed in tweeter. As long as the users follow the DUCK, they can command it.

figure 12

The next step is to send the tweet to the computer. Actually, twitter does not send anything to the computer. It’s the computer itself who searches for new tweets. We achieved this by programming a script in Python. Here is the script:
1º Accesses @H9832B’s twitter account
2º Gets its friends (followers) including itself (@H9832B)
3º For each friend gets their last tweet
4º Filters those tweets that are commands (they have a specific syntax)
5º Chooses the first one
6º Sends that command to the serial port (where it’s expected to be Arduino)
Usually, signing in a twitter account requires the owner of the account to access the twitter website through a web browser, and by which, they must insert their username and password manually. Can Python do that by itself? Well, of course it cannot. But there is a method that makes this process automatically. Firstly, we had to go to the twitter developers website.

Then, we created an application  by giving a name for it and its description. Once we created our application, we got the information for OAuth ( OAuth is an authentication protocol that allows users to approve application that can act on their behalf without sharing their password. Specifically the information required is: Consumer Key, Consumer Secret, Access Token and Access Token Secret. That information is supplied by twitter in the application itself.

figure 13

After creating our application and getting the relevant information, we installed the python-twitter library  on the computer. This library provides a pure Python interface for the Twitter API. This way, we can perform operations by using just the python code. A complete description of this API can be found here. Some of the methods we used are:

– import twitter //imports the python-twitter library
– api = twitter.Api(consumer_key, consumer_secret, access_token_key, access_token_secret) //creates the connection
– api.GetFriends() //gets followings
– api.GetUserTimeline(user.screen_name) //gets a user’s timeline

To send a command to the duck, the user must write a tweet with the next format: “… @H9832B … $command$ …”. The tweet must be sent to “@H9832B” and the command written between “$”. Right now, the duck can perform two operations and it understands three commands: “wings” to move its wings, “head” to move its head and beak, and finally “everything” to move its wings, head and beak. The python script checks every 10 seconds for new tweets. If there is a new tweet, the command (the text between “$”) is extracted and sent to the serial port, where the Arduino is supposed to be. The information sent to Arduino has the next format: “@user -> command”

figure 14

The other important issue concerning the python script is its communication with Arduino. Talking to Arduino over a serial interface is pretty trivial in Python. There is a wrapper library called pySerial that works really well. This module encapsulates the access for the serial port. The data transmission with the serial port is made byte by byte, therefore, to send a whole text, it must be sent character by character. The methods we used are:

– import serial //imports the pySerial library
– arduino = serial.Serial(‘/dev/ttyACM0’,9600,timeout=1) //creates the connection with serial port
– arduino.write(character) //writes a character to the serial port (or, in other words, sends a character to arduino)


As a command is sent to Arduino, two things can happen: one, if the command is known, the duck obeys the instruction and the message “@user -> command” is displayed on the screen; if not, the duck does nothing and the screen displays the message “I don’t understand”. In addition, the duck blinks periodically. This behavior is possible thanks to all the electronic components involved. There are two LEDs (for its eyes) and two Servo Motors inside the duck, one for its wings and another one for its head and beak; and finally, an Arduino and a Sensor shield to control those components. A proper program running in Arduino is also required.

figure 15

Arduino is programmed in a language called Wired. This program is coded in the IDE Arduino, which you must previously install on your computer. When the program is done, it is sent and ran in Arduino. This program manages every component in our project.

figure 16

First of all, we needed to set up every component: pins, positions, etc. We would like to clarify that we did not connect the components to Arduino directly, we used the shield instead. Every time we say “connected to Arduino”, we mean “connected to the shield”. We have two LEDs connected to two pins in Arduino, two servo motors connected to other two pins and the LCD screen connected to the BUS1 on the shield. It is very important to check that pins that are being used by the BUS do not overlap with the pins used by the LEDs and the motors. Since the motors have rotating movements, it was needed to set up their positions in angles (degrees). So it was necessary to give the initial and final angles of the motion. We also defined special counters for the blinking of the duck’s eyes and some constants for the screen: number of rows, number of columns, speed of scrolling, etc. Secondly, the program starts with the setup() method. The project configuration is analyzed here:

– We set up pin modes and initial values (HIGH) for turning LEDs on, and attached the motors to their corresponding pins.
– We created the connection with the serial port (from where the computer is sending the commands)
– We initialized the LCD screen: size (2 rows and 16 columns) and the initial message “Hi, I’m H9832B Duck”.

Finally, the loop() method runs over and over again. The loop() is the heart of the program and its code controls the behavior of the duck and the screen. Specifically:

– It checks for new commands.
– It makes the duck blink if applicable.
– It scrolls the screen.


We wanted that messages on screen to appear on the bottom row, from right to left. When it starts to disappear on the left, it then begins to appear on the top row, also from right to left. And when it disappears completely on the left, it reappears on the bottom row and the process starts all over again. The LCD library includes its own scroll() method, but its scrolls each row independently, so it did not offer the behavior we needed.

Our own screen_scroll_next() function does not actually scroll the screen. It just prints different messages once and again and by doing so, creating the effect of scrolling. To exemplify: imagine a screen with 1 row, 6 columns and the message “hello”, here is the way we would print the sequence of messages:

01: _ _ _ _ _ _
02: _ _ _ _ _ h
03: _ _ _ _ h e
04: _ _ _ h e l
05: _ _ h e l l
06: _ h e l l o
07: h e l l o _
08: e l l o _ _
09: l l o _ _ _
10: l o _ _ _ _
11: o _ _ _ _ _
01: _ _ _ _ _ _
The effect is that the message “hello” appears on the right and disappears on the left. Which is simple but effective! The message “scrolls” one character for each step on the loop.

The screen always shows the same message until an event makes it switch. In the case there is no tweet, the screen shows “Hi, I’m H9832B Duck”. When a command is received, the message shows the last user and command executed with the format “@user -> command”. If the command is unknown, the message that would follow is “I don’t understand you”.

figure 17


Approximately, every 5 seconds, the duck blinks. We have a special counter that starts at 0 and increments by 400 (0.4 seconds ) every step of the loop(). When that counter reaches 4800, the duck blinks once; when it reaches 9600, the duck blinks twice; and finally when it reaches 10000, the duck blinks three times. Then, the counter restarts again. This sequence creates a non-uniform and natural blinking.

We are aware that the red color gives a psycho-killer look to our robot, but that is the way we like it!

figure 18 servo motor


In every step on the loop, the program checks for new commands so, it checks whether new information was sent from the serial port; in other words, whether there is new data available or not. Because the data transmission with the serial port is made character by character, we coded a specific function that would basically read the serial port character by character and then, put them together to create a whole message. The python script takes care of sending the messages with the format “@user -> command” but, it is the wired program that checks that the “command” is known for the duck. To make this possible, we codified another function called getInstruction(message) to extract the right side of the “->”. If the instruction obtained is known, then the duck will do the corresponding action. However, it is not, it will do nothing and the screen will show the message “I don’ understand”.

What happens if the duck understand the instruction? It can perform two actions: 1.) move the wings and move the head and beak. For this, what we really did was to write on the servo motors new values of angles. The motors have a repose angle (set up on the setup() method) and when the command is activated, this value is modified and a little piece of the motor rotates and goes to the new position. This new position is held on for the necessary time and then, the original value of the angle is restored. For some movements however, there is more than one repetition. For example, the duck moves its wings three times, that means, the program on Arduino switched the initial and final value of the angle three times.

When the motors move, their little pieces move the wings and the head. This process has been explained above, in the second part of the post.

figure 19

There were three small projects which helped us with our own. Here are the links for those mentioned projects,  in case you are interested:

– Tweet-a-Pot: Twitter Enabled Coffee Pot

– SimpleTweet_01 python

– Send a Tweet to Your Office Door: And let your coworkers know what you’re up to


8 responses to “This is the last post of; What is next?

  1. Pingback: H9832B Duck | 2011: A Digital Odyssey

  2. Pingback: Final Post: Gamex and Faces in Baroque Paintings | In my humble opinion…

  3. Pingback: Baroque Faces: Final Post | The Digital Fingerprint of the Brush

  4. Pingback: Final Reflections on Digital History and our Interactive Exhibit « Backwards with Time

  5. Pingback: Emergency Stop on Dundas Street! | Douglas McGlynn – a wee fireside chat

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s