Requirements

/in /by

Requirements:

Level 1

  1. The μBiPed must be finished by the 8th of May, 2015 to correspond with the duration of the EE 400D class.
    1. Verification: http://csulb.edu/divisions/aa/calendars/documents/2014-2015_academic_calendar_updated.pdf
  2. The μBiPed must move (i.e. walk in a human-like fashion) up an incline that starts initially at 8° and then decreases to a 6° slope in relation to level ground. This is due to the obstacle course prescribed in the specifications.
    1. Verification: To test this parameter, the μBiPed will be sent up an incline at varying grades, starting at 6° and going till at least 8°. The incline grade may increase past the 8° in order to test failure point.
  3. The μBiPed must avoid walls at a distance of TBD. Determined by the mission profile. The distance may be determined based off of the constraints of the parts used to determine distance, or the customer may indicate distance.
    1. Verification: Will have the μBiPed walk towards an object, i.e. a wall, and see if the μBiPed will stop or try and change path. The distance will be measured with a tape measure.
  4. The μBiPed must walk over or on an object at about a 45° angle and a height of 2 cm.  This is part of the mission profile dictated by the specifications.
    1. Verification: The μBiPed will walk over an object of about 2 cm +/- 1 cm. The 2 cm is for margin of error. This will be measured by a ruler.
  5. The μBiPed must walk on surfaces of varying friction coefficients:
    1. Carpet: 1.0 static
    2. Linoleum: 0.5 static
    3. Verification: The μBiPed will walk on all the different types of surfaces. Carpeting will vary, it will range from thick to thin. Verification for each surface friction coefficient was found on the below websites.
  6. The μBiPed must stabilize when disturbed by a force/time. The force has not yet been calculate. This requirement is dictated by the specifications and mission profile.
    1. Verification: The μBiPed will be hit to test response to immediate impact, and will be tested for force applied over time, i.e. a push. Force will be measured by a force gauge or equivalent.
  7. The μBiPed must weigh no more than 1 kilogram in order to facilitate the miniaturized size of the μBiPed. Otherwise, if the μBiPed is too heavy the project may not be realizable.
    1. Verification: The servos will be tested for maximum torque, then μBiPed will be weighed with a scale and will be checked if it can move.
  8. The μBiPed must interface with Arxterra Remote Control™ mode as defined by the specifications. The RC mode must be used because the μBiPed must conserve its mass; any additional mass, such as a phone would require the increase of size.
    1. Verification: The Arxterra Remote Control™ mode will be used to direct movement in the μBiPed. Movement via Bluetooth will verify that connection with Arxterra has been meant.
  9. The μBiPed must be miniaturized as is dictated by its own name, size 7 inches.
    1. Verification: The μBiPed will have its size miniaturized compared to its larger model. Measurement will be done with a ruler or equivalent.

 

