Difference between revisions of "Independent Study for Biobots, A Continuation"
|Line 161:||Line 161:|
physical design and algorithm work
physical design and algorithm work
Revision as of 02:17, 17 February 2007
Biobots continued ...
The overall goal for this class is to further our work from the Biologically Inspired Robots class, specifically representing the behavio(u)r of robots, co-design of physical systems and software, creation of virtual worlds for behavior testing, fidelity testing between physical and virtual models, and tracking course progress in a way that is educationally valuable to future users.
A course in which the three participants attempt to build a real robot, made out of
this is a block quote from wikipedia: http://en.wikipedia.org/wiki/Lego <BLOCK> Design and manufacture
Since their introduction in 1949, Lego pieces of all varieties have been, first and foremost, part of a universal "system". Despite tremendous variation in the design and purpose of individual pieces over the years, each remains compatible in some way with existing pieces. Lego bricks from 1963 still interlock with those made in 2007, and Lego sets for young children are compatible with those made for teenagers.
Bricks, beams, axles, minifigures, and all other elements in the Lego system are manufactured to an exacting degree of tolerance. When snapped together, pieces must have just the right amount of "clutch power"; they must stay together until pulled apart. They cannot be too easy to pull apart, or the resulting constructions would be unstable; they also cannot be too difficult to pull apart, since the disassembly of one creation in order to build another is part of the Lego appeal. In order for pieces to have just the right "clutch power", Lego elements are manufactured within a tolerance of 2 µm.
Since 1963, Lego pieces are manufactured from a strong, resilient plastic known as acrylonitrile butadiene styrene, or ABS. Precision-machined, small-capacity moulds are used, and human inspectors check the output of the moulds, to eliminate significant variations in colour or thickness. Worn-out moulds are encased in the foundations of buildings to prevent their falling into competitors' hands. According to the Lego Group, its moulding processes are so accurate that only 18 bricks out of every million fail to meet its stringent standards. It is thanks to this care in manufacturing that the Lego Group has maintained such a high degree of quality over the decades.
Manufacturing of Lego bricks occurs at a number of locations around the world. Moulding is done at one of two plants in Denmark and Switzerland. Brick decorations and packaging is done at plants in Denmark, Switzerland, United States, South Korea and the Czech Republic. Annual production of Lego bricks averages approximately 20 billion (2 × 1010) per year, or about 600 pieces per second.
examine the above for relevant material for engineering informatics
Here are our readings to date:
Intelligence without Representation Rodney Brooks Artificial Intelligence 47 (1991) 139-159 139
<can someone help me out with a more compact citation here?> Algorithmic Issues in Modeling Motion
PANKAJ K. AGARWAL Duke University LEONIDAS J. GUIBAS Stanford University HERBERT EDELSBRUNNER Duke University JEFF ERICKSON University of Illinois, Urbana-Champaign MICHAEL ISARD Compaq Research Labs SARIEL HAR-PELED University of Illinois, Urbana-Champaign JOHN HERSHBERGER Mentor Graphics CHRISTIAN JENSEN University of Aalborg LYDIA KAVRAKI Rice University PATRICE KOEHL Stanford University MING LIN AND DINESH MANOCHA University of North Carolina, Chapel Hill DIMITRIS METAXAS University of Pennsylvania BRIAN MIRTICH MERL DAVID MOUNT University of Maryland
This article is based on the report of the Workshop on Algorithmic Issues in Modeling Motion, sponsored by an NSF grant CCR-00-83-033 and an Army Research Office grant DAAD 19-00-1-0478, held on August 6 and 7, 2000 at Duke University, Durham, NC.
Stair Climber Smart Mobile Robot (MSRox) Mohsen M. Dalvand1 and Majid M. Moghadam1 Autonomous Robots Volume 20, Number 1 / January, 2006 Pages 3-14
what are the right policies for citation in a forum like this? here are some of the issues of plagarism in academia:
what is the drexel policy? what citation/reference standard should I adhere to for this wiki--is it good enough to be so that some person reading after could recreate? what about in a context of digital archiving? examine this question.
why can't i just link the actual papers here? what are the intellectual property rights?
Our current status is that we have performed a prototype evaluation of the following locomotion strategies and decided upon a strategy for our prototype:
-inchworm style (accordian type motion with a wheel climbing up the stair) -flipping and crawling (having body segments that lift other body segments up onto the stair) -tri-wheel front crawler (which we are currently going with, so more about this later) -tank tread type design (we may come back to this one)
We got the tri-wheel idea from the paper Stair Climber Smart Mobile Robot (MSRox) in Autonomous Robots (I've attached a zip of the article html), which also has some nice comparisons of locomotive strategies and good ideas for analysis.
Our robot will have three wheels on each of the right and left sides of the front axle. These wheels will roll when the robot is moving around on flat ground, and the entire assembly will tumble and pull the robot up stairs/obstacles when the robot is in climbing mode. There will be a single set of rear wheels, which may or may not be powered.
The current design has a single motor for the tumbling/climbing aspect, and two motors for each side (L/R) for normal rolling motion and to enable turning. As there are three sensors ports on the NXT brick, our current thinking is to have ultrasonic sonar distance detectors for all three of these sensors, though possibly we could use the compass sensor for mapping purposes. The sonars would point straight ahead and diagonally up, then we have an option of either straight behind or forward looking down to the ground, we'll have to figure this out later on. Better would be to have a single sonar that we can change the direction of, but this would take up a motor and necessitate another NXT brick in the model, and this could cause problems with tangled wires.
We've built the prototype of the front of the robot with the single tumbling motor and the triangular wheel frames. We have also built a test frame for the sensors (basically a carriage with four wheels, a forward looking and diagonally upward looking sonar) that we've playing around with writing code for. We took measurements on the spiral-ish staircase in Bossone to check the height and length of the stairs, and used this in conjunction with our sensor test frame to start coming up with algorithms for the robot to determine how high of an obstacle it can climb. We have also starting writing a basic control program for the robot and loaded them onto the NXT brick.
-come up with a good name for the robot -start on the virtual model of this style of locomotion, also model the Bossone stairwell environment in Adams -work on the wiki page to document work to date -come up with a definition of the behaviors for the robot (possibly a flow chart) -figure out the programming environment (currently we are using the Lego graphical environment, which doesn't provide enough control) -start programming the behaviors of the robot -complete the physical prototype (add rear wheels, add gear structure to triangular wheel assembly, add drive motors, decide on a sensor package)
can we put 1 or 3 or 2 treads, either back r and left, or back r and l and one diagonal middle one, or one diagonal middle one, does this interfere with sonar or normal mobility?
physical design and algorithm work
http://www.botmag.com/articles/vex_1.shtml can we have an onboard video camera or better yet an onboard video camera that we deposit in a maze and solve the art gallery security man placement problem?
pictures of the robot
pictures of the geometric sensing
picture of the flow chart for the driving algorithm