Humanoid Robotics 1
Mentor: Doug Blank
A humanoid robot is a robot that is designed to have the appearance and body of a human. It typically has a head, a torso, and two arms and legs. Humanoid robots are also meant to be autonomous, meaning that they can perform tasks on their own without continuous human control. This summer I will be using a microcontroller to control my own humanoid robot. The control board is designed to control a variety of actuators, including the types of servo motors that are used throughout the robot. We will be working on optimizing the size and shape of the humanoid so that it can efficiently carry a small PC and power source while still enabling it to support its own weight. I will be controlling the positions of individual servos and also manipulating multiple servos simultaneously through the use of different applications designed for this specific control board. I plan to communicate with the control board over a serial interface, so that I can read and write to the serial device, specifically enabling the robot to respond to inputted values through initiating servo motors (i.e. move the robot's joints). Through working on this humanoid, I hope to learn about the ways a robot can see and perceive its environment and appropriately react and respond to its world. A popular application of such humanoid robots is the "Robot Soccer World Cup," also known as "RoboCup." In this competition, various categories of autonomous soccer robots compete in games against each other. My ultimate goal for the summer is to enable my robot to stand and walk on its own without constant need of human guidance, and to also enable the robot to play a simple version of soccer.
This is where I will keep track of my work each day.
Today I read the book “Getting Started with Arduino” for my first introduction to this platform. The following are brief notes from the 1st chapter:
- physical computing platform
- implements the Processing language
- you program it via USB cable, not a serial port
- experiences between humans and technology
- uses electronics to prototype new materials for designers/artist
- design of interactive objects to communicate with humans
- uses sensors, software running inside a microcontroller
I started out by connecting the arduino to the computer by USB. It seemed too complicated to install all the arduino software on Linux, so I’ve been running Windows. I ran some example sketches, and I was able to make the LED light on the board flash at 1 second intervals. I edited this sketch to change the interval of blinking. By the end of the day, I was able to connect the servo motor to the board. Through help of online example sketches, I made the motor move back and forth 180 degrees.
How to connect servo to arduino:
- Servo black wire to arduino ground (gnd)
- Servo red wire to arduino 5V
- Servo yellow wire to arduino digital pin 9
How to connect IR sensor to arduino:
- IR black wire to arduino ground (gnd)
- IR red wire to arduino 5V
- IR yellow wire to arduino Analog In 1
I attached the IR sensor and the servo motor to the arduino at the same time. My goal was to make the motor move based on readings from the IR sensor. Originally I had trouble getting the IR sensor to work while the motor was connected, because both needed to be attached to the 5V power port. To solve this, I connected a wire directly from the 5V port to the breadboard for the sensor, and then I took another wire that connected from that area of the breadboard to another for the motor. Another problem was that I did not know how to print out data from the sketches I write. I knew that “Serial.print()” should work, but I didn’t know where it was printing to. To see where it prints, you need to open the “Serial Monitor” box.
Now I have code that moves the motor if the IR detects an obstacle. The Serial Monitor also prints out the IR reading, and it prints when an obstacle is detected. I edited this code so that while there is no obstacle in the way, the LED light stays on, and once the sensor detects an obstacle, the light turns off.
I also set up the Rovio robot and installed the initial software needed. So far it hasn't been able to do much moving around because it needs to be charged, but I got to experiment with its camera. There are three different heights that the robot "head" can be at, so it any time, the robot can see all around itself.
In the morning I continued to work on the rovio robot. One thing it is supposed to be able to do is locate and travel to its "home," also known as the charging dock, all on its own. Even though its battery was fully charged by the morning, it still had trouble moving itself to the dock. I think the problem is that the light projected on the ceiling from the dock is being interrupted by the various ceiling fixtures in the room. The instruction manual said that ceiling lights or fans could disrupt the light so that the rovio cannot correctly locate its home. I think the lights on the ceiling here in the lab are causing the problem, but later I will try moving the dock so that it has a flat ceiling above it.
Later in the day I used the arduino to try and control servo motion based on keystrokes, specifically enabling the servo to move based on pressing certain keys. This led me to researching the similarities and differences between the Arduino software and the Processing programming language. Although their programming environments and the languages themselves are very similar, as the Arduino software is based on Processing, Arduino has significantly fewer libraries than that of Processing. I found several articles through the Arduino Website that explained how Arduino and Processing codes can run together to go on the microcontroller. I haven't yet figured out how to write to the arduino serial port through Processing, but I will try again using Python. I did however write a code using the Arduino software that allows for an input into the Serial Monitor, and based on the input, it lights up the LED on the microcontroller.
Today I continued to work on reading into a serial port by using Processing. I was having trouble originally because it claimed to not be able to find and connect to the correct serial port. Then I tried using Python instead. I spent a lot of time reading about the "pyserial" library and how I would read and write to a serial port. I found several useful articles, but I was still having trouble connecting to the serial port for the arduino. I read that with windows, python can have trouble connecting if the number in the serial port name is above 09 (meaning COM01 through COM09 would work). On this computer, the arduino was on COM12, so it was not connecting. I eventually tried this again on my Macbook, and it was able to connect and write to the serial port. In the next days I'll have to figure out how to do this on a computer running windows.
Later in the day, Jenny from Villanova came with her professor to visit our CS lab. Jenny from BMC, Jenny from Villanova, and I all talked about our summer research with Doug, Diana, and the Villanova professor.
Lab safety training!
Doug told me that the servo motors on this robot are made by Bioloid. They can be controlled in a similar fashion to the servos for the Arduino, but they use a different microcontroller called CM-2+. We spend a long time downloading the RoboPlus software, which is used to interact with the CM-2+. Doug opened up the RoboPlus Terminal and attached the CM-2+ to one of the servos on the robot's arm. He said at first he got the servo to move, but now we're not sure how to get it to move again. It might be that the power source is not strong enough. Our goal for this week is to get the servos moving from the CM-2+ commands and to hopefully start thinking about the settings for each servo to put the robot into different set positions. This will be the first step to making the robot walk.
Today we worked more with using the RoboPlus Terminal to get the servos on the robot to move. There are two kinds of servos used on the robot: the RX28 and the RX10. We were having some trouble getting the robot's servos to move, but we were able to move other servos connected to the CM-2+. Through the terminal, we have to set an ID number for each servo and then tell it to "Go" to a position between 0 and 1023. You can also set all servo motors connected through the CM2-2 Plus to be the same ID number so that you can move multiple servos at the same time. We figured out that you also need to specify the baud rate. We weren't doing that for the servos on the robot, but once we set the baud to 34 in the terminal, the servos on the robot could move. Also we experimented with reading and writing data to the CM-2 Plus by opening the serial port through Python. The information we read and write is in hexadecimal, and each section of the string of characters represents a different piece of information that is contained within the packet.
I did some more experimenting with RoboPlus Terminal and moving the motors on the robot. From yesterday, there were two other RX28 servos attached in a daisy chain to the RX28 on the robot's left arm, and one of the two external servos was connected to the CM-2+. I set the ID of the three servos to be 1, and I was able to control them all at the same time. Then I disconnected the two extra servos and connected the CM-2+ to another servo on the robot's leg. I was able to move this servo too, and while doing this I noticed that it was unable to manually move the connected servo myself (without too much force obviously). This makes sense because the servo should be strong enough to lock into a set position, which will be important when we get the robot standing on its own. After disconnecting the servo from the board, I tried to move the servo myself again. I was able to move it now, but for some reason, it's a bit harder to move than before. Then I checked the servo on the arm that I first connected to, and it also was harder to move. Because of this I didn't try to connect to any other servos on the robot, but this is something I need to look into later.
Today I created a diagram of the robot and each of its servos. I labeled all twenty servos and showed to connect them all to each other with wires. Doug and I spent a long time reading about the RX28 servos and how to communicate with them. We found a way to write to the servos that would use hexadecimal bytes to move them. We had a lot of trouble with this because the RX28 manual wasn't exactly clear. Doug found out that when we write to the CM-2+, we are actually writing to the RoboPlus Terminal which then writes to the CM-2+. We wrote a python program that has a Humanoid class that opens the serial port and has different methods which can move the servos and change their ID numbers. Now we need to set the ID for each servo and connect the wires together.
In the morning I connected to each servo individually and set the ID numbers using the terminal. I followed the diagram I made a few days ago to label each servo with the appropriate number. After that, I tried connecting most of the servos together with wires. While testing the motors, I may have accidentally over-stressed two of them, because we later found out that the two no longer work. Although they received power (the light would turn on along with the CM-2+), the motor would not move. Doug and I went down to the basement to meet with the guys in the shop. We talked about what we could do with the robot, and they gave us some extra motors and different types of screwdrivers. Towards the end I the day I started to take out the servo that acts as the robot's right knee, because it was one that was not working. I successfully took it out, and now I need to put in a new servo.
I finished working on the knee replacement. When I stopped working yesterday, it was because I could not get the metal circular plate off the top of the servo. In the morning Doug went to the shop to get this fixed, so I was able to completely reassemble the right knee. This took over an hour to put the new servo into the robot. I tested this new servo in the terminal, and it was moving fine. Next I had to replace the motor for the right foot. Taking it apart wasn't too hard, but figuring out how to put it back together correctly took a very long time. This took at least two hours. Then I spent a while connecting all the servos to each other with wires and tested them again to make sure each one works. While doing this, I also recorded the range of each servo so that we can figure out restrictions that we should put on them.
We started out the day by connecting more wires throughout the robot's servos. Each leg is wired up separately, and the arms are also connected through the back. I've been testing the RoboPlus Motion application which is a program to control each servo on a robot to define different poses. Later we tried connecting the USB2Dynamixel. We then downloaded the Dynamixel Manager which works with this new control board. I was able to control the two servos connected to it and to change their speeds. We were unable to write anything to the USB2Dynamixel using Python because when we try to read from the serial port, we don't get anything back. Then I tried connecting the CM-2 Plus and running it in Toss Mode. This should allow us to write directly to the Dynamixels using packets instead of communicating with the RoboPlus Terminal. We haven't yet gotten anything to work in Toss Mode because I can't successfully write anything to the serial port.
Today we met with the guys from the shop. We talked about what we plan to do with the robot and what changes we think need to be made. We decided that we need to expand the torso because we need to fit the PC and some kind of control board inside. I separated the torso from the lower body and we gave the torso to the shop. Then I set up something that suspends the lower body with wire so that the legs can stand up with out having to much force on them. After putting the robot on the wires I tried testing each servo using the terminal to make sure each one worked, and I also confirmed the ranges of each servo while typing up the results. While doing this, the robot's left leg was getting power, and I realized that one servo was not working. I took apart the leg and found that one of the pins to connect the wire with was broken. I disconnected the broken servo and replaced it with a new RX10. Now I need to finish testing the robot's other leg with this new robot to make sure the other servos work.
In the morning I set up the robot to test if this new RX10 helped to give power to the other servos in the leg. All the servos in the leg get power and work properly. I finished recording and typing up the ranges of each servo. I also went through all of them and wrote down their default or "standing" position values. By figuring this out, hopefully we can create a standing pose using these values. While doing this I found that three of the servos do not move correcting. ID 13 is off because its standing position is at 0, meaning that from this position, it can only move in one direction. Since ID 13 is an "ankle pitch" servo, it needs to be able to pitch in both directions, so this servo must be fixed. Now we want to explore the Tekkotsu program and see how we can use it with our humanoid.
I went through some of the applications we have been using to work with our humanoid, and I wrote up a list and brief description of the different programs.
- RoboPlus Terminal - Direct commands to control the dynamixels. "go _" moves them to a certain position between 0 and 1023. "id _" sets all attached servos to that id value. "cid _" changes communication to servos with that id number. Typing "help" lists all possible commands. You can only control one dynamixel at a time. The CM-2+ must be in the "manage" setting.
- RoboPlus Task - A programming environment that allows you to interact with the CM-2+. You cannot actually type anything, but you must select commands from a drop down list. Through this we were able to control the LED and read the load of dynamixels. You must say you are using a CM-5 to be in the right setting. The CM-2+ must be in the "manage" setting.
- RoboPlus Motion - This allows you to create and save a series of dynamixel positions so that you can send the steps to the robot. Also you can read the current positions from the dynamixels in a robot. There is an option to see and move 3D models of certain bioloid robots, and there is a humanoid very similar to ours. This program has not yet worked for us.
- Dynamixel Wizard - Used with the USB2Dynamixel. You can connect to multiple dynamixels and individually control their position and speed. Using this program, we experimented with "Torque." Torque controls how tightly locked a servo is.
We upgraded the firmware for the CM-2+ by using the Robotis Bioloid installation CD. This came with an application called "Behavior Control Programmer," which can be used to write programs that run on the CM-2+. First we had to do an update, but after that finished, we could connect to the CM-2+. In order to run the programs, the control board must be in "play" mode. Also we now have an application called "Motion Editor" that controls all of the dynamixels. It can create and store poses that can then be played back in series to create movements. I played around with this application and managed to create a few motions. The first thing I did was set a pose called "stand" that put the robot in a standing position. I also made a motion called "kick" which put the robot in a standing position, moved the robot's right leg back, and then swung the leg forward in a kicking motion. When we get the robot's upper body we can see how the additional weight will affect these motions and individual poses.
Today we went down to the shop to check on the progress with our robot. They expanded the upper body so that there was enough room to fit the battery and the PC inside with the PC using velcro. We gave them the CM-2+ so they could attach that as well. Later in the afternoon they brought up the completed robot for this version. It was significantly heavier than it was before, mainly because of the battery weight. Doug and I experimented with Motion Editor to see if we could make the robot stand. We got a saved standing pose, and we also saved a pose that puts the robot in a resting position. In this pose, the robot's knees are not being controlled so that they can rest on the lower parts of the leg. Although we managed to get the robot to stand, we had some difficulty stability. When we tried to put the robot manually in a standing pose and then read and save that pose through Motion Editor, some of the servos would shift slightly out of place so that the robot was no longer stable. We figured out that some of the servos are out of place, causing their ranges of motion to be wrong. I started on taking apart the robot's legs to get to these servos and rotate them so that their ranges of motion could be better for a standing position, and therefore better for the robot overall. I'll finish with these servos tomorrow.
I worked on a servo on the robot's right leg that controls the ankle pitch motion. Its original standing position was at 0, so it could not rotate the ankle back as far is it should be able to. I disconnected the servo and rotated it back a bit so that it's new default position is around 512. Now the entire lower body has servos with correct default positions for optimal ranges of motion. After that I met with Doug, and we made this list of things to work on:
|Notes for the Day|
|List of things to do:||Additional ideas:|
Later in the day, Doug and I set up to film the video. We had the robot on the floor, but it was still connected to the PC in the desk. Doug filmed the video and I put the robot into different poses using "Motion Editor." I'll put the video up on YouTubethis weekend.
Today the guys from the shop came up to see a demo of the robot. We showed them the different poses that the robot has using the "Motion Editor." We talked about more changes we will be making to the robot, like finding a smaller battery and making the robot's torso smaller. Later in the day, Doug and I decided on the type of battery we will be using. It is a RYOBI Lithium 12V rechargeable battery taken from a power drill. Since we have two of these batteries, we think we can have one battery on the robot while the other one is recharging, and then when the one battery runs out, we can just switch it with the other. We tested out how long this battery would last by connecting it to both the CM-2+ and the FitPC2, and running motions on the robot. The battery lasted over half an hour, which is a pretty good amount of time considering how light it is. I'm going down to the shop on Monday to talk about more changes. Here is the list of topics to discuss with them:
- make space for exchanging batteries
- take off plastic covering? or velcro
- make torso smaller
- wiring for batteries
- center of mass low
After this, since my final abstract is due today, I worked on editing it so I can hand it in. I updated my current abstract at the beginning of the page with the new one. This weekend I'm going to edit the video of the robot and add music to it.
Over the weekend I edited the robot video using iMovie, and I added music and slides to it. Below is a snapshot I took from the video. There's a link to watch the video on YouTube under the image.
In the morning I met with the guys in the shop and we talked about how to upgrade the robot. I talked about the new batteries we have and how we want to make the upper body smaller and lighter. They will also set up the wiring for the battery and make sure we can easily switch it out with the other one once the original battery is low on power. The rest of the day I spent most of my time working on publicity for the video. It's getting quite popular. ;)
Today I worked on editing the python code we originally wrote to talk to the control board. The original code was a Humanoid class which had different methods to control the servos. One method sets the ID number of a servo, and another method tells the servo to move to a specific position. At first we weren't sure how to use "toss mode" for the CM-2+, so our original python class talks to the dynamixels by first connecting to the RoboTerminal, then talking to the dynamixels. In the Humanoid class, we sent strings of characters to the serial port, using commands like "go ..." or "cid ..." which are commands used in the terminal. By using toss mode, we should be able to talk to the CM-2+ directly without using terminal commands.
I got the robot back from the shop this morning! The upper body looks a lot smaller, and it looks much better for the new, smaller battery we have. They removed the servos on the end of each arm, and they also moved the shoulder rotation servos to the outside of the body. This gives more room in the torso to store the PC, battery, and their wires. They also slimmed down some of the metal pieces on the legs to make the robot lighter. The robot's feet have been rotated around so they are backwards to what they were before, so I might be fixing that later. These new feet make it harder for the robot to have a resting position where it bends its knees and rests on the back of its legs. While checking to see if all the servos still work correctly, I found out that the guys switched the two arms so their ID numbers are off. I have to either switch the arms or reassign the ID numbers.
While working with the robot today, I noticed something about the battery. When I plug it into the PC, it powers the PC just fine. But after that, when I try to connect the CM-2+, the power to the PC shuts off, and the CM-2+ does not receive power either. Even when I try to power the CM-2+ alone, it still doesn't get power. I think this must have something to do with the wiring for the CM-2+, so I will go down to the shop tomorrow and ask them about this. Throughout the rest of the day, I worked on the python code for controlling the dynamixels. I looked at the source code that is posted on the Summer Research 2010 wiki page, and I followed that as an example. I added to the Humanoid class I already had, and I wrote a method that tells the dynamixels to move a certain degrees instead of moving to a specific position. I also did some experimenting with toss mode, but this didn't seem to work. After the control board was set to toss mode, I would send it the byte code, but the servos wouldn't move. Then I would read from the serial port, and nothing was there to read. I continued working on writing more methods, but I needed to figure out how to get toss mode to work correctly.
I went down to the shop this morning to talk to Rob. I told him about the problems with the battery and powering the CM-2+. He said I should come back on Monday because that's when Rich will be back. Until then I can just power the CM-2+ using the outlet on the desk. I spent some more time working on methods for my Humanoid class, but I still can't get toss mode working correctly. For now I'll write my methods based on the terminal commands from the original python code, and I will change this to byte code when I know how to later.
When I got in today, I went down to the shop with the robot to talk to Rich about the problems we've been having. I left the robot there and Rich brought up the robot about an hour later. He said that the wiring was done backwards, but now everything is fixed and the battery can power the control board. I also talked to him about the robot's feet being switched around from how they originally were, and he said that it wasn't intentional. I'm going to take apart the feet and put them back on how they were before because it should be better for the robot's balance.