By: Alexander Clavel (Project Manager)

Project BiPed Team:

Alexander Clavel (Project Manager)

Jacob Cheney (Systems)

Abraham Falcon (Electronics & Control)

Mikaela Hess (Manufacturing)

Executive Summary

Program Objective

The BiPed team was assigned the task of designing a 7th generation bipedal toy robot utilizing a 3Dot board. The robot was to use D.C. motors as the main driver for walking motion instead of the more frequently used servo based motion. Project Biped was to be able to demonstrate static walking and should be able to demonstrate the ability to dynamic walk and turn. Our project overall was to cost lest than $200.00 as well as be completed and ready to participate in the end of semester game on May 15th, 2017.

Mission Profile

The Biped shall be able to participate in the end of semester “Pacman” game where the goal is to navigate a maze while being remotely controlled. The velociraptor acts as the ghosts and attempts to catch up to the biped. If the biped is caught, then the velociraptor wins. There are also red colored dots placed around the maze that will count as points once a robot walks over it. The robot will then count the dot and continue on with the game. The time limit of the game lasts up to a maximum of 30 minutes. Viewing of the game will be provided by the spiderbot which will be hanging above the maze and relaying live video feed through the arxterra control panel. The game rules can be referred to here.

Project Features

Ankle Turning Servos

One of the main focus and key features of our robot is that we will use servos in the ankle to turn the robot. Traditionally when turning, you would change the speed at which the individual legs move reference to each other. You could  have one leg moving while he other remains stationary or you can even have them rotate opposite of each other. For our design, none of the would work considering that we were using just one D.C. motor to power everything. Since we had one motor that rotate both legs simultaneously, we thought to get one leg off the ground and then to turn it from there. This proved to be an acceptable solution and perfect feature for our robot.

Tilt Box For Counterweight

The other challenge for us was to be able to shift the center of mass of the robot to each leg as it would walk. Whenever a leg would lift up, the robot would immediately tilt over and fall. To attach this issue, we copied the idea from a Theo-Jansen video that was seen on the internet. The idea was to have a ball, or some sort of smooth weighted object move back and forth from side to side. The weighted object in question would obviously need to have weighed a majority of the entire systems weight to be able shift the center of mass, so mass allocations was a concern but we fell within requirements. In our design we incorporated a wooden box that would look like arms, and had a cam attached right beneath it to tilt the box back and forth effectively moving the ball back and forth.

This blog post goes more in depth with how the tilt box is essential to the robot.

http://arxterra.com/spring-2017-biped-working-prototypewalking-balancing-experiment/

Bluetooth Controlled Movement

The robot will be able to be controlled using the arxterra phone application or through a computer using the arxterra control panel. Due to the mission profile stating that we will be viewing game through a video, we needed to make the robot able to be controlled remotely. For our design we included a bluetooth module on the Arduino and from there was able to remotely control the BiPed. (3Dots were the planned component but through certain situations we were not able to use them and resorted to using an Arduino)

Simplistic/Straight Leg Design

For our robot we decided to go with  a straight legged design instead of the more popular approach of using linkages. A few reasons for this is that we wanted to keep the robot as light as possible and as simple as possible. Adding linkages means more parts and more connections that need to be held together and ultimately adds more weight. More connections means more fasteners (or something of the sort) and the linkages would add material stress into consideration in more places than we intended. Keeping a straight leg would limit our focus on stress to only a few areas. We also essentially wanted to start over from scratch  considering the last generation did not work with a D.C. motor source driven motion. If we were able to get it to walk, turn and succeed in all its functions, then the next class would be able to improve on  it even more. It would be a lot more difficult for a class to try and find out what was wrong with the last one and improve it, than get a perfectly functioning one and improve it.

System Design

System Block Diagram

The system Block Diagram shows the inputs and outputs of our robotic system. From the input side we have the HM-10 Bluetooth module that receives data from the Arxterra application and an Adafruit color sensor that detects when the Biped is standing on a red surface. For outputs we have two servos and a DC motor that enable the robot to walk and turn. Lastly we have 3 LEDs to provide a visual effect. Two will be the “eyes” of the robot and one will be toggled on and off based on the color sensor inputs.

Subsystem Design

Experimental Results

We were able to test out and experiment on all the key components of our robot. The main concerns are all listed in this section of the blog post.

Servo Torque Test

D.C. Motor Stress Test

Color Sensor Experiment

Servo Turning Test

Interface Definition

Custom PCB

The BiPed utilizes a total of 8 pins from the Arduino microcontroller. The left and right ankle servos are controlled by PWM pins 9 and 10 while the DC motor and color sensor are controlled by the I2C lines. Data will be transmitted through the Tx and Rx lines that are directly connected to the HM-10 Bluetooth module. All of the connected devices run off of the supplied 5V.

Mission Command and Control