Level 2

  1. In order to avoid an obstacle the μBiPed will use an HC-SR04™ ultrasonic sensor. Primary reasons are that it is less susceptible to noise and cost; in addition, the project has one in inventory. Refer to requirement 3, level 1.
    1. Verification: Based on previous semesters, distance will be determined when height of the μBiPed has been decided to finalize the angle of detection. Calculations will be done similar to previous semesters. Link provided below.
    2. https://www.arxterra.com/ultrasonic-sensor-examination/
  2.  The μBiPed will use a gyro, type MPU-6050, in order to allow for completion of requirement 2, level 1, and requirement 6, level 1.
    1. Verification: The μBiPed will be tested on how well the gyro keeps it stable. This will be done by walking over uneven surfaces and not falling over.
  3.  In order to successfully miniaturize the μBiPed, micro-servos will be used. Type of micro-servos are MG92b after testing. The project must test the micro servos using SolidWorks or through math analysis in order to determine if micro servos provide enough torque to complete the project.
    1. Verification: Micro-servos will be tested on strength and maximum load they can handle based off the load bearing tests.
  4.   In order to miniaturize the μBiPed, a microcontroller, type Arduino Micro, must be chosen. The microcontroller should at least have 14 kb of Flash memory and 4.7 kb of SRAM.
    1. Verification: Microcontroller will be tested if it can control at least 12 servos and facilitate the additional components needed to implement the μBiPed.
    2. Reduced the footprint of the code.
  5. Due to the miniaturization of the μBiPed, a PCB board will be fabricated that includes the wiring for the gyro, the Bluetooth IC, and the servo pins that will allow for the microcontroller to interface with the assembly.
    1. Verification: A continuity test to verify proper wiring layout of the PCB.
  6. In order to traverse multiple surfaces (requirement 5, level 1) the μBiPed’s legs must have some type of tread or rubber sole added to it. Reference.
    1. Verification: Will test the μBiPed with various types of tread to see the traction difference.
  7. In order to keep within the specified size restriction, the μBiPed will have light weight batteries. Type of batteries are LIPO 2S 350mAh.
    1. Verification: Testing and calculations will be performed before selection.
  8. A light weight material must be used for the frame in order to keep within the specific mass restrictions of the μBiPed; the type of material is PLA. Testing must be done as to whether or not the μBiPed can be made of plastic, or if a lighter material must be used.
    1. Verification: Different materials will be strength tested and weighed. Strength testing will be verified by hand, and weight will be verified with a scale.
  9. As mentioned in item 5, a Bluetooth IC will be chosen that will communicate to the Arxterra™ program. An IC must be used in order to minimize the μBiPed size and mass. The type of Bluetooth IC is HC-06. Requirement 9, level 1.
    1. Verification: To test if the Bluetooth IC works properly commands will be given from the Arxterra Remote Control™ program and the robot will respond accordingly.

Reduction of Dynamic Memory Usage

/in /by

By: Tate McGeary

As stated in a previous blog, one of the immediate issues that was evident was the lack of resources on the smaller micro-controllers. The micro-controller that was chosen the Arduino Micro has the following resources:

32 kb of flash (4kb for the bootloader): 28 kb flash available for programming

2.5 kb of SRAM (dynamic memory)

While the program will require around:

14 kb of flash

4.7 kb of SRAM

That means the program uses a little under 200% of the dynamic memory. The first task was to go through the code and reduce the variable footprint. All variables that were constant where pushed into flash memory with the PROGMEM, but this did not reduce the SRAM usage enough. It was determined that a majority of the SRAM was used due to the tables that stored the movement of the BiPed. These tables could not be stored in flash in the original code due to the modification the tables went through. In the original code the tables had to be modified through the use of a calibration sub function because the frames are usually different BiPed to BiPed.

Using Robot Poser  from Dr. Dowdall, a servo calibration table is created and inserted into the original code. From there the sub-function called calibration(), will then map the servo calibration table to the proper frames used for the BiPed locomotion phase. The calibration() function is what uses a majority of the SRAM simply because it is actively modifying the tables stored on the Arduino which are rather large.

To overcome this two methods were thought of.  One is to separate the calibration() code and have an Arduino MEGA output the data to a text file on a computer. Another method is to use Processing 2.21 (a JAVA type language) or MATLAB. By looking at a flowchart of the calibration code ( see below) one can see how it can be applied or modified to fit a different platform other then the original code.

applycalibrate

Right now, the group is working on the calibration() code for the Arduino MEGA outputting data to a computer and a MATLAB code. However, a version for Processing 2.21 is being tested and completed using Dr. Dowdall’s logic, variable declarations,  and method. The project chose Processing 2.21 in case an individual wanted to reduce the footprint of the code, but didn’t have access to an Arduino MEGA or MATLAB. As Processing is a free compiler and anyone can access it, the group decided to try and get Processing to do the calibration. Here is a link to the current Processing code.

Immediate issues Micro-controllers and Choice.

/in /by

By: Tate McGeary

One of the immediate issues with the Micro BiPed showed itself in the code and micro-controller. When researching the micro-controller, it became evident that the smaller micro-controllers do not have enough memory.

