MicroSegbot Fall 15′ Final Document

Written By: Josh Tristan (Project Manager), Ricardo Gordillo (Manufacturing), Ruben Petersen (Mission, Systems, and Test), and Yoseph Yegezu (Electronics and Control)

Approved By: Josh Tristan

Final Document

Josh Tristan-Project Manager

Ricardo Gordillo-Manufacturing

Ruben Petersen-Mission, Systems, and Test

Yoseph Yegezu-Electronics and Control

Introduction

The MicroSegBot is designed to be a self-balancing two-wheeled robot. It is designed based on a 6:1 scaled ratio of a Segway Glider. Just like a full sized segway it is designed for a passenger and the passenger for the MicroSegbot is scaled to be 12 inches. The Micro-SegBot will be controlled via Bluetooth by any Android phone that is equipped with the Arxterra mobile application.

Mission Objectives

Objective: Create a micro robot that will be scaled to a Segway Glider for an action figure to travel across a figure 8 course.

MicroSegbot is designed to resemble a Segway Glider with a 6:1 ratio that is controlled via Bluetooth using an Android phone with the Arxterra interface. Like the Segway, it is self-balancing and can move forward, backward and rotate left and right. The budget was set at $250 and completed on 12/16/2015.

Mission Profile

Figure 8 Course

Figure 8 Course

The figure 8 course was designed to test the MicroSegbot’s capabilities in most aspects. It would test the ability for it to navigate in all directions while keeping its balance. As shown in more detail in the provided link, it states that the course include a 2.8° incline that the MicroSegbot needed to account for. This would all be done as well with a 12” doll that was calculated to be the 6:1 ratio to meet the mission objective.

Level 1 Requirements

  1. The total cost of the MicroSegbot project will not exceed [$250]. This budget was set by the customer.
  2. The MicroSegbot will resemble closely to a Segway Glider with a 6:1 scale ratio.
  3. The product will be able to complete a figure 8 course.
  4. The MicroSegbot will be able to travel up a 2.82 degree incline as defined by the course.
  5. An action figure will be used to ride the MicroSegbot through the course.
  6. The MicroSegbot will have the capability to maneuver on berber carpet and linoleum tile which can be shown in the course .
  7. In order to complete the course, the MicroSegbot will be able to travel at a minimum of .5 ft/s.
  8. The MicroSegbot will use an android phone/laptop to navigate wirelessly by the customer.
  9. The project will comply to the health and safety policies enforced by CSULB.
  10. The Project will be completed no later than December 16, 2015 which is the end of the semester for CSULB.

Level 2 Requirements

  1. In order to travel the course and be faithful with the design of the Segway, the MicroSegbot will implement dual DC motors.
  2. The printed circuit board (PCB) cannot exceed the frame of the base of the MicroSegbot.
  3. To communicate with the MicroSegbot, BLE and V2.0 were being studied; but to finish the project on time, a Bluetooth V2.0 device will be used and will be compatible with the Arxterra software.
  4. A device containing a gyroscope and accelerometer that sense orientation and acceleration will be used on the MicroSegbot. The device shall have a max baud rate of 38,400, which is the optimum rate for the Arduino Nano which has the same clock speed as the Arduino Micro.
  5. Per the design of the tires, and according to our calculations, the selected DC motors will travel the calculated speed as well as overcome the incline and friction. This can be verified by analyzing the torque that the motors can perform.
  6. Because two DC motors are being used, a dual DC motor driver must be utilized to provide the motors with enough current, voltage, and PWM compatible based on their specifications. After performing a motor driver trade off study, the DRV8835 was chosen.
  7. A microcontroller that will support each component of the MicroSegbot will need to be used to be able to accomplish the program requirements. The microcontroller will need rx/tx serial communication to be able to be compatible with the Bluetooth module. It will also need to have two PWM pins and two analog pins to be compliant with the motor driver and the accelerometer respectively.  The microcontroller that meets these specifications and fits within the dimensions is a Sparkfun Pro microcontroller and will be the module that will be used to control the MicroSegbot.
  8. The battery chosen for the MicroSegbot must be capable of providing enough current and voltage to our MicroSegbot and be within our budget. According to our power budget and battery tradeoff conducted the battery we have chosen fits all our program requirements and will be a 7.4 V, 1000mAH, 5C Lithium Ion Battery.
  9. A voltage regulator will be needed to supply the correct voltage to the motor driver that can step down 7.4V to 6V.

Verification and Validation

Preliminary Project Documentation

The Preliminary Project Documentation can be found here.

Major Project Features

Compact Design

The Micro-SegBot features has a compact design that is easily assembled as the pieces are all female and male connected. They all have a tight fit and do not need any glue or restrain to keep the pieces together. All the electronics fit within the base with the exception of the bluetooth which is located in the pouch.

The Base

The base is designed with a bracket that holds the PCB board in place and two motor mounts that hold the motors within the base. The base has fillets all around the exterior part to give it an aesthetic look that resembles a segway glider.

Remotely Controlled

The MicroSegbot can be remotely controlled via the Arxterra remote control panel in the Arxterra mobile application, which can be downloaded on any Android phone or tablet. It connects to the MicroSegbot via Bluetooth.

Completely 3D Printed Body:

The entire MicroSegbot is 3D printed out of P430 ABS Model (Ivr) plastic. This plastic is extremely durable and strong. The MicroSegbot also has the pouch laser engraved with the CSULB logo.

Design and Storage Solutions

Two major design problems that the group needed to overcome was the packaging of all the components and climbing up the incline of the course. To store the components, the team decided on using a pouch in front of the handlebars to hold the bluetooth.  The battery will also be placed on the exterior and be specifically attached to the doll will be used to ride the segway. These design innovations will solve the packaging problem and result in a smaller base which will help accomplish the requirement to resemble a Segway. The handlebar shaft will also to be hollow to allow wires to connect the bluetooth to the PCB located in the base. The specifications of our design innovations can be found here.

System Block Diagram

