Download B2B

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Perturbation theory wikipedia , lookup

Lateral computing wikipedia , lookup

Mathematical optimization wikipedia , lookup

Computational electromagnetics wikipedia , lookup

Knapsack problem wikipedia , lookup

Computational complexity theory wikipedia , lookup

Fast Fourier transform wikipedia , lookup

Operational transformation wikipedia , lookup

Numerical continuation wikipedia , lookup

K-nearest neighbors algorithm wikipedia , lookup

Smith–Waterman algorithm wikipedia , lookup

Simulated annealing wikipedia , lookup

Expectation–maximization algorithm wikipedia , lookup

Algorithm characterizations wikipedia , lookup

Multiple-criteria decision analysis wikipedia , lookup

Travelling salesman problem wikipedia , lookup

Factorization of polynomials over finite fields wikipedia , lookup

Weber problem wikipedia , lookup

Genetic algorithm wikipedia , lookup

Time complexity wikipedia , lookup

Algorithm wikipedia , lookup

Transcript
A 296 MicroMouse project
By Brian Kuriyama
Profit!
•Overview
•Design goals
•Structure
•End-Goals
Started with Parallax’s BOE-bot kit
Designed 2nd 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 Sturns and similar motor controlling techniques