Updated Software Block Diagram

The BiPed software contains six different subroutines. Five subroutines control the robots movements and one controls the color sensor and LED. The software begins by first decoding incoming data packets, then each subroutine is called based on the decoded command in the commandHandler

Electronics Design

Some of the main components to the robot would be the Pololu 200:1 D.C. motor. We chose this one specifically because it had high torque and would be able to move the robot even with all the weight we were placing on it. Further more, we only used one and that helped a lot with our mass allocations. There are other components such as HXT900 micro servos and a RGB color sensor. Additional information on the components can be found here.

Firmware

All of the code and firmware that was used to control the walking, turning, and color sensor can be found here.

PCB Schematic/Layout

We designed our PCB to be able to function modularly from the rest of the system. In short, the robot itself can still be able to perform its main function of walking and turning without it. The main purpose for the PCB was to be able to participate in the game. For that end, we needed the robot to be able to detect dots and to light up LEDs in accordance to those dots. Initially in our first design we had the PCB with many more functions. It had two more servos connected to it to serve as a way to shift the center of mass. Now that we are using a tilting box with moving ball bearings, that is no longer needed. It also adds to the simplicity of the design and allows us to keep everything as small and light weight as possible. Now that we have two less servos to deal with, it leaves more room for us on our mass allocations. The blog post above can provide more detail into the PCB.

Hardware Design

The above blog post is a show of one of the initial designs that we had previously had in mind. It again utilizes the straight leg, minimal linkage design. After progressing past this one we were able to look back on it and in retrospect really see where most of the flaws were coming from. Some of the key issues are as follows:

1. Off-centered weight (D.C. motor sticking out of the body to the right)
2. Unreliable pulley system
3. Unacceptable leg design (overlapping)
4. No center of gravity shift or consideration.
5. Incorrect use of gear ratios (not specified in the blog post)

From these five lessons as well as others, we were able to come up with a better design and improve off the last one. The main difference with the newer design as opposed to the one before is that the dc motor is not centered in the middle. This makes it easier for balancing and the shifting of the center of mass. Now that most of the components are in the middle, the weighted ball can move from side to side at equal lengths. We also moved away from the pulley system completely. The blog post below as well as the images may provide better insight into the actual physical design.

Verification & Validation Test

We had written up our verification and validation in accordance to the new format which we had linked in the link below. The verification matrix is also included within the test plan and it documents all of the requirements that we were aiming to hit and those of which that we had not.

Verification & Validation Test Plan

Project Status

Power Allocation

The Table above shows the maximum current the robot can draw at one particular time. This would mean both servos and the DC motor are at full power. The max current draw is 600 mA with a 60 mA margin. Our battery can only supply around 650 mA at a given time so this means our contingency is actually negative. While this may seem bad, its an impossible scenario because our robot will never be running all 3 actuators at one time.

This table shows the max current of each actuator with the total capacity of our battery. The goal here is to ensure the battery has enough energy to power the Biped for at least 30 minutes. Since the robot will only be using one actuator at a time, the worst case scenario would be the Arduino (200 mA) and the DC motor (100 mA) running at full power. At 300 mA our battery is rated with a total capacity of 400 mAh. This means our robot will be able to supply power much longer than our desired minimum.

Mass Allocation

Cost Report

Updated Schedule

Top Level

Subsystem

Much of the top level schedule had remained the same mostly because most of the top level tasks had been completed. In the subsystem schedule you can see that some of the tasks mainly in electronics and control and in manufacturing had been pushed back some. This was mostly due to manufacturing’s inability to be able to produce and assemble a working prototype.

Burndown and Percent Complete

The project ended up being rushed at the end but we were able to finish on time. There were many bumps along the road like components not working, or accidental drops that hindered the progress of the project as a whole but in the end we were able to finish everything on time.

Summary / Concluding Thoughts

Results

In the end the project was completed on time. We were able to create a statically walking BiPed that was bluetooth remotely controlled and was able to turn up to 180 degrees. We stayed within budget costs and weight limits that were set. The only issue was that nearing the demonstration date, the BiPed was dropped and the timing for the tilt box was thrown off and ultimately threw off the entire walking motion. We continuously tried to solve the problem before demonstrating it, but we ended up running out of time. Although it did not walk on the actual day of the demonstration, we are happy that we were able to get a fully functional system running and working exactly as we had intended it to. We can strongly say that this is a strong base for the next class to try and improve on it especially because it is a system that works.

We also ended up running out of time because we had planned to laser cut the entire body our of plastic and to make it look sleek and nice. Due to being rushed and having limited time for testing, this was not able to happen. We had, at the end, printed out the head unit, body, and legs, but had not completed the tilting box, cams for the box, and the servo brackets to hold the feet. Ultimately it ended up looking like an evil Santa Claus due to the request of the customer wanting it to be more “toy-like” and fun looking.