The system block diagram represents the way all of the components are connected together. To get here, we first have to determine the components. To determine the components, they all require different specification to be able to complete MicroSegbot’s mission objective, as well as be light enough and take less space. Because of these requirements, we decided to go with the Sparkfun Pro Micro which is similar to the Arduino nano, Spring 2015’s microcontroller, but smaller. The DC micro motors were also selected for their small size and weight, since they only weigh less than 10g each, and provide enough power to meet the objective. The driver motor was selected because it supplies each motor with enough voltage (0-11V) and continuous current (1.2A). Also, the MPU 6050 was selected because of its well known use to provide accurate gyroscope and accelerometer readings at a sufficient baud rate of 38400 to complete our requirements. The HC-06 bluetooth device was selected because of its low cost and ability to receive information via bluetooth. One of the challenges this project presented was fitting all the components in a confined space, as a result the selected items are selected to meet those restrictions. The trade off studies for each component can be found in the Prototyping, Simulations, & Trade-Off Studies section of the Final Documentation.

System Block Diagram

Prototyping, Simulations, & Trade-Off Studies

Motor Driver Trade-Off Study

The team was tasked with finding a motor driver that would be capable of operating the motors at optimum efficiency. A dual DC H-Bridge motor controller can control the speed and direction of two DC motors independently. After deciding on a breakout board, our decision was between the Pololu DRV8835 and the SparkFun TB6612FNG. The specifications are similar, but ultimately it was decided to use the DRV8835 as it is smaller, has a higher continuous output current, and has a higher max PWM frequency.

Motor Driver Trade-Off Study

Battery Trade-Off Study

The battery trade-off study details how the team decided on which battery was going to be used to power the MicroSegbot. It describes the specifications of the battery chosen as well as how we arrived to those specifications. It also describes an important discovery that allowed us to purchase a battery that was lighter and smaller in dimensions than what we had originally planned for. The battery chosen was a 7.4 V,1000mAH, 5C Li-po Battery.

Battery Trade-Off Study

Motor Trade-Off Study

The motor trade off studies go over different types of motors we looked at and which type we chose. We ended up choosing pololu’s micro geared motor with 120 rpm and 60 oz of torque. This was based on a calculation we did to determine which combination provided enough power to get the segbot up the ramp as well as looking into the dimensions of the motor compared to the other motors.

Motor Trade-Off Study

Accelerometer Trade-Off Study

The MicroSegbot needs to be able to balance itself both while standing and while on the move, so it must contain an accelerometer with a gyroscope. All of the devices looked at communicate with the microprocessor via the I2C bus, making them able to receive its sensor data without the system processor interfering. The 16 bits on each channel of the MPU6050 allow it to capture the x, y, and z channels all at the same time with better accuracy than the MMA8451 and the ADXL345. The higher scale factor shows that the MPU6050 also has a higher range of sensitivity that can be chosen for our segbot. Because of these reasons, we have decided to go with the MPU6050 as the accelerometer in our project.

Accelerometer Trade-Off Study

Bluetooth Trade-Off Study

The Bluetooth trade off studies go over the different types of bluetooth 2.0 and the selected device. The bluetooth was chosen based on the dimension, price, and weight. The HC-06 was the best priced and weighed less and also has a smaller dimension, because of this it was selected.

Bluetooth Trade-Off Study

Microcontroller Trade-Off Study

This trade off study compares different Arduino IDE compatible microcontrollers, giving us a decision between the similar ATmega32U4 and ATmega328. One of the main obstacles that we as a group need to overcome is the packaging of the segbot, which means the Arduino Nano will be too big, and gives an advantage to the Pro Micro. The weight category also goes to the Pro Micro, as it is 3.5 grams lighter that the Arduino Nano, and 11.5 grams lighter than the Arduino Micro. Because of these specifications being met, along with the slightly lower price, we decided to go with the SparkFun Pro Micro.

Microcontroller Trade-Off Study

Kalman Filter

In order to get a clear reading on the angle provide from the MPU6050 accelerometer and gyroscope, a few things need to be done. Since the individual readings from the accelerometer and gyroscope are not accurate on their own, they must be combined after going through a low pass filter and integrator respectively. A Kalman filter is added to eliminate remaining error by looking at previous values and making an educated guess of what the ange will be next. A more detailed explanation is contained here.

Motor Controller Test

In order the get control of the motors to get the MicroSegbot moving, we first had to test our DRV8835 motor controller with our motors and the Arxterra app via bluetooth. This test involved manipulating the Arxterra firmware and connecting our motor driver to the motors and Pro Micro while programming them to spin in different directions. The blog post of the test can be found here.

MPU6050 Test

The MPU6050 test was done using Jeff  Rowberg’s I2Cdev library and the teapot code on the Processing app. On Arduino, a live feed of the current angle of the device was printed on the serial monitor. The code was then taken to Processing where a visual of a plane was used to mimic the movements made with the MPU6050. More information on this test is in the blog post here.

Motor Test

The motor test was performed to get an idea of how fast the actual motors rotated compared to the specifications on the datasheet. We concluded that the RPM was around 120. Next, the torque of the motors were tested. This was a needed test to confirm that the motors would be able to travel up the ramp in the course. Three tests were performed and the blog post here goes more into detail.

Rapid Prototype

The rapid prototype was essential to the completion of the final MicroSegbot. The experimentation with the prototype led to finalizing the final dimensions of our Microsegbot as well as giving the team a solid foundation on helping the MicroSegbot with its balancing. All the information pertaining the prototype can be seen here.

Subsystem Design

Interface Design Matrix

The interface design matrix illustrates all of the connections that are made between the different components of the MicroSegbot. Using the schematic for the SparkFun Pro Micro, the team had to figure out which pins exactly could be used for all of the correct pin configurations. Column by column, the matrix shows every connection involved with the Pro Micro, MPU6050, DRV8835 motor controller, HC-06, 7.4 volt LiPo battery, micrometal gearmotors, and voltage regulator. The matrix and the interconnections between each component are explained here here

PCB Design

The PCB is designed to house most of the electronics at the base of the MicroSegbot to eliminate the need for excessive wires. This is done by putting the connection excessive pieces such as the microcontroller, motor driver, and gyro and accelerometer on the PCB. It was also designed to keep the 6:1 ratio aspect, by being much smaller than the base. More details on the design and troubleshooting can be found here.

Link for the PCB can be found here.

Hardware Design

