A 296 MicroMouse project By Brian Kuriyama. Profit!

Slides:



Advertisements
Similar presentations
May 19, 2012 Lloyd Moore, President/Owner Just kidding – next slide please!
Advertisements

Autonomy using Encoders Intro to Robotics. Goal Our new task is to navigate a labyrinth. But this time we will NOT use motor commands in conjunction with.
MicroMouse Proposal Presentation Team: Amaze Me. Introduction Members and roles Brandon Gibu Brandon Gibu Updating webpage Ah Ram Kim Ah Ram Kim Contacting.
Proposal Presentation EE 396 – Micromouse Spring 2008 Saturday, February 9, 2008 Donald Kim Lab - POST 214.
Ramrod IV Micromouse 396. The Team  Andrew Igarashi – Programming  Kevin Li – Hardware  Amy Maruyama – Hardware  Stephen Nakamura – Hardware  Quang.
A fully autonomous robot designed to navigate and solve a maze.
The Pied Pipers Alyssa Visitacion Ken Shum Joanne Flores.
Ramrod III Micro mouse. The Team  Andrew Igarashi – software  Kevin Li – hardware  Stephen Nakamura – hardware  Quang Ngu – software.
Preliminary Design Review Micromouse EE 296 Spring 2008.
EE 296 TEAM “DA KINE” MICROMOUSE PROJECT PROPOSAL Team members: Software Group - Henry, James Roles : tracking, mapping, guidance, interface Hardware Group.
Micromouse Team:. Team Members Kanoa Jou (Leader) Ryan Sato (Organizer) KiWoon Ahn (Organizer) Brett Ikei (Recorder)
EE396 Project Micromouse Team: Ocha. Team Members Kanoa Jou (Programmer) Ryan Sato (Hardware) KiWoon Ahn (Recorder) Alan Do (Programmer)
("/(o_O)\") RaWr! Design Review Presentation March 11, 2006.
FINAL PRESENTATION Lost Café 66 EE 296 5/6/2004. Introduction of Team Team Leader: Arthur Phanphengdy Members: Quincy Quach Kang Lu Jackson Ng.
‘Iole o Mãnoa Mouse of Mãnoa. Team Members Jeff Fines Designer, Fabricator, Programmer & Thomas Matsushima Designer, Fabricator, Programmer.
Micromouse 296 Final Presentation Fall 2008 Group: Rabbitwagon.
Amaze Me Final Presentation May 4, Introduction of Team Amaze Me Team Members –John Miyajima –Brandon Gibu –Justin Ogata –Ah Ram Kim.
Preliminary Design Review
1 Final Presentation Team Amaze Me May 8, Content Members Overview of Project Goals Structure of Design Design Decisions Problems & Improvements.
KTD Micromouse Overview Team Goals Approach Outstanding Problems Future Solutions Final Status.
take your JACKET OFF KELLIESCOTT KENDALLJAYSON Final Presentation  Members:  Jayson Nakakura: Chassis Design and Fabrication  Kellie Murakami: Circuitry.
Design Review Presentation Lost Caf é 66. Introduction of Team Team Leader: Arthur Phanphengdy Members: Quincy Quach Kang Lu Jackson Ng Team Name: Lost.
TAKE YOUR JACKET OFF! Proposal Presentation  Members:  Jayson Nakakura: Chassis Design and Fabrication  Kellie Murakami: Circuitry Design and Fabrication.
M & M EE 296 Final Presentation Spring 2004 Presentation Overview Team Member Introduction Project Overview Overall Design Description Final Project.
("/(o_O)\") RaWr! Final Presentation May 9, 2006.
Micromouse Spring 2006 K A L The Pied Pipers. The Pied Pipers: Joanne – Programming Ken – Hardware Alyssa – Hardware Introduction of Team and Roles.
("/(o_O)\") RaWr! Proposal Presentation February
Ramrod IV Micromouse 396. The Team  Andrew Igarashi – Programming  Kevin Li – Hardware  Amy Maruyama – Hardware  Stephen Nakamura – Hardware  Quang.
Micromouse Team:. Team Members Kanoa Jou Ryan Sato KiWoon Ahn Brett Ikei.
Final Presentation EE 396 – Micromouse Spring 2008 Friday, May 9, 2008 Donald Kim Lab - POST 214.
Preliminary Design Review EE 296 – Micromouse Spring 2007.
M & M EE 296 Project Spring 2004 Alex Gomera Sophomore: electrophysics?!?! Favorite EE Teacher: F. Koide I hope to be like that man 
Team Asphalt Kellen King Ikaika Ramos Brad Centeno.
Team P.A.C.K men EE 296 Project. Chris Mcleod Hardware Specialist.
MicroMouse Final Presentation Jill Kobashigawa Min Mo Jon Shindo Christy Kaneshiro.
EE 296 Team Da Kine James Cuaresma – Software Wesley Mina - Hardware Regi Morales - Hardware Henry Do - Software.
The goals of Micromouse: to build an autonomous “mouse” Mouse should be able to navigate and solve any given maze Mouse should be no bigger than 25.
Curry Mouse EE296 Final Presentation Wednesday, May 10, 2006.
The goals of Micromouse: to build an autonomous “mouse” Mouse should be able to navigate and solve any given maze Mouse should be no bigger than 25.
KTD Micromouse OverviewApproach Potential problems Personal Expectations Team Goals.
Micromouse 296 By Lemmings. Introductions  Vicky- coordinator, software oriented  Bryce-morale booster, software oriented  Ruffer-time keeper, hardware.
Team P.A.C.K men EE 296 Project. Chris Mcleod Hardware specialist.
EE 296 TEAM “DA KINE” MICROMOUSE PROJECT PROPOSAL Team members: Software Group - Henry, James Roles : tracking, mapping, guidance, interface Hardware Group.
Final Presentation EE 296 – Micromouse Spring 2007 Friday, May 4, 2007 POST 214.
Curry Mouse EE296 Design Review Presentation Saturday, March 11, 2006.
Administrative Introduction Our goals for this project is for the two robots to work together intelligently using wireless communication Not only did.
Microcontroller Robot Design Spring 2003 Advisor : Prof. Hayler Engineering Team: Mark Vo Jing Hua Zhong Abbas Ziadi.
Overview of Project 1 Slides are available at : Report due next week Matthew Murach.
Maze Challenge Maze Challenge activity > TeachEngineering.org
GROUND UTILITY NETWORK DECIPHERING AUTOMATED MACHINE GROUP 10 BLAKE SIMONINI DIDIER LESSAGE GABRIEL RODRIGUEZ G.U.N.D.A.M.
Team 4 Shane Sunada – Project Leader Malcolm Menor – Project Manager Nathan Umeda – Technical Supervisor Joseph Longhi – Documentation Final Presentation.
EV3 Workshop Oct 3, 2015 Instructor: Chris Cartwright
‘Iole o Mãnoa Mouse of Mãnoa. Team Members Jeff Fines Designer, Fabricator, Programmer & Thomas Matsushima Designer, Fabricator, Programmer.
Wandering Standpoint Algorithm. Wandering Standpoint Algorithm for local path planning Description: –Local path planning algorithm. Required: –Local distance.
Program Development Cycle Modern software developers base many of their techniques on traditional approaches to mathematical problem solving. One such.
Team Name: Group C.  Zisimos  Team Leader, Software Engineer  Richard  Hardware Engineer  Michael  Hardware Engineer  Jason  Software Engineer.
Back To Basics A BASIC Stamp Based Micromouse B2B MicroMouse Traditional MicroMouse  Language used › PBASIC  Drive systems › Servo Motors  Sensor.
Final Presentation Micromouse Spring 08 8” Comb.
Preliminary Design Review (PDR) Team Amaze Me. EE 296 Project (MicroMouse) Members –Brandon Gibu –Ah Ram Kim –John-Kalani Miyajima –Justin Ogata Website.
Team: CHEE WHOOO Spring 08. The Team Mitchell La Puente-Project Leader Josh Miyamoto-Software Richard Ordonez-Hardware.
BEGINNER EV3 PROGRAMMING LESSON By: Droids Robotics Using Sensor Data and Port View.
The George Washington University Electrical & Computer Engineering Department ECE 002 Dr. S. Ahmadi Class3/Lab 2.
EV3 Software EV3 Robot Workshop
MICROMOUSE EE296 Spring 2004 Team Name: Lost Café 66.
BEGINNER FLL PROGRAMMING WORKSHOP BY DROIDS ROBOTICS & EV3LESSONS.
Robotics Programming Wall Follow Line tracking for a set amount of time Line tracking for a distance.
An EE 296 Micro Mouse Project. Brian Kuriyama’s Profit!
How Do You Make a Program Wait?
BEGINNER EV3 PROGRAMMING Lesson
Line Following Behavior
Presentation transcript:

A 296 MicroMouse project By Brian Kuriyama

Profit!

Overview Design goals Structure End-Goals

Started with Parallax’s BOE-bot kit

Designed 2 nd Generation uMouse Chassis and board by 12/02 All Major Hardware updates completed by 12/10

Picture as of 12/10: Final Design:

Original Promised goals: General movement algorithm Result: Smart intersection and corner handling algorithms implemented Wall tracking algorithm Result: Follows walls according to the right hand rule, can accurately map out distances, but the two programs have not been merged yet Backtracking algorithm Result: Has not been implemented due to change in chassis design. But robot will return to last intersection and continue following the right hand rule.

Updated goals: Distance Tracking algorithm Result: Pulse/Distance curve has been obtained for one particular program, a crude “best-fit” algorithm provides adequate and accurate distance measuring. Wander throughout the maze following Right hand Rule Result: As of 12/11 the bot will navigate relatively reliably and can count the number of turns it has made. Solve the maze Result: Distance tracking and Movement algorithms have not been combined due to space and time constraints.

Smart turning algorithm As of 12/09

To be honest, my uMouse had no mapping algorithm implemented at the time of filming Followed 18 turns and then stopped Maze had to be RHR solvable Maze had to have no dead ends when following the RHR (as of 12/11 that problem has been fixed) Bot was in “debug mode” therefore was stopping at every intersection to announce it’s next decision audibly

Includes Dead end management As of 12/11

To be honest, my uMouse still had no mapping algorithm implemented at the time of filming Stopped filming when the bot found the center Maze had to be RHR solvable Bot was in “Regular mode” and therefore moved faster and did not announce it’s decisions.

It can navigate a maze relatively reliably following the RHR. Occasionally it does slip up due to semi known bugs in implemented algorithm. It can measure any distance traveled in a straight line and report how many blocks it has moved audibly. It can also enter a debug mode based on the current algorithm

Boebot was too big to make 90 Degree turns Code for turning was predicted to be too big Navigating out of dead ends would be difficult No good place to mount sensors For testing, sensors were friction fitted to the sides Sensor placement would require unwanted extensive permanent modification to the BOE-bot

Distance measuring was not linear Solution: Create a best fit algorithm to compensate under the conditions of the maze Allocated battery space was too small Solution: Cut off protrusions “Canned” moves were not reliable during complicated sections of the maze Solution: Designed and implemented a “smart turning” algorithm that it allowed it to correct it’s alignment when possible Voltage regulator too hot, cutting power in the middle of a program Solution: Use a larger heat sink ADC suddenly stopped reporting values from left hand side Analysis of problem: Port on ADC died. Will only report a value of 255 when queried Sharp Distance sensor also died. Will only report a voltage value of 1.85v to 1.90v Solution: Rewire spare ADC port to spare Sharp distance sensor.

Power appears to cut out randomly while in the middle of execution Solution: NOT SOLVED YET Partial solution: Smart Turning has been implemented so the robot does not crash if the robot experiences a power loss. Mapping data is still lost Possible causes: Damaged Voltage regulator Insufficient regulator cooling Errant subroutine “Return” command Insufficient program space to combine mapping with navigation Solution: NOT SOLVED YET Proposed Solution: Optimize Navigation and Mapping programs to reduce space consumption “Return to start” program has not been implemented Solution: NOT SOLVED YET Proposed Solution: Once mapping and navigation can be combined in one program, create a list of intersections in scratchpad ram to be passed onto a secondary “return to start” program “Fastest route to center” program has not been implemented Solution: NOT SOLVED YET Proposed Solution: If all the above problems are cleared, Read back scratchpad ram (supposedly a correct maze) to get to the center “Even faster method of getting to the center” program has not been implemented Solution: NOT SOLVED YET Proposed solution: If all the above problems are cleared, Implement creative, but smart methods of navigating particular turns with S- turns and similar motor controlling techniques