The two different videos below show the BiPed in 2 different stages of its development. The first video shows the BiPEd with minimal weight on it and purely tests the functionality of it’s ability to turn and walk forward. The second video is in the final stages of its production and has (for all intents and purposes) the amount of weight that it would normally carry. In this test we decided to test out one of the requirements that it be bluetooth controlled from a distance of 5 feet. Jacob in the background is controlling the BiPed as it walks forward from a measure distance of 5 feet. All of this shows the success of the project in itself.

Video 1

Video 2

Lessons Learned/Future Suggestions

******THIS IS A MECHANICALLY CHALLENGING PROJECT*******

When you look at this project as a whole, we are studying to become electrical engineers and in all honesty do not focus too much on the physical aspects of a system. Granted, we have our basic physics courses and knowledge, but we are not experts on the mechanics of robots. That being said, manufacturing division must be a huge focus of the project managers from the beginning of the semester. From the very beginning you need to focus on getting a system that is structurally sound and something that works. If you cannot do that then, it does not matter how amazing of an electrical engineer you or any of your teammates are. If you cannot produce a testable system that is structurally sound, you will not be able to progress at all. The issue that I ran into with my project group was that at the time that my systems and electronics engineers were ready to test, my manufacturing had not yet produced a testable model. This was where the brunt of our time was spent. More time should have gone into studying and researching how to actually design the physical aspects of the robot. The assumption was that it was going to be quick and easy was one of our biggest downfalls.

The other very destructive aspect of our project process was that we spent much too long in the “creative” aspect of our design. There were many times where we keep throwing out ideas that we thought would be “cool” or innovative where instead we should have stuck to one idea, one solution and worked on it from there. There were three specific times where we worked an initial design and then from there, we thought of “a better way to do it”. We then scrapped the first option and completely started anew with the next one. This happened 3 times and it pushed us far back past our schedule than I had originally intended. This leads into the role as the project manager. Sometimes you just have to push your engineers. You cannot be worried about them liking you and you cannot have things be personal between you and your team. The project is a team effort and everyone has to do their part. If someone is slacking you have to be able to tell them in a firm manner that they are not performing the way that they should be. I made the mistake of trying to be too nice. I feel that in doing that, it gave certain individuals the idea that they were able to push due dates back on me. The difficult part that you will have to figure out on your own is being able to discern that sensitive line between destroying their motivation to do any work, and the firm hand that will keep them doing their job.

Lastly, when it really comes down to it and there is no other option, the project manager must step in to get the job done. There may be a time where a certain division is not doing their job and no matter what you do, they just do not improve or produce acceptable work. It is at that time that you must step in and just complete the work yourself. Whether you do that by getting help from the other division members/manager, or you step in to do the work yourself. As the project manager, results and ultimately mission success falls completely on you. Yes you may find a fault in one of your divisions, and yes it may be clear where things went wrong, but you are the one who’s job it is it make sure those don’t happen. I found myself in the situation where I waited to long to do just that. I could not wait any longer and I had to step in to build the physical aspect of the robot myself. It was done with just enough time, but it was a stressful and extremely arduous process. If I was able to identify the problem sooner and stepped in sooner, we may have been able to get in a few more tests than we had actually completed. We may have been able to make the robot more durable and last longer. The point is that you are ultimate quality control and the performance and quality of the project rests on you.

In summary:

1. Focus on the physical robot mechanics and structural aspects
2. Do the research, and not just when you think it is enough (Continually question your design for flaws)
3. Do not jump around on options. Once you have picked a design, stick with it until you have exhausted all solutions
4. Push project members to do their job
5. Quality control the work that is being done by your members
6. BE PREPARED TO STEP IN AND DO ANY JOB THAT IS REQUIRED

Resources

1. Project Video
2. CDR
3. PDR
4. Project Libre (excel Burndown)
5. Verification & Validation
6. SolidWorks
7. Fritzing Files
8. EagleCAD Files
9. Code

By: Abraham Falcon (Electronics and Control)

Approved by: Alexander Clavel (Project Manager)

Introduction

The electronics and control engineer job is to find the right equipment and test it for its project functionality. To make sure the biped can participate in the game it must have a color sensor to detect the red dots placed on the floor. This experiment was done to see if the adafruit color sensor can sense red and to discover what the best range of detection is. As per the requirements of our project, this test was able to verify that we were indeed able to detect dots as well able to detect the dots at the specified distance of 2mm.

Equipment

Table 1

Arduino Code

The code below is from adafruit which can be located in the reference section of this post. The purpose of the following code is to be able to give feedback on the raw data of the colors. We were able to test this by placing different colors under the sensor and observing the given data.

#include <Wire.h>

#include “Adafruit_TCS34725.h”