The final design for the MicroSegbot had a lot of revisions until the final version was created. The final design was scaled to a ratio of 6:1 based on the Segway glider. The total Micro Segbot was composed of six 3D printed parts including the two motors, doll, battery, PCB, jumper wires, two fishing weights and two rubber bands. The entire design was then painted using black and grey colors. The entire design explaining the details of the design can be found here.

Hardware Files (SolidWorks files) found here.

Software Design

Most of the final code that was written was contained in the pololu_DRV8835 tab of the Arxterra firmware. This code incorporated three libraries to balance, which were wire.h, Kalman.h, and I2Cdev.h. Using the MPU6050, the current angle is calculated. Once the MicroSegbot is outside the balanced angle and no longer upright, a subroutine is used to calculate the speed the motors need to move to bring it back to balance, and then the motors are told to move that speed. In order to move the MicroSegbot, the Arxterra app is used. Moving the robot forward or backward changes the setpoint of balance in the needed direction of motion, and the motors work once again to balance the motors in the specified motion. This moves the MicroSegbot where we need it to go. A link to the blog post with a more detailed description is located here.

Resource Reports

Power Budget

The power budget accounts for all the electronic components that require energy from the battery. Once this data was accounted for the battery was chosen which is the main reason the team was able to obtain a much smaller battery than anticipated. Originally, the MicroSegbot was going to use a battery that gave an output twice as much as the battery we chose, it was also heavier and more expensive then the final battery the team chose. Creating the Power Budget helped the team in many aspects of the project as it decreased the dimensions, weight, and price.   

Mass Budget

The mass of the MicroSegbot continuously changed as the team attempted to find the center of mass that worked best for the project. The team tried adding different weights at different points of the Microsegbot until the ideal weight distribution was finally found. The team found that changing the weight distribution of the doll was one of the key reasons the MicroSegbot was able to balance with the doll riding it. The final weight of the MicroSegbot was 462.27 grams or 1.109 pounds.

Cost Analysis

The estimated total cost to recreate this project is approximately $150.00. However, this price is lower than expected because of the connections the team had with the manufactures that printed the MicroSegbot. The price paid for the 3D printing was roughly one fourth of what the total cost should have been for the MicroSegbot. The cost report states the team spent $219.38 which is higher than it should be because the team had to buy an additional Pro Micro as a result of the first one became damaged . The battery, motors, and the PCB fabrication (which we sent out to OSH Park) was the most significant costs for this project.

WBS

WBS

Schedule

The team was able to complete 85% of the tasks that was assigned to the project. The project was on schedule from the start (8/24/015) until the final testing of the MicroSegbot. Final testing started on 12/2/2015 and being able to keep the robot stable and able to hold up the doll took until the final due date. If the team was not on schedule to begin with, the project might not have completed as many requirements as expected. Below shows a figure of the project’s milestones.

sch1

Summary

In conclusion, the team was excited for the progress that was accomplished. The main goal the team wanted to pursue was to improve off of the Spring 2015 Segbot project. This goal was accomplished with its resemblance to the Segway Glider with the pristine 3D printing that the manufacturing was able to get. A special thanks goes out to the Hawthorne High School Robotics Lab who 3D printed the entire frame. Another goal was to be able to have a doll ride the MicroSegbot while self balancing. Even though the MicroSegbot was not able to complete the course or climb the incline, the team’s numerous improvements and accomplishments were a great leap forward and hopefully the next group can excel even more.

Final Video

 

Mass Budget

Written By: Ricardo Gordillo (Manufacturing) & Yoseph Yegezu (Electronics)

mass

The final mass for our project fell right in the estimated weight approximated at the beginning of the semester. While it was heavier than the team hoped for it still fell in the range where our motors would be able to move the MicroSegbot. The 3D printed frame was heavier than anticipated and to compensate for this the team had to shed weight of the doll. The doll was originally 210 grams, but after the legs were replaced with light wooden sticks, the dolls final weight was 96 grams. This was a huge shed of weight for the overall microsegbot. In addition, the final product was front heavy and in order to help the MicroSegbot balance better, two fishing weights weighing .5 ounces were added to the back compartment of the base to create a more centered mass distribution. Ultimately the eight distribution was a major key of success to completing the project and the team had to get extremely resourceful and innovative to help the MicroSegbot balance.

 

 

Software Description

Written By: Ruben Petersen (Mission, System, and Control)

Software Description

When the code first started coming together, I believed that the code to operate the motors and the code to balance the MicroSegbot were going to be two different codes. As I put together the software block diagram, I soon realized that the same portion of the code could be utilized for both aspects. This was helpful to realize, as it can be seen from the Motor Controller Test that the pololu_DRV8835 tab had already been implemented into the Arxterra firmware code, connecting the motor driver, motors, bluetooth, and the android phone using the Arxterra app. Since we also had the MicroSegbot balance code separate from the firmware, the next thing to do was to bring the two codes together.

Since the balance code used 3 libraries to perform its calculations, the first thing that needed to be done was to include those libraries. These included Arduino’s Wire.h, Kalman.h from TKJ Electronics, and Jeff Rowberg’s I2Cdev.h. After much trial and error, the PID constants were finally decided on and initialized before the setup. In the setup, each motor output is defined and communication with the I2C is set up. The I2C data is then read and the starting angle is calculated in order for the Kalman filter has an angle to work with.

At this point, the code reaches its main loop. If the bluetooth is connected to the phone, the first thing the code does is go to the command decoder. This is followed by the movement code. Using the Arxterra app, if both motors are told to move forward, then the setpoint is increased by an angle value of 1. The change in setpoint forces the device to move forward to correct this, and performs this by moving into a while loop while the motors are told to go forward until the bluetooth reads that there is no longer a signal being sent. The dof() subroutine calculates the current angle using the Kalman filter and an array of values. If the current angle is between the the setpoint and a range of 0.03 in both directions, the motors are told to stop, as this means balance has been achieved. Once the angle has left this range of values, the code then goes to another subroutine to calculate the speed the motors need to go based on the angle and the PID constants initialized in the beginning of the code. Once this speed is calculated, the motor subroutine is used to communicate with the motor driver and the motors to go that specific speed. This method is used when both motors are told to move backwards as well.