The program at minimum required 14kb of flash memory and 5kb+ of dynamic memory (SRAM). In order to compensate for this, it was planned on using an ATmega 2560 micro-controller set on a custom board designed by chip45, the crumbiuno Mega. But when testing the device it immediately became evident it would not work. The primary reason was due to the inability to connect to the Arduino IDE, two different Crumbiunos™ were tested and neither worked. To eliminate hardware issues, a continuity test was done on all the components, all of which passed. The crystal itself was also tested, for if it was bad. Using the GwInstek GDS-2062 the crystal was measured; the output (pictured below) was appropriate.

crystaloutput

The noise in the picture above is due to the flux that coated the prongs of the crystal, however despite the noise 16MHz can be seen. This means that issues with components has been ruled out, as all parts pass scrutiny.

Due to the inability to use the Crumbriuno™, it was decided to use one of the Arduino standard boards. The micro was decided on.

While the micro has a 28kb of flash memory and 2.5kb of dynamic memory (SRAM) the code could still fit if the variable declarations are moved from SRAM to flash. This can be done through the use of an Arduino function called PROGMEM when declaring variables. There were some issues using PROGMEM, see the post detailing reduction of memory.

 

Due note that all values for resource usage was given by Arduino IDE 1.6.1. Arduino IDE 1.6.0+ all give the SRAM usage as a dynamic memory output when a program is compiled along with flash resource usage.

 

Micro Processor chosen:

As explained , the initial option was the Crumbuino Mega™ however it was not possible to get the Mega to communicate with the computers at hand. So the other option was the Arduino Micro™. The primary issue with this microcontroller was lack of resources; SRAM exclusively. To compensate the project went through and reduced the variable allocation used in the program by taking out the calibration() explained in another blog. The other issue that was determined was the lack of PWM pins. PWM pins are important because the microBiPed uses 12 servos all of which need PWM impulses to move to the correct location. Yet, the Arduino Micro ™ does not have enough PWM pins, rather it has 7. To compensate for this the project is looking into using TLC5940™ ICs produced by Texas Instruments. The TLC5940 will take the necessary information from Arduino Micro™ using the appropriate library and the correct commands the TLC5940 can turn 4 PWM pins into 16.

 

Micro BiPed Introduction

/in , /by

Mission Objective:

The project mission is inspired by the BiPed designed by Jonathan Dowdall of Project Biped, completed in previous semesters of EE 400D. The goal is to scale down the BiPed design by changing standard servos to micro servos to yield the μBiPed, which will result in design changes to the robot. The robot must be able to communicate and be controlled by the Axterra™ application. The final deliverable of this project is to have the µBiPed maneuver through an obstacle course, while being able to resist outside disturbances.  The course may include multiple surfaces, an incline, and an obstacle avoidance portion; however, the challenges in the obstacle course may change.

Mission Profile:

The μBiPed must complete an obstacle course on a figure 8 track in ~ 7 minutes. The obstacle course will require the μBiPed to cross over a threshold, at approximately a 45° angle and a 2 cm height. From there the μBiPed must ascend an incline that is initially an 8° slope which then decreases to a 6° slope. Half way through the course the μBiPed must then start its descent down the incline towards the threshold again crossing over it at about a 45° angle proceeding towards its start position until an object (i.e. a wall) causes the μBiPed modify its path. Additionally the μBiPed must be able to withstand external disturbances. Finally the μBiPed must be able to traverse multiple types of surfaces which will include carpet, linoleum tile, and metal. All of this must be completed while using the Arxterra™ interface as per requirements. It has also been specified that microServos must be used.

Course

*The above diagram was created in AUTOCAD™ 2014.

*Measurements were provided by the microSegway group, and confirmed by the microBiPed group.

 

Mission Objective and Level 1 Requirements

/in , , , /by

By Ayaka Hatori, Project Manager  —  TEST

Hello and welcome to UFO – AbDucted!

Mission Objectives:

The UFO-AbDucted team is hard at work to create a product that will resemble a UFO from the 1951 movie The Day the Earth Stood Still, which is small enough to land in the palm of one’s hand. The UFO will fly for two minutes in an unobstructed field at a height greater than 8 feet while a light show plays for the duration of the flight.

 