Adafruit_TCS34725 tcs = Adafruit_TCS34725(TCS34725_INTEGRATIONTIME_700MS, TCS34725_GAIN_1X);

void setup()

{

  Serial.begin(9600);

}

void loop()

{

  uint16_t r, g, b, c, colorTemp, lux;

  delay(25);

  tcs.getRawData(&r, &g, &b, &c);

  colorTemp = tcs.calculateColorTemperature(r, g, b);

  lux = tcs.calculateLux(r, g, b);

  Serial.print(“Lux: “); Serial.print(lux, DEC); Serial.print(” – “);

  Serial.print(“R: “); Serial.print(r, DEC); Serial.print(” “);

  Serial.print(“G: “); Serial.print(g, DEC); Serial.print(” “);

  Serial.print(“B: “); Serial.print(b, DEC); Serial.print(” “);

  Serial.print(“C: “); Serial.print(c, DEC); Serial.print(” “);

  Serial.println(” “);

}

This code using the raw data from previous code from Adafruit will now check for red color since it is part of the requirements for the BiPed.

#include <Wire.h>

#include “Adafruit_TCS34725.h”

Adafruit_TCS34725 tcs = Adafruit_TCS34725(TCS34725_INTEGRATIONTIME_700MS, TCS34725_GAIN_1X);

void setup()

{

  Serial.begin(9600);

}

void loop()

{

  uint16_t r, g, b, c, colorTemp, lux;

  delay(25);

  tcs.getRawData(&r, &g, &b, &c);

  colorTemp = tcs.calculateColorTemperature(r, g, b);

  lux = tcs.calculateLux(r, g, b);

  float ColorAverage, RED, GREEN, BLUE;

  ColorAverage = (r + g + b) / 3;

  RED = r / ColorAverage;

  GREEN = g / ColorAverage;

  BLUE = b / ColorAverage;

  if (RED > 1.4 && GREEN < 0.9 && BLUE < 0.9)

  {

    Serial.println(“RED Detected”);

  }

}

Experiment

To perform the experiment, the color sensor was placed on the breadboard for easy connection. The color sensor itself  has four connections and the Arduino was powered by the computer through USB connection. The four connections that are being used are SDA, SCL, Vin and GND. Vin and GND are connected respectively to the Arduino for 3.3 volts and ground. Below is how the color sensor is connected to the Arduino to the computer.

Figure 1

Figure 2 shows the mini breadboard we were using to test the actual sensing of the color red. There were various other objects of different sizes and colors that were used to see whether or not the sensor is was picking only red or if there were any errors of any kind. We did not want the sensor to pick up a bright orange when what we really wanted was red. We were able to verify that it only detected red and on any other color would not light up the LED counter.

Figure 2

To conduct this test, the red mini breadboard was placed on top of the sensor to detect red and to see how this color sensor performs. Figure 3 shows the set up and how the test was actually performed. This was the first step to show that the components were performing the way we wanted it. Once we had verified that it was picking up red and only counting the red objects we then moved on to trying to find the optimal distance.

Figure 3

Figure 4

Figure 4 shows the test that was done to find out the operational range of the color sensor. The setup was very basic in the way that the color sensor was connected to the Arduino and placed side ways. A tape measure was placed along side it to indicate distance. The red mini bread board was then placed at varying distances. We initially put the sensor an inch away from the red object, but nothing was detected. From there we continuously moved the red object an eighth of an inch closer and closer until the red color was detected. The resulting distance happened to be about half an inch. This distance is well over our required detection distance of 2mm.

Analysis/Data

Table of Results

Table 2

Raw Color Data

Figure 5

Figure 5 shows the raw data for the colors, which are red, green, and blue. This sensor detects and uses this raw data as a reference code to be implemented to detect red for biped function. The raw data shown is sensing red green and blue, but the point was to take account of the red values. To do this we took the red, green, and blue raw values to a sum which will be called the average. So we then used the total raw values and then divided the specific color raw values to get the ratio of those colors from the sensor raw data. Using this ratio, we can make conditions where it reads only red when these conditions are true. In the section of Arduino codes, the code for reading red is provided. This code will help detect red and to be use for biped main code.

Arduino Serial Monitor Test of Detection

Figure 6

Using the previous codes to detect red the red mini breadboard was detected and shown on the Arduino serial monitor. This code is successful for detecting red and will be used for biped main code.

Conclusion

Performing this color sensor experiment we can see that this sensor will operate successfully for the biped to participate in the game. This sensor will help the biped be able to read red dots placed on the floor. It also shows that the color sensor will perform well and beyond the range of what is actually required. In conclusion the tests were successful and showed that the mission is achievable.

References

1. http://www.makerblog.at/2015/01/farben-erkennen-mit-dem-rgb-sensor-tcs34725-und-dem-arduino/
2. https://learn.adafruit.com/adafruit-color-sensors?view=all – programming