When turning left or right, the same code is used until the point where the speed is calculated. Since the MicroSegbot is already balanced, the speed to bring it back to balance does not need to be calculated. The motors are then told to spin in opposite ways at a specified speed, making it spin in place. If no command is given to the MicroSegbot telling it to move, then the code skips to the ‘else’ and continues to balance in place.

flow

References

[1] “Building a Self Balancing Bot.” Arduino Electronics and Robotics. Bajdi.com, 30 Oct. 2013. Web. 18 Dec. 2015. <http://www.bajdi.com/building-a-self-balancing-bot/>.

[2] Lauszus, Kristian. “TKJElectronics/KalmanFilter.” GitHub. GitHub, Inc., 2012. Web. 18

Dec. 2015. <https://github.com/TKJElectronics/KalmanFilter>.

[3] Rowberg, Jeff. “Jrowberg/i2cdevlib.” GitHub. GitHub, Inc., n.d. Web. 18 Dec. 2015.

<https://github.com/jrowberg/i2cdevlib>.

PCB Design

Written By: Yoseph Yegezu (Electronics and Control)

MicroSegbot Fall 15′

Figure 1

pcb1

PCB Design:

For our PCB design we decided to put the microcontroller, voltage regulator, accelerometer/gyro, and motor driver on the board. We initially had the microcontroller in a different compartment of the Segway, and when we realized too many wires will be required to connect the PCB and Controller, we decided to include the microcontroller on the PCB. This will reduce the number of wires flowing through the handle bar. Since the base of the segbot has a limited space, the PCB has a dimension of 1.8 by 1.65 inches.

Updated PCB design and Schematic:

When the initial PCB was designed there was one mistake in it. There was not a single ground connecting all the components. As a result, when we tried to implement our balancing code it was giving us a problem. After realizing the flaw, we immediately soldered a single wire to connect the two set of grounds into a single ground. This immediately fixed the issue, and we proceed to the next task.

Figure 2

pcb2

Motor Controller Test

Written By: Ruben Petersen (Mission, System, and Test)

The first goal once the DRV8835 motor controller arrived was to get it connected to the motors and subsequently communicate with it via bluetooth with the Arxterra application. This required a full understanding of the motor controller schematic and of the Arxrobot firmware that would be allowing for this communication to occur.

When working with the firmware, the thing to do was to go into the firmware folder and hide the TB6612FNG motor driver code by transferring it into the motor shield folder.  Next, a new DRV8835 tab was created along with a new Segbot definition set to true to start communicating with Arxterra app (Figure 1). If Segbot is set to true, the code then immediately sets up the pololu_DRV8835, defining each motor output and setting up communication with the I2C, as seen in Figure 2. We then moved to the command tab, where if the MicroSegbot was issued a command to move and Segbot was set to true,  the code went to the pololu_DRV8835 tab where all the communication with the motors is located (Figure 3).

 

Figure 1

data

 Figure 2

data2

Figure 3

data3

The TB6612FNG motor driver that was already being used in the firmware has three input pins for each motor, two for enable and a separate one to control the PWM.  the DRV8835 had only two input pins for the motors that also had PWM capability. This required most of the data being written to be analog instead of digital. The operation table below in Figure 4 is from the datasheet of the DRV8835, and it supplied the information on how to write the motor data. A snippet of the code is shown in Figure 5. When the command is given to move the motors, motordata[3], which corresponds with the left motor, is set to 0x01 (move). Then going off of the Figure 4, it can be seen that in order to move a motor forward, AIN1 needs to be set to the PWM, and AIN2 needs to be set low. The PWM command for the left motor comes from the Arxterra app via motordata[4], and increases or decreases based on how far the slider is altered. Serial prints are set throughout the code to show up on the serial monitor which direction each motor is rotating. When the code is working properly, the debug definition in Figure 1 is set to false to save memory. The flowchart below in Figure 6 displays the pseudocode.  

Figure 4

data5

Figure 5

data6

Figure 6

data7

References

[1] “DRV8835 Dual Motor Driver Carrier.” Pololu Robotics and Electronics. Pololu Corporation, n.d. Web. 18 Dec. 2015. <https://www.pololu.com/product/2135>.

 

Hardware Design

Written By: Ricardo Gordillo (Manufacturing)

MicroSegbot Fall 15′

One of the biggest desires the president of the Robot Company wanted to see in the MicroSegbot project was that the final design resemble as closely as possible a real life Segway. Past semesters had created their own design, but none of them had actually attempted to make the aesthetic looks of it resemble a real life Segway. The team decided on modeling the MicroSegbot after the Segway Glider, but scaled to a 6:1 ratio in order to meet the the requirement of it being a micro robot.

The final dimensions can be seen in the link to the actual Solidworks file at the bottom of this page. Here are some of the crucial dimensions that must be highlighted:

Total Height: 9.022’’(from lowest point to highest)

Total Length: 4.44’’

Width of base: 1’’

Height of Doll: 12’’

Another key thing to point out is the distance from the top of the base to the where the handle bars are. The reason being is that the MicroSegbot was designed so the doll would be able to rest his hands comfortably on the handlebars just like a real human would on a full scaled segway.

Those dimensions are:

Doll base to upper torso: 7-8’’

Top of base to handlebar: 7.2’’

The range where the doll could rest his hands comfortably would be between 7 to 8 inches and our final design had that dimension set at 7.2 inches.

Major components:

Our final design is composed of six 3D printed parts and those components can be seen in Figure 1:

(1) Base Bottom

(2) Base Lid

(3) Handle Bar Shaft

(4) Pouch Lid

(5) Wheel #1

(6) Wheel #2

Figure 1

explode

The Base Bottom:

The Base is the main foundation of the Microsegbot and contain two main design innovations. The first one is the two motor mounts that are 3D printed together as one whole piece. The motor mounts hold the two motors the MicroSegbot uses. The motor mounts also have a specific distance so the motors can be wrapped in a rubber adhesive to help with vibrations and decrease overall noise.

The second innovation is the PCB brackets that are used to hold the PCB in place. The PCB can be placed within the brackets and the brackets are designed for the gyroscope to be at the center of the base in order to help the MicroSegbot balance. This is the reason the brackets appeared to be shifted to the left, in order to allow the gyroscope to be at the exact center. This can be seen in Figure 2 below. The entire exterior edges have fillets in order to give it round edges. Also the side view in Figure 3 shows that it is designed similar to a trapezoidal body this is because the Segway glider has these similar dimensions as well. It gives it a great esthetic view and it allows the MicroSegbot to avoid looking like a box.