image6

Requirements:

Level 1

1. The UFO will resemble a UFO from the 1951 movie The Day the Earth Stood Still. 

Test: The final product will be visually compared against an image of the UFO from the movie to verify likeliness.

2. The UFO will fly at a height of 8 feet or higher for a minimum of two minutes.

Test: The UFO flight height will be measured against a calibrated 8 foot long object and the entire flight time will be video recorded to verity that it has met the minimum flight time requirement.

3. The UFO will be small enough to land safely in the palm of the hand.

Test: The UFO will be held in the hand comfortably without it falling off.

4. The UFO will display a light show for the duration of the flight.

Test: The UFO will have a colorful light show displayed from the bottom of the craft while it is in flight.

5. The UFO will be fully controllable on the x, y, and z axes through interfacing with the Arxterra application on an Android device.

Test: The UFO will receive communication signals from the application via bluetooth and correctly perform the dictated movements.

Final Project Document

/in , , , /by

By Kristine Abatay – Project Manager
      Matthew Clegg – Computer & Control Systems
      Simon Abatay – 3D Modeling & Manufacturing

Before signing off with the final document for Spiderbot, we would like to thank various members of the Robot Company in aiding with the completion of Spiderbot:

First off, we would like to thank David Gonzalez of last semester’s Hexapod project for his loan of Chop Suey for preliminary code practice.

We would like to thank Ali Etezadkhah of 3D Bioprinter and division manager of manufacturing, for allowing us use of his 3D printer for the class and for printing Spiderbot’s pieces in a timely fashion.

We would also like to thank Tommy Sanches of MC3 for his immense help in getting Spiderbot connected to Arxterra.

We would like to thank Elaine Doan of Biped for helping run tests and for guiding Spiderbot in the writing of requirements.

Finally, we would like to thank Vice President (Dr.) Larry Harmon for all of his hard work in posting countless blogs and grading presentations, despite his busy schedule.

THANKS!

A pdf file of the final document of Spiderbot can be downloaded here:

https://dl.dropboxusercontent.com/u/184627659/EE%20400D_Spiderbot_CDD.pdf

This is Project Spiderbot signing out.

Live Long and Prosper!

Spiderbot: Struggles Remembered and Suggestions

/in , , , /by

By Kristine Abatay – Project Manager
      Matthew Clegg – Computer & Control Systems
      Simon Abatay – 3D Printing  & Manufacturing

Following the mass lay-off of all members of the Robot Company for Spring 2014, we remember the numerous struggles faced by Spiderbot with the following video:

http://youtu.be/1e-2mCIpM-Y

Many improvements can be done to make future Spiderbots better machines.

For one thing, connection of Spiderbot to the Arxterra Android App can definitely be helped by possibly finding a forest-like route in a different location on campus. Many issues occurred on demonstration day during the race against Rover and Hexapod. Connection was constantly dropped when multiple projects were connected to the app in the particular race course area and perhaps a location with better wifi connection might remedy that issue.

A route with a more even terrain might be helpful in preventing damage to the gears of the servo motors, as was done with one of the servos from a rear leg of Spiderbot.

A convenient trick we learned from Tien Dang, Communications member of Hexapod, was that if, when taken apart, the servo motor shows gear damage, then the motor can easily be fixed by replacing the gear, which can most likely be purchased online. This is much cheaper than purchasing a whole new servo motor.

The damage was most likely done when testing Spiderbot in the race location prior to the race, when it encountered the various branches of the course.

As for manufacturing, the individual pieces can be improved to help Spiderbot’s overall performance. For one thing, the tibia side portions of Spiderbot’s tibia pieces can be shaved down. The pieces were extended mostly for aesthetics, so if they were shaved down to the same width as the servo motors in their particular orientation, then they should function just the same and be lighter in weight in the long run.

The base of Spiderbot was ultimately very dense, causing the stance of Spiderbot to be higher than it should have been in order to support the entire piece. A wider base most likely would have allowed for a lower position and therefore, a faster sweep of the legs. Research regarding a possible ratio between the base width and leg length should be done to achieve a faster speed.

