Warning: this post is almost the same than Mohammed’s due to we’re working together on our final project.
H9832B Duck is our project’s name. H9832B Duck is a robot that obeys commands sent from Twitter. I explained the general idea on my last post. In order to make it work, we had to face to some technological and mechanical challenges. I’m talking about technological and programming issues and Mohammed will about mechanics.
* ANTONIO *
Let’s start by introducing all the components of the project:
- LCD screen
- Sensor shield v4
According to the architecture of my last post, this project has two main modules. The first module deals with sending the tweet from twitter to the computer. The second one is responsible for execution of the command in Arduino.
Just as a reminder, here you are the architecture again (see my last post):
Twitter and Python
The first step is to send a tweet to the duck. For this reason, we created its own account on twitter: @H9832B. Like every user, @H9832B follows others. In this case, “following” means “I accept your commands”. Every user can send tweets to the duck (of course), but it only obeys those whom it follows. Following is the way to allow to other users to command the duck. The following ones needn’t to be followers. The duck also can command itself.
The next step is to send the tweet to the computer. Actually, twitter doesn’t send anything to the computer. It’s the computer who searches for new tweets. We achieved this programming a script in Python. Basically, this script:
- Accesses @H9832B’s twitter account.
- Gets its friends (followings) including itself (@H9832B).
- For each friend, gets their last tweet.
- Filters those tweets that are commands (they have an specific syntax).
- Chooses the first one.
- Sends that command to the serial port (where it’s expected to be Arduino).
Normally, signing in a twitter account requires that a person (the owner of the account or his/her boyfriend/girlfriend) accesses to twitter website through a web browser and inserts their username and password manually. Can Python do that by itself? Of course it can’t. But there is a method that let automate this process. Firstly, we had to go to twitter developers web and sign in (with @H9832B’s account). Then, we created an application by giving a name for it and a description. Once we created our application, we got the information for OAuth. OAuth is an authentication protocol that allows users to approve application to 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.
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 performance operations by using just python code. A complete description of this API can be found here. Some of the instructions we use 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(username) //gets a user's timeline
To send a command to the duck, the user must write a tweet with the next format: “… @H9832B … $command$ …”, i.e., the tweet must be sent to “@H9832B” and the command written between “$”. Currently, the duck can performance two operations and it understands three commands: “wings” to move its wings, “head” to move its head and beak, and “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”.
The other important issue concerned to 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 transmision with the serial port is made byte by byte, so, to send a whole text, it must be sent character by character. The methods we use 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)
Arduino and the duck
As a command is sent to Arduino, two things can happen: 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”. Besides, the duck blinks periodically. This behaviour is possible thanks to all the electronic components involved. There are two LEDs (for its eyes) and two Servo motors (one for its wings and another one for its head and beak) inside the duck, and an Arduino and a Sensor shield to control those components. But a proper programme running in Arduino is also required.
Arduino is programmed in a language called Wired. This programme is coded in the IDE Arduino you must previously install on your computer. When the programme is done, it’s sent and run in Arduino. This programme manages every component in our project.
First of all, we needed to set up every component: pins, positions, etc. I’d like to clarify that we don’t connect the components to Arduino directly, we use the shield instead. Everytime I say “connected to Arduino”, I’ll mean “connected to the shield”. We have two LEDs connected to two pins in Arduino, two servo motors connected to other two pins and a LCD screen connected to the BUS1 on the shield. It’s very important to check that pins used by the BUS don’t overlap with the pins used by the LEDs and the motors. Since the motors have rotating movements, it’s needed to set up their positions in angles (degrees). So it’s necessary to give the initial and final angles of the motion. We also defined a 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 programme starts with the setup() method. The project configuration is initialized 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 serial port (from where the computer is sending the commands).
- We initialized the lcd screen: size (2 rows and 16 columns) and initial message (“Hi, I’m H9832B Duck”).
Finally, the loop() method runs once and again all the time. The loop() is the heart of the programme and its code controls the behaviour of the duck and the screen. Specifically:
- It checks for new commands.
- It makes the duck blink if applicable.
- It scrolls the screen.
We wished that messages on screen appeared on the bottom row, from right to left. When it started to disappear on the left, it’d started to appear on the top row, also from right to left. And when it disppeared completely on the left, it’d appear on the bottom row and process started again. The LCD library includes its own scroll() method, but its scrolls each row independently, so it didn’t offer the behaviour we needed.
Our own screen_scroll_next() function doesn’t scroll the screen actually. It just print different messages once and again and creating the effect of scrolling. To exemplify, imagine a screen with 1 row, 6 columns and the message “hello”. We just print the next 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 rigth and dissapears on the left. Simple but effective! The message “scrolls” one character for each step on the loop.
The screen always show the same message until an event makes it switch. In the beginning, the screen shows “Hi, I’m H9832B Duck”. When a command is received, the message shown is the last user and command executed with the format “@user -> command”. If the command was unknown, the message is “I don’t understand you”.
Once a (aproximately) 5 seconds, the duck blinks. We have a special counter that starts on 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 once; and when it reaches 10000, the duck blinks twice. Then, the counter restarts on 0 again. This sequence creates a non-uniform and natural blinking. We’re aware that the red color gives a psycho-killer look to our robot.
Every step on the loop, the programme checks for new commands. That means, checks whether new information where sent from the serial port. In other words, whether there is new data available or not. Because of the data transmision with the serial port is made character by character, we coded a specific function that basically read the serial port character by character and put them together to create a whole message. The python script takes care of sending messages with the format “@user -> command”, but its the wired programme who must check that the “command” is known for the duck. So, we codified another function called getInstruction(message) to extract the right side of the “->”. If the instruction obtained is known, the duck will do the corresponding action. If not, it’ll do nothing and the screen will show the message “I don’ understand”.
What happens if the duck understand the instruction? It can performance two actions: move wings and move head and beak. What we really do is to write on the servo motors new values of angle. The motors have a repose angle (set up on the setup() method) and when the command is activated, this value are modified and a little piece of the motor rotates and goes to the new position. This new position is held on the necessary time and then, the original value of the angle is restored. Likely, there are more than one repetition. For example, the duck moves its wings three times. That means, the programme on Arduino switched the initial and final value of the angle three times.
When motors move, their little piece move the wings and the head. This process is explained below, in the second part of the post.
There are three small projects which helped us with ours. Here you are their links 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
* MOHAMMED *
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. http://williamjturkel.net/
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.
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” http://www.pololu.com/docs/0J40/all
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.
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.
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.
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: http://arduino.cc/hu/Main/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.
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!