Figure 2

base b

Figure 3

baseb3

The important dimensions of the base bottom are:

  • Internal base floor is 2’’x 3.94’’
  • Internal base roof is 2.49’’x 3.94“
  • Internal Base height is .67“
  • Total Height of base is 1‘’

 

The Base Lid:

The base lid serves as a connector between the base and the handle bar shaft. It does so through a female to male connection. In figure 4, 5 and 6 the connection can be seen as an oval connection that is inserted into the handle bar shaft. Another key feature is the whole that can be seen in figure 4 which was designed so the battery wires could run from the doll into the base to power the MicroSegbot. The base lid also has two indents which are designed to replicate the Segway glider that our team chose to model the Microsegbot after. The indents serve as a stepping area for the doll and the final design had these indents cover with a rubber spray in order to create a similar feel to the Segway Glider. The base lid also contains the wheel covers which only serve to replicate the wheel covers the Segway Glider has. The wheel covers were 3D printed as one whole piece along with the base lid. It was designed this way in order to avoid gluing two pieces together and this design was able to be implemented because the 3D printer was cable of printing these two pieces without running into any kind of complication. This can be seen in Figure 6. The final design of the base lid can be seen in Figure 6, which also shows the separator in the middle of the base lid that separates the two leg placement indents. This was done to resemble the Segway glider and also to serve as an added weight to help shift the center of gravity towards to the back of the MicroSegbot. The final innovation for the base lid was to attach to the bottom base in a simple but durable way. The result can be seen in figure 5 as it has four pegs that fit perfectly around the motor mounts. The pegs worked perfectly in our final design and kept the entire frame perfectly secured and allowed the team to avoid using screws or glue to connect the pieces together.

Figure 4

basel

Figure 5

basesfd

 

Figure 6

baseld

 

The Handle Bar:

The purpose of the handlebar was not only for aesthetic looks but to have a pouch lid that would carry the bluetooth. The handlebar is connected via female to male connection. The base lid has a connector on top of it and the handle bar fits right on top of the connector.  The shaft has an internal space of .44 x .33 with fillet corners of .15, this gives the handlebar an internal shape of an ellipse. A see through version of the handlebar can be seen in figure 7.  Four Wires with a .05 diameter will run up the shaft and connect to the Bluetooth in the pouch. The internal space of the pouch is 1.8 x .9 x .45 (inches) which is more than enough room to house a bluetooth with the dimensions of 1.69x.63x.25 (inches). The front view seen in Figure 8 gives a great visual of where the bluetooth would be stored. The total height of the handlebar is 7.2 inches.

Figure 7

stem

Figure 8

stem2

 

The Pouch Lid:

The pouch lid serves as the cover for pouch that contains the bluetooth. The CSULB logo is laser engraved on the front of pouch as can be seen in Figure 9.It connects to the pouch via femal to male connections that allow the pouch cover to easily attach in a similar fashion to a tupperware.

Figure 9

puch

 

The Wheels:

The two wheels that were 3D printed are 3 inches in diameter and .5 (inches) in thickness. There is a spacer of .15 (inches )thickness where the shaft of the motor attaches to the wheel that serves the purpose to reduce friction should the wheel rub against the base. The final design did not have this problem as there was enough distance, this was merely a precautionary move in case this would have occurred. Figure 10 shows the side view of the wheel with the wheel cover. Figure 11 shows the wheel wheel the MicroSegbot had its wheel designed afterwards.

 

Figure 10

wheel

The doll:

The doll thee Microsegbot team chose to use to ride our project was the Ken doll. The reason being that it fit our dimensions perfectly and weighed an appropriate amount. The doll can be seen riding the Microsegbot in Figure 12 below.

Figure 11

IMG_5416

Hardware Problems & Suggestions:

Once the entire MicroSegbot was assembled our team ran into a few problems that were later on fixed by adjusting some hardware from theMicroSegbot. The first was to firmly glue the wheels to the motor shafts. The reason behind this was the wheels were too shaky and were affecting our balance, as soon as the glue was applied the balancing improved dramatically. another piece of advice for future teams that attempt to design the MicroSegbot is that they chose the doll they use wisely. The doll we ended up using turned out to be to heavy for our design so the team had to make some extreme adjustments. The team ended up replacing the legs of the doll with wooden legs to reduce the overall weight of the doll. By replacing the legs the team was able to cut the weight of the doll in half and as an added bonus was able to shift the final center of mass of the Microsegbot towards the top to make the design even more top heavy. This adjustment greatly improved the balancing of the project and allowed the PID control to become more stable. The final doll used can be seen in Figure 12, however by using the clothes of the doll, the doll still looks aesthetically pleasing.

Figure 12

doll

Final Design:

The final design can be seen in figure 14, 15, and 16 below. They show the front, side and top view respectively. The final design was a success, but there is definitely room for improvement. If the MicroSegbot could be designed from scratch again there is a few improvements I would have made. The height of the base would be increased to better accommodate the wire connections from the battery and bluetooth to the PCB. There would have been an increase in dimensions in the Pouch to give the bluetooth more space so it wouldn’t be such a tight fit. The main adjustment that would have been made is to create a removable slot on the back side of the base so the system engineer could easily access the Microcontroller without having to disassemble the entire Segway; it would have saved a bunch of time, headaches and frustrations for the entire team. At the bottom is also a link to all the SolidWorks file used to 3D print the MicroSegbot.

Figure 13

IMG_5412

 Figure 14

side

Figure 15

top

 

 

Verification and Validation

Written By: Josh Tristan (Project Manager)

MicroSegbot Fall 15′

 

Verification and Validation

Status:

Complete

Requirement 1.1:

 

The total cost of the MicroSegbot project will not exceed [$250]. This budget was set by the customer.

Verification:

 

Per request of the customer, the reimbursement form had a total cost of $219.38 which was sent 12/3/2015.

 

Method of Validation:

 

The reimbursement form was approved on 12/08/2015.

 

Justification:

 