In regards to the connections of the bracket pieces, the tibia pieces were molded in a manner that made it difficult for the screws to easily tread and lock into them. Because of this, epoxy was initially used, but after testing in the grass, it proved to be too weak of an adhesive. Loctite is recommended as a better adhesive alternative to insure secure connection. That, and testing in terrains aside from grass, since the grass most likely caused some wear and tear in the servo motors from the legs getting stuck.

Purchasing stronger servos would be a good alternative to increase the speed as well, but will ultimately rack up the cost of the final project. Another thing to keep in mind in regards to cost is that creating a mold to cast 3D pieces will require a lot of material, so the initial starting price for this project is already projected to be a couple hundred dollars, so mold and cast wisely.

Good luck to all future Robot Company Projects!

Spiderbot: The Final Video

/in , , , /by

By Kristine Abatay – Project Manager

With the demonstration of all projects having wrapped up, the final video for Spiderbot, created by yours truly, has dropped! The video can be viewed after clicking the following link:

http://youtu.be/5wJuN8XxtVk

Enjoy!

Project Burndown and Overview

/in , , , /by

By Kristine Abatay – Project Manager

The following image displays the final overview of Spiderbot:

 Blog25_image1

Due to the incomplete state of some of the tasks originally assigned, Spiderbot is only 83% complete. The slack comes from the planning and programming portions of the progress of Spiderbot. Manufacturing is labeled at 100%, since, though not done in the timely fashion that was hoped for, Spiderbot’s design came out, for the most part, as planned.

The burndown of the project can be seen in the charts below:

 Blog25_image2

I did not account for many of the issues causing delays that were encountered throughout the progress of this project, so the work and task burndown plots are steeper than they should have been. 

A Day at the Races

/in , , , /by

By Matthew Clegg – Computer & Control Systems

It all began earlier in the day. Group members Kristine Abatay, Simon Abatay and Matthew Clegg met early in a classroom, for a last second check to ensure everything on Spiderbot was working properly.  A couple of screws were tightened and the Android phone was connected properly to the Arxterra website. The group had lunch to prepare for the race. At around 2 o’clock, Spiderbot, Hexapod, and Rover met on the predetermined course.

SONY DSC

SONY DSC

There was a bit of nervousness coming from all the groups. Who would come out on top? Who would be showered with glory and accolades as the victor or who would crash and burn in failure and leave bitter and dejected? Negotiations quickly took place to shorten the course with less obstacles but this did not go through because the original course was outlined in the requirements and had to be the one all of the projects would race on.

SONY DSC

Both Spiderbot and Hexapod were fairly large, so having them all line up and race at the same time would have proven difficult. It was decided that each project would go individually and a time would be kept as it traversed the track.  All of the groups had difficulty at first establishing a connection due to Wi-Fi issues but it was all eventually settled by having only one project at a time connected to the Arxterra control panel.

SONY DSC

We (Spiderbot) got everything up and running and decided to go first. The first two steps started off well, but after that things quickly deteriorated. The pathway was on uneven ground, so with each step, Spiderbot slowly drifted to the left. Attempts to correct this did not fare well either. As it was turning, it lost footing, which caused it to collapse. It was picked up and set on course again. The next problem to arise was the servos. The rear right servo that causes the spider to lift its leg started making a horrible grinding noise with each lift. The weight of Spiderbot might have been too great for the servos to sustain for an extended period of time. At this point, it was decided to shut everything down to prevent further damage. Simon opened up the servo and found the gears inside to be busted.

The total distance traveled was roughly 6 feet at a time of around 3 minutes. Hexapod and Rover reached a further distance but did not have their share of issues. No project completed the full course. Spiderbot was defeated that day, but it was not a total loss. The knowledge learned from the track can be used by future projects for better planning and design. From the ashes, Spiderbot shall rise again like the phoenix.

SONY DSC

Here’s a link to a video of the exciting race day!:

http://youtu.be/XNUIfEWJOmY