In order to get the MicroSegbot reimbursed, a budget was set by the customer and The Robot Company would pay the budget set or pay less.

 

Score:     /10

Status:

 

Complete

 

Requirement 1.2:

 

The MicroSegbot will resemble closely to a Segway Glider with a 6:1 scale ratio.

 

Verification:

 

The team member in charge of manufacturing will create a SolidWorks design that is scaled at a ratio of 6:1 and will resemble a Segway Glider.

 

Method of Validation:

 

Appendix B shows the Segway glider the team modeled the design after. The customer will decide whether the MicroSegbot resembles the Segway glider.

 

Justification:

 

The purpose of the project is to resemble the Segway glider and for it to be a miniature version of a full sized Segway glider

Score:     /10

Status:

 

Fail

 

Requirement 1.3:

 

The product will be able to complete a figure 8 course.

 

Verification:

 

The MicroSegbot will have to complete the course shown in Appendix A. The MicroSegbot will be able to travel the course, including going up the incline and returning to its start point.

 

Method of Validation:

 

Using Arxterra to control the movement of the MicroSegbot, it should begin at the start point and start moving in a counterclockwise motion and head towards the incline. If it reaches the point it started by overcoming berber carpet, linoleum tile, and an incline of 2.82 degrees, then the requirement will be met.

 

Justification:

 

The customer had set an objective for the MicroSegbot to complete the figure 8 course.

 

Score:     /10

Status:

 

TBD

 

Requirement 1.4:

 

The MicroSegbot will be able to travel up a 2.82 degree incline as defined by the course.

 

Verification:

 

The MicroSegbot will be tested by going up and down the ramp located in room VEC 501 shown in Appendix A.

 

Method of Validation:

 

The customer will decide if the MicroSegbot is able to complete the course shown in Appendix A by traveling through the incline.

 

Justification:

 

The figure 8 course has an inclination of 2.8 degrees, which the MicroSegbot must traverse.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

TBD

 

Requirement 1.5:

 

An action figure will be used to ride the MicroSegbot through the course.

Verification:

 

This requirement will be met if the MicroSegbot is able to carry the action figure throughout the entire course shown in Appendix A. Also, the MicroSegbot is scaled to a 6:1 ratio of a Segway Glider which means an action figure of 12” will be the height required to fulfill this.

 

Method of Validation:

 

From the start of the course and until the end, an action figure will need to stay on the MicroSegbot. A ruler will be used to measure the height of the action figure.

 

Justification:

 

The customer set an objective for the MicroSegbot to be able to build a scaled down Segway robot with a 6:1 ratio that can carry an action figure.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:    /10

Status:

 

Complete

 

Requirement 1.6:

 

The MicroSegbot will have the capability to maneuver on berber carpet and linoleum tile which can be shown in Appendix C.

 

Verification:

 

The tires on the MicroSegbot are designed to have a sufficient friction in order to be able to travel across the course regardless if it is linoleum tile, berber carpet or the rubber strip. The wheels have a rubber band around the rim, which is then covered with a rubber coating to ensure it can traverse all the surfaces from the figure 8 course.

 

Method of Validation:

 

The customer can validate that the MicroSegbot travels across the course regardless if the floor is linoleum tile, berber carpet or the rubber strip.

 

Justification:

 

The customer wanted the product to run the figure 8 course located in VEC 501. The course floor in that room consists of berber carpet and linoleum tile connected by a rubber strip.

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

TBD

 

Requirement 1.7:

 

In order to complete the course, the MicroSegbot will be able to travel at a minimum of .5 ft/s.

 

Verification:

 

The team will measure the time it takes for the MicroSegbot to cover a certain distance, to see if the requirement is met. A blog post is online that explains the calculations that verify the required speed.  The speed given was to ensure the MicroSegbot finishes the course within a reasonable amount of time.

 

Method of Validation:

 

The customer is able to determine if the MicroSegbot is able to achieve the required speed by referring to the calculations on the blog post and by witnessing the MicroSegbot travel on the evaluation day.

 

Justification:

 

The MicroSegbot should be fast enough to finish the course shown in Appendix A within a reasonable amount of time.

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

Complete

 

Requirement 1.8:

 

The MicroSegbot will use an android phone/laptop to navigate wirelessly by the customer.

Verification:

 

An Arxterra application running on an android phone should be able to give commands to the MicroSegbot. The MicroSegbot should then successfully respond to these commands and navigate in the given direction.

 

Method of Validation:

 

The customer will input forward, backward, left, and right to verify that the MicroSegbot responds to the commands in the corresponding direction.

 

Justification:

 

The customer requested that the project utilize the Arxterra interface to control the MicroSegbot.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

Complete

 

Requirement 1.9:

 

The project will comply to the health and safety policies enforced by CSULB.

Verification:

 

The team will comply with the safety policies to ensure a safe environment when testing the MicroSegbot.

 

Method of Validation:

 

The final product will have no potentially dangerous leads and sharp edges that may harm a staff or student.

 

Justification:

 

The CSULB health and safety policies were created to keep a safe environment for its staff and students.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:    /10

Status:

 

TBD

 

Requirement 1.10:

 

The Project will be completed no later than December 16, 2015 which is the end of the semester for CSULB.

 

Verification:

 

The team will complete the project by December 16, 2015.

 

Method of Validation:

 

The project will be presented to the customer on the listed date for validation.

 

Justification:

 

The project must be completed by the end of the semester.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

Complete

 

Requirement 2.1:

 

In order to travel the course and be faithful with the design of the Segway, the MicroSegbot will implement dual DC motors.

 

Verification:

 

The MicroSegbot will use two micro DC motors in order to maneuver the figure 8 course.

 

Method of Validation:

 

The customer can look inside the base of the MicroSegbot to see the dual DC motors are being used. The MicroSegbot can also be seen traversing the course using the DC motors.

 

Justification:

 

The DC motors being used were found to be some of the smallest motors and produce the

required torque that allows the MicroSegbot to traverse up the incline and decline of the figure 8 course.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

Complete

 

Requirement 2.2:

 

The printed circuit board (PCB) cannot exceed the frame of the base of the MicroSegbot.

 

Verification:

 

The PCB design was designed to fit at the bottom of the base (1.75x.165 inches). The PCB fit perfectly onto the brackets designed at the bottom of the base used to hold the PCB in place.

 

Method of Validation:

 

The customer will be able to confirm the PCB fits at the bottom of the base.

 

Justification:

 

In order to have all our components fit within our MicroSegbot the team had to minimize the size of all components. The PCB had to fit within the base as it is the only location in the MicroSegbot where the PCB could be placed while maintaining the 6:1 ratio.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

Complete

 

Requirement 2.3:

 

To communicate with the MicroSegbot, BLE and V2.0 were being studied; but to finish the project on time, a Bluetooth V2.0 device will be used and will be compatible with the Arxterra software.

 

Verification:

 

The Bluetooth is located within the pouch of the MicroSegbot. The Arxterra communication is tested by sending commands to the MicroSegbot via the Bluetooth.

 

Method of Validation:

 

The customer will be able to input forward, backward, left, and right to verify that the MicroSegbot responds to the commands in the corresponding direction via Arxterra using the Bluetooth.

 

Justification:

 

The Bluetooth provides the MicroSegbot the easiest way of communicating with the customer commands. Arxterra can communicate via Bluetooth and provides the team a method of giving the MicroSegbot commands.

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

TBD

 

Requirement 2.4:

 

A device containing a gyroscope and accelerometer that sense orientation and acceleration will be used on the MicroSegbot. The device shall have a max baud rate of 38,400, which is the optimum rate for the Arduino Nano which has the same clock speed as the Arduino Micro.

Verification:

 

The MicroSegbot will be tested going up the course’s ramp, shown in Appendix A, while keeping it balanced.

 

Method of Validation:

 

The customer can confirm the gyroscope and accelerometer are located on the PCB. The accelerometer will supply the angle that the MicroSegbot is at and supply the microcontroller the data to feed the motor the correct speed it needs at that period of time. The MicroSegbot can be seen attempting to balance itself using the gyroscope and accelerometer.

 

Justification:

 

The MicroSegbot will be traveling on a surface that has different angles and needs to keep its balance throughout.

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

Completed

 

Requirement 2.5:

 

Per the design of the tires, and according to our calculations, the selected DC motors will travel the calculated speed as well as overcome the incline and friction. This can be verified by analyzing the torque that the motors can perform.

 

Verification:

 

The motors are tested on carpet, tile, and up the incline in order to pass the requirement.

 

Method of Validation:

 

The customer will validate if the motors are able to traverse the incline and decline.

 

Justification:

 

The motors should be able to overcome the friction of the carpet, tile, and incline in order to complete the course shown in Appendix A.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

Complete

 

Requirement 2.6:

 

Because two DC motors are being used, a dual DC motor driver must be utilized to provide the motors with enough current, voltage, and PWM compatible based on their specifications. After performing a motor driver trade off study, the DRV8835 was chosen.

Verification:

 

This requirement is verified by the DRV8835 motor driver’s ability to supply an increase in

current and controllable PWM pins to allow the motors to run at different speeds. A trade off study was completed to chose a sufficient motor driver.

 

Method of Validation:

 

The customer will see that the motors can make the MicroSegbot travel at different speeds by communicating PWM signals.

 

Justification:

 

In order for the MicroSegbot to travel the course, the motors must have enough current supplied to allow the MicroSegbot to travel uphill, and different PWMs to allow it to turn and travel at different speeds. It must also be small enough to fit on the PCB inside the base of the MicroSegbot.

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

Complete

 

Requirement 2.7:

 

A microcontroller that will support each component of the MicroSegbot will need to be used to be able to accomplish the program requirements. The microcontroller will need rx/tx serial communication to be able to be compatible with the Bluetooth module. It will also need to have two PWM pins and two analog pins to be compliant with the motor driver and the accelerometer respectively.  The microcontroller that meets these specifications and fits within the dimensions is a Sparkfun Pro microcontroller and will be the module that will be used to control the MicroSegbot.

Verification:

 

The PCB was fabricated to accommodate the pin layouts to the respective components. The accelerometer will supply the angle that the MicroSegbot is at and supply the microcontroller the data to feed the motor the correct speed it needs at that period of time. The motor driver will be capable of supplying the respective duty ratio fed from the microcontroller to the motors which will make the motor driver move at the speed and direction. The Bluetooth module will be able to communicate and receive data through the RX and TX pins.

 

Method of Validation:

 

The customer will control the robot with the Android phone which will verify all the components working synchronously through the microcontroller.

 

Justification:

 

The microcontroller is needed to be able to interact and command components to perform their respective duties.

 

 

Score:     /10

Status:

 

Complete

 

Requirement 2.8:

 

The battery chosen for the MicroSegbot must be capable of providing enough current and voltage to our MicroSegbot and be within our budget. According to our power budget and battery tradeoff conducted the battery we have chosen fits all our program requirements and will be a 7.4 V, 1000mAH, 5C Lithium Ion Battery.

 

Verification:

 

There is a blog post about the battery tradeoff, as well as a power report that explains why this specific battery was chosen. It also satisfies all the dimensions required for the MicroSegbot.

 

Method of Validation:

 

The battery has its values printed on the outside of the battery by the manufacturer. The customer can validate that our battery is providing enough power to supply the MicroSegbot.

 

Justification:

 

A small battery is required in order to power our MicroSegbot and a lithium ion battery was the ideal power supply to use for this project.

 

 

 

 

 

 

 

 

 

 

 

 

 

Score:     /10

Status:

 

Complete

 

Requirement 2.9:

 

A voltage regulator will be needed to supply the correct voltage to the motor driver that can step down 7.4V to 6V

Verification:

 

Testing the voltage readings supplied to the motor driver was taken to verify the reliability of the regulator.

 

Method of Validation:

 

Verification will be provided by observing the MicroSegbot travelling at a constant speed at different times.

 

Justification:

 

The voltage regulator is used to step down the voltage to the specified voltage that the regulator is rated for. It also provides a stable 6V rather than a slightly fluctuating voltage from the battery when it drains. The team noticed while testing the motors with the battery that depending on the voltage, the motors would operate at slightly different speeds.

 

 

 

 

 

 

 

 

 

Score:     /10

Appendix A:

Figure 8 Course

Figure 8 Course

 

Appendix B:

Segway Glider

3seg

Appendix C:

Course Floor Material

Berber Carpet

Berber carpet

Linoleum Tile

linoleum tile

 

Rubber Strip

 

rubber line on course

 

 

Design Solutions for MicroSegbot

Written By: Ricardo Gordillo (Manufacturing)

MicroSegbot Fall 15′

The Fall 15’ MicroSegbot team had a handful ideas from the gecko on how to implement a segway robot,but one of the main goals in building this robot was that it resemble a segway as closely as possible. Past segways we had encountered were incredible and looked aesthetically pleasant,but there was no segway that actually looked like a segway. In order to create the design, the team looked to find a segway that the MicroSegbot could be modeled after with the exception that it be scaled at a 6:1 ratio. The team was satisfied with the Segway glider seen in Figure 1 and ultimately the team decided this would be the Segway our MicroSegbot would be modeled afterwards.

Figure 1

seg1

The team realized that if the MicroSegbot would resemble the Segway glider then the components would have to be stored in a creative way. We had to store a battery, two micro motors, bluetooth, and the PCB that contained the gyroscope,accelerometer, and microcontroller. One of the solutions the team found was to add a pouch and found that certain segways also had the option for the consumer to add a pouch as can be seen in Figure 2 below.

Figure 2

seg2

It was decided that the bluetooth would be stored in the poucha and would have wires run down the shaft of the handle bar and connect to the PCB located at the base of the MicroSegbot. The motors would also be located inside the base. Figure 3 below shows how our team implemented the connections for our MicroSegbot.

Figure 3

seg3

The last remaining piece left unaccounted for was the battery. Finding a location for the battery was the trickiest part because at the beginning of the semester the team was not sure what the dimensions of the battery would be and if the battery was placed in the base it might make our base dimensions too big and therefore compromise the initial objective of having the MicroSegbot resemble a segway Glider. The final decision was to have it on the outside attached to a doll. Another requirement we had was to have a doll ride our MicroSegbot. The team decided to take advantage of the use of the doll and to conceal the battery within the doll. Our final design had the battery on the chest of the doll concealed by a doll t-shirt. The battery wires would then run underneath the clothes of the doll and would be connected to the PCB through a hole on top of the base lid. The hole was designed on the right side of the base lid and can easily be concealed by the pants of the doll as can be seen in Figure 4 below.

Figure 4

seg4

Overall all these design innovations were a success with the added bonus that adding the battery to the top part of the doll made our MicroSegbot top heavy and helped our project with balancing. Now that our MicroSegbot is complete, the design innovations would remain the same with one exception.

One thing our team did not account for was uploading code to our microcontroller once all the connections were made and everything was assembled. The team soon found that it was a hassle having to take apart all the pieces so we could remove the PCB and connect to microcontroller that was part of the PCB board. adjusting the PID control was a tedious process and the systems engineer had to continuously have to update the PID values.

One easy way to solve this would have been to have a detachable slot in the base located near the microcontroller portal. This would allow the system engineer to continuously plug in the USB cable without  having to disassemble the entire MicroSegbot and then assembling it all together again to use it. Due to this problem the team had to make the decision to make a whole in the base in order to make this process much easier and the result can be seen in Figure 5 below.

Figure 5

seg5

While it is not the most aesthetically pleasing sight, it was a move that had to be made. In order to cover it up the team use back electrical tape and it blended in with the color of the Microsegbot, but this is definitely one aspect that could have been accounted for in the manufacturing design.

PID Control

Written By: Yoseph Yegezu (Electronics)

PID Control

The PID theory is used to control the balance of the MicroSegbot. After determining the set point or balance point of the system, the PID is implemented to secure the system in place. The P is the amount of power you want the system to have. The I increases how fast the system reacts. Meaning it’ll try to fix the error rapidly.  The D will calculate future errors based on the current given variables. The way the team determined the PID values for the MicroSegbot is by trial and error for each variables. One of the easiest methods is to start with all the variables at 0. Then start increasing the variable P until oscillation occurs. Once it does, the D variable is increased until the oscillation stops. Then I was slowly increased to create a balanced system. If there is a sensor being used to determine the set point, make sure to secure it in place so that during the process of oscillation, the set point should not change. Another consideration to take into account is to secure everything as tight as possible. If the system is not secure, it will affect the PID. The two things previously mentioned are some of the problem we came across during testing. These PID values were used within the Kalman filter that was used and more detail about the filter can be found here. The values that the team ended up using were P=30, I=1.7, and D=28.

Interface Design Matrix

Written By: Ruben Petersen (Mission, System, and Test)

MicroSegbot Fall 15′

Figure 1

interface

The interface design matrix shown below in Figure 1 illustrates all of the connections that are made between the different components of the MicroSegbot. Using the schematic for the SparkFun Pro Micro, the team had to figure out which pins exactly could be used for all of the correct pin configurations. In the first column of the matrix seen below, all of the pin capabilities can be seen for the Pro Micro, with TX and RX pins, 5 PWM pins, I2C interface, VCC, Ground, and analog and digital pins.

The next column shows the connections between the MPU6050 and the Pro Micro. For the connection, the VCC can be supplied 3.3-5 Volts, AD0 was grounded to set the least significant bit of the I2C address to 0, SDL and SCL were hooked up to analog pins for the I2C, and the interrupt was connected to the Pro Micro’s external interrupt pin 4 (digital pin 7).

The next column is for the DRV8835 motor controller. Each enable and phase pin for both motors had to be connected to PWM pins from the Pro Micro so that the speed of the motors could eventually be controlled. After those PWM pins were input into the DRV8835, the two outputs for each motor went to connect to the motors themselves. Voltage was supplied via the voltage regulator from the LiPo battery.

The HC-06 communicates with the Pro Micro via Universal Synchronous/Asynchronous Receiver/Transmitter (USART) with the TX and RX pins. It is also supplied voltage from the Pro Micro. The HC-06 and android device then communicate with the Arxterra app to get the motors to move where needed.

The battery is connected to the Pro Micro through the voltage regulator. As mentioned above, the motors are only connected to the motor controller. Lastly, the voltage regulator goes from the battery to the Pro Micro and the DRV8835.