.......................................................................................................................................................................................................................................... EDGE
P11216: Wandering Campus Ambassador (part 6)
/public/

Meeting Minutes

===12/9/2010===

* Don't need to submit the deliverables until after the meeting on Friday
* Plans, custom needs, etc are being done off of team P11215
* Our plan is different from that of other teams
* Integrating/working with team P11215
* Tying up loose ends
* Prepping for the Innovation Festival
* More focused on build than planning
* Design/build water collection system? (Anna and Nick)
* Become very familiar with what the current team has done and is going to be working on so that when they leave we're not screwed over.
* Help current team with build and troubleshooting
* Not really successful
* Possible days are Saturdays and Wednesday mornings.

===12/10/2010===

* Mechanical
* Ability to drive around (met last year; made modifications/redesign now)
* Weather considerations
* Safety (large bump sensors; when pressure--> circuit closes; chain guards)
* Robot controls and sensors
* Handle installed
* Clutch system installed
* Larger wheels/tired--> robot won't shake as much
* Better ideas for the sonars? (4 sensors that point forward and back)
*Protection to bars when handle is pushed in?
* Cut them off
* Cross bar
* Rounded
* Put within bumper range
*Indiana Jones switch (push button, normally one)
* Does full weight of plant sit on switch or on bar below it?
* Is there a way to turn the switch off without setting off the alarm, or will it go off all the time when the plant is off?
* Mechanical aspects/specifications of the switch
* Is it designed so the weight of the plant can sit on the button for a long period of time?
* Maybe use bumper tape?
* is bumper tape good enough for safety for barriers? (doing force-check now)
* Mount for plant
* Currently one size
* Make adjustable?
* Mechanical that still possibly needs to be done
* Re-evaluate sonars
* Build/put together
* Testing
* Umbrella/water collector?
* Make adjustable plant holder?
* Look at Indiana-Jones switch?
* Handle protection so that it doesn't stab people
* Look at bumpers/sensors? (better way?)
* Physical deterrence? (water gun/sprinkler)
* Flexible membrane for LCD touchscreen
* Electrical
* Drive forward/backward/turn
* LCD screen
* Software/hardware communications (MSP430 --> micro-controllers)
* GPS communication
* Archive data robot takes in
* Problems/Discussion
* I2C --> not functional; blown chip on PCB (therefore no communication to the BeagleBoard)
* Software written; was working at one point (work again when chip is replaced?)
* Used to use Java (last group); too long and complicated (too 3 seconds for 20byes of data) therefore, switch from Java to C
* i2cgit--> Open source (foundation there) and there's support, but not enabled currently for QNX
* compiled/built in system?
* source level support, but it doesn't seem available to use with QNX right now (only source headers available)
* LCD Support--> None (displays to touch screen, but nothing works when touching the screen)
* Switch to QNX --> new/better touch screen
* Connects to USB port and DVID(and is powered by) instead of Beagleboard
* Indoor/outdoor use?
* Wait until QNX works with I2C
* Checkout LCD in Vallino's cabinet (free)
* Located under cover; open the cover to use the LCD (i.e. you can see it, but not open it to use)
* Relevant measurements
* Personality
* Plant/robot interaction
* interaction (can't be under cover then; unless flexible membrane)
* Maybe get an outside-use LCD?
* Diagnostic mode (drop down/touchscreen/simplification)
* Human factors (done by Industrial Design major)
* Interfaces
* Flash filed
* Phil has experience with this already
* Give to Industrial Design independent study student
* GPS Support
* Confirmed working (gives string of number for what it's saying)
* Rely on something else when GPS signal is lost (on what?)
* Motor control (MSP430)
* Start measuring RPMs (currently measures change, but not over time)
* Navigation (MSP430)
* Mostly working (I2C isn't)
* IR sensors
* Sonar sensors
* Compass
* Sonar sensors (weren't working)
* $100 each because they're weather resistant
* Mode of output--> not functional (pinging and getting only noise)
* Other output data does work (PWM mode)
* Physically de-soldered and re-soldered
* Are all sonars damaged?
*10-254 centimeter distance range on each
* Two swivel-sensors
* Not currently water-proofed (can be cracked open, and resealed to water proof)
* Winter Start Customer Needs Plan
* Mechanical
* Re-evaluate Servos
* Meet with Dr. Walter and Stan Rickle
* Examine sensors to see how they work
* Waterjet (deterring people <sprinkler>)
* Solenoid valves or something (preliminary image in Anna's notebook)
* Force measurement on bump switch
* LCD box (flexible membrane)
* Adjustable plant system (can the robot and switch system handle the extra weight on the front)
* If they need an adjustable plant system, we can re-work the switch.
* Schedule
* Week 3
* Bump sensor prove (force)
* Customer needs (see above) and Engineering Specs
* Servo evaluation
* Talk to Dr. Walter and try to get a meeting with Stan Rickle
* Week 4
* System level design
* Mechanical Side / Miscellaneous Things that were brought up
* Potted plant - switch questions... is the switch designed to be pressed all the time? Is the button the best idea? Should we use a bump switch? How does it sit in the robot? Can it be switched out? (Yes, it is all bolted in) Should the button be holding the whole weight of the plant?
* Wheels - wheels on the back? - Yes, just not pictured
* What work still needs to be done mechanically? - All the metal is cut for bump sensors, all plant holder stuff is done - just waiting on plexiglass to be cut and put together. Supposed to be on the wheels by early next week (Week 3 - 12/13-12/17) Anticipating trouble putting guards together because of model being a little off, other than that shouldn’t really be any showstoppers.
* What will be left for the two mechanical engineers coming in? - Reevaluate what was done with the sonars to see if there might be something better?
* Independent study - how to collaborate and add the human factor to the robot... the actual plant... could we make it adjustable, the size of the pot... can we change the type of plant? Bumpers - is there another way? These types of discussions for the industrial design folks.
* When should the robot be rolling? - Probably by next Sunday
* Electrical Side
* Monitor and archive things - Archive? How Long?
* Software side - switching from Java to C from past problems
* I2C questions - over my head, wasn’t really sure what was happening here
* i2cget not available for QNX, but open source, and they have headers and software support available - may need to write it ourselves - might be good to go out to the community to find the support, etc. There are guides on how to write the code, but there is some work to do with it.
* There is source level support - worth digging into a bit
* Touch screens - Should we buy them now? Will they fit in the watertight housing? Probably order after we prove that the I2C works
* Is there an LCD that would be for outside use? Can we make it dry? Can we use it for interactivity?
* Touch screen - Phil worked on a team that programmed a touch screen last year, get some flash files from the industrial design folks
* SE - Where do I want my robot to go from all of the information coming up from the sensor data? I have the compass, I have the GPS... etc
* Servos and pings, 50 ms to get an actual ping, fast enough to not really worry about losing the ping
* Sonar problems, talk with someone with more experience to see if there is some kind of issue? The interface may be damaged. Sonars are $100 apiece because of being weather resistant
* Question on sonars - can we just get the Beagleboard to set which degrees it needs in order to make a turn decision
* Figure out the customer needs for each sub-team and which needs have to be done first

===12/17/2010===

* Group integration of ideas/plans/concepts/specifications
* Sonars
* 4 Scanning (side to side), 3 in the front, 1 in the back.
* The three in the front are at different vertical angles
* Move LCD to front of robot for face?
* The 7" LCD if it's waterproofed
* What we've thought of
* Mechanical
* Physical deterrence and flashy lights
* Sprinkler/siren-type lights
* Rain collection system/water collection
* Easy-access for water adding
* Improve sensors
* Work with EE/CE/ME
* Weather proof LCD
* Test bumper
* Good idea
* Adjustable plant holder/placement
* Weight of plant is trivial
* Add more plants?
* Software
* The last week was spent working with the EE team to get a stable QNX image running on the Beageboard. At this point in time it has been determined to stem from incompatibilities between the QNX image type and the firmware running on the Beagleboard. We are currently in the process of trying different versions of software to try to resolve this incompatibility as well as reading through any available documentation we have found on the subject. We hope to have this resolved by the end of week4 but if necessary we will continue through week 5. We will concurrently work on building a design through weeks 4 and 5, having an initial draft for week4 and a revised final design for week 5. Actual development will start in week 6 and likely continue into the opening weeks of the Spring quarter.
* We have also obtained a Windows virtual machine from the Software Engineering department. By the end of Friday of week 3 we will have installed Momentics on this VM. During week 4 we will set up an SVN account within Momentics to act as a dedicated server for our development, and once QNX is running on the Beagleboard we will connect the two environments.
* Customer needs
* Diagnostic mode
* Slinger onto QNX (web browser)
* Electrical/Computer
* Integrate and learn current project "really really well"
* Flashy lights
* Get QNX working
* Work on I2C and sensor information
* Reevaluate sensor information
* Ken is working with Justin a lot
* LCD consult with Terra
* EE=> fit in with other electrical students (get in contact with them)
* Need to be able to test/troubleshoot/etc when other group leaves.
* Sensors/beagle board communications
* detailed design review (information)
* Other
* Higher-level schedule (make)
* with everybody
* inter-related with all groups (EE/CE/ME/SE groups)
* To do
* flush out customer needs specifications
* Anna and Nick met Stan Rickle after the 1pm meeting to ask about the mechanical aspects that were considered
* Sprinkler=good idea
* Make sure not too much water
* Gutter system/water collection
* At home base
* Simplicity is key

===1/7/2011===

* Discussed what needed to be done for 1PM meeting
* Discussed agenda overview
* Nick and Anna worked on concept selection
* Discussed weekly plan
* Discussed SE initial software design
* Change how drawn for personalities
* What pieces are being drawn from all personalities?
* What pieces are specific?
* Discussed rubric/next week
* Customer needs/specs
* Add P11215
* Project plan
* Add transitional plan aspect
* Around weeks 8-11 when they do testing
* Update home page (done)
* Improve sonars
* The view
* Servos work properly (checked by P11215)
* Sonar analog output doesn't work
* QNX
* Default image doesn't work
* Sample image seems to work
* Try on LCD and see if it works; if it doesn't, look at demo image and analyze
* When are we going to decide if it works?
* QNX is easier for software (when it works)
* Personality
* Why is importance low?
* Started earlier, not important yet
* Make personalities easily switchable
* Make one personality at a higher importance
* Apathetic/diagnostic modes are primary personalities
* What tools are available?/ Can you do it?
* Yes, we think so
* How do we define a personality; think/define
* Everybody picks 1 and defines it
* Integrate sonars?
* Or get it to move to show personality
* What do we have to use to define personality?
* If you can think of different a personality, maybe write it down?
* Can we do it now?
* Engineering specs
* Each customer need requires and engineering spec (why have the customer need otherwise)
* Milestone chart
* Good
* P11215=shared
* Plan breakdown structure
* Good
* Strategy on this quarter, testing, hand-off, etc.
* System level review
* New mechanical features
* We have concepts, but haven't settled in yet
* Pick 1, but say we're open to ideas
Use concept feasibility matrix
* Want to be prepared/complete
* Behavior/personality
* Week of thought
* Week of development
* SE overview chart is done
* Personality chart isn't done yet; define framework
* Justin and Ken have I2C working
* I2C can't be verified
* Doesn't work this year
* P11215 can work on it now
* Needs to work
* P11215 needs to get it working on Angstrom then P11216 can get it working (if QNX doesn't work yet, so that something is being done)
* Do 1/2 week 5, 1/2 week 6
* Divide into 3 weeks?
* Week 5
* ME (minus sonar)
* Lower level software (Sensor interaction and MSP430 control)
* Personality framework
* Week 6
* SE personality (detailed)
* Sonars (ME)
* Week 5
* Lower level software (Ken and Rui)
* Sensor interaction
* MSP 430 control
* ME (Anna and Nick)
* Water deterrence
* Adjustable plant holder
* Building Matrix -HOQ
* Personality framework (Team)
* Week 6
* Personalities
* UML chart
* Software
* Sonars
* Hardware development done by end of February
* Software development done by end of March
* Testing done by mid-end of April
* Innovation festival is May 6-8
* Talked to and invited Dr. Walter and Dr. Gomes to next weeks design review
* Asked to attend next week
* Dr. Walter will be there the whole time
* Dr. Gomes can attend from 12:30PM to 1PM
* Dr. Gomes had some suggestions/thoughts (things that gave him red flags)
* Safety on bumper in case it fails
* Moving slowly, but it will still hurt if it runs into somebody
* Have additional safety checks on some things, in case it fails (even though it shouldn't)
* Invite both professors to preliminary design review part 2 during week 6?
* Make sure to include date/time/location in email with the pre-read
* QNX - test to see if it works with the touch screen, and therwise load the demo image into Momentics and fix the video drivers (if possible)
* Make some diagrams to show the personalities. How do we define them? What needs to be captured? Is it motion based or state based?
* Everyone come up with a personality
* Framework for personalities... what can be used to define an actual personality?
* Split up the Deisgn Review into 3 - EE/CE, SE, ME (suggestion)
* I2C - Other team’s responsibility to get the I2C communication working

===1/14/2011 System Level Design Review===

* To develop autonomous robot to maintain health of plant.
* Current group built alarm system in case plant gets stolen
* Our group: work with current group to get robot done by ImagineRIT, debug/test everything, develop software program so it can navigate autonomously
* Robot isn’t completed by the time we’re ready to inherit it
* Prepared to deal with it, but expecting it’s finished
* Two separate drive trains
* Plant care system
* Electrical: IR, battery, electronics
* What robot will look like when it comes time to ImagineRIT
* Explained how Indiana Jones switch works
* Blind spots in sonar field
* Drive train issues
* Robot hurting people?
* Attached bump sensors not working fully
* Working on getting QNX working on BeagleBoard
* Making a lot of progress
* Keeping angstrom up to date as a backup plan, but QNX should work
* Problems with hardware for I2C
* Surfboard it’s on is damaged and needs to be replaced
* While it’s shipping in, started working on MSP430s
* Had about ½ of the sensors going before these teams, and working on getting sensors that aren’t working, working (all of them)
* Parts coming dead on arrival
* Software incompatibility (b/c still working with two operating systems)
* Shouldn’t be too big of an issue anymore

Discussion with people that attended meeting

* Move decision making up to Beagleboard (should we leave MSP430s to do the determination, or can it be done on the Beagleboard? (would be a software re-work to move the decision making up))
* AKA, do we want to commit that time to the software?
* Since 1/2 the sensors aren’t working anymore, might try the time. Big thing is it has to be consistent throughout the team; either all software, or get data from sensors and transfer that to software.
* SE’s have to know how they’re getting the data.
* Sensors work, code doesn’t work.
* Battery
* Light
* Accelerometer
* Sonars have to be reconfigured

Discussion with people that attended meeting done

* Completing testing
* Need integral knowledge of the current robot
* Spent first three weeks learning about the robot
* Improve sonar range and area of vision
* Test bumpers
* Physical deterrence for the alarm (spending most amount of time (mechanical)
* Personalities

Discussion with people that attended meeting

* Other sensors except for bumpers?
* Bump sensors are just for touch
* Sonars are to detect objects.
* Bump sensors are just a fail safe (triple safety)
* Point of the plant?
* Robot has to keep the plant alive
* Idea is that if it can keep the plant alive, it can stay alive
* Plant will alert robot when it’s dying.
* Adjustable plant holder to change plant
* Customer doesn’t want it to be a single plant
* Find optimal conditions for the plant so that it can keep it alive, what are you using?
* Solar panels
* A lot of tests that need to be completed, have any of them been prioritized? (if you can accomplish one thing, then get to the next one)
* We don’t think it’s been addressed in that order, but it’s definitely a good idea

Discussion with people that attended meeting done

* Physical deterrence: water source
* Sensors: can detect when the plant moisture level is low, and when the reservoir is running low

Discussion with people that attended meeting

* Are there any kind of commercial systems they use for growing plants? There might be computerized systems for monitoring the plant.
* In nurseries, they have them on timers.
* Robot needs to be able to survive in all conditions. We don’t want it to drown the plant, so we don’t want it on a timer system
* Future opportunities for computerized systems/other systems for monitoring the plant

Discussion with people that attended meeting done

* Physical deterrence
* 360 degree sprinkler (either vane sprinkler, or a fire sprinkler

Discussion with people that attended meeting

* Chris recommends going with a 180 degree field forward,
* He doesn’t want to necessarily test that on a regular basis (probably a good idea)
* Other sprinkler types
* Installing a shield
* Have you thought of other systems for physical deterrence?
* We were thinking water, because we want it to be self-sustaining.
* We already have the main thing you need for a water deterrent system, so it might be easier (we were thinking that)
* The water is just a second layer of defense, b/c the sound will be a deterrent anyway

Discussion with people that attended meeting done

* Hoping for interaction
* Adjustable plant holder
* Thinking of changing current design, to a mechanical loop
* Our original design was to have various brackets, and find the one you need, this will help will adjusting the side.

Discussion with people that attended meeting

* Dr. Slack thought that they didn’t like the location of the plant and wanted that to vary, Nick thinks that the graduate assistant wanted a varying size for the plant

Discussion with people that attended meeting done

  • Personality framework
* We decided that personality is going to determine how the robot moves, and what it does; therefore diagnostic mode is a personality
* Came up with 8 actions for interactions depending on the personality
* Forward/backward movement
* Leftward/rightward spin
* Sensor servos moving as eyes?
* LCD touch screen (face to show what the robot is “feeling”)
* Alarm system
* Water sprinkler
* 5 basic personalities
* Apathetic (first personality; main one; ignores people for the most part)
* Angry (if plant gets stolen)
* Curious (wants to know more, but doesn’t want to get closer)
* Happy (interactive)
* Super-care (similar to apathetic, but ignores everybody except the plant, and doesn’t really wander)
  • Software design review continues next week for more in depth (because adviser can’t be there next week)
* Software design
* Threading models

Discussion with people that attended meeting

* What are your methods of designing?
* Not pseudo code, as much as different models and sequence diagrams
* Make a prioritized list of what each team is doing (what’s realistic?)
* Big priority=getting QNX working
* The priorities are so straightforward, that there’s really not much to prioritize
  • Other thoughts/ideas
* If you can get it to color, you can have a beacon on the robot to display other colors to show personalities
* Part of what the LCD touch screen is for
*Reposition LCD
* Might want a warning sign about the potential for being sprayed with water
* Are their sound files for the personality maybe?
* Not yet, it’s been talked about.
* Would be nice, but later priority.
* When the robot is all set, will it be running throughout the day/all the time?
* Original thinking is that it’s there to sustain the plant.
* Customer wants curiosity factor and interaction with the people
* Maybe when it got dark, it could go into “sleep mode”
* Industrial design student that’s going to work on a “house” build so that it has somewhere to go to recharge
* If it runs around during the day, it gets busier during the day, maybe integrate a “get out of the way” on the hour
* Maybe integrate a “snow personality”

===1/21/2011 Software System Design Review Meeting===

  • Project Description
* Idea of robot is that it will support a plant. Plant is on the robot and there will be sensors attached on the robot of everything the plant needs to stay alive.
* To give robot a personality for interacting with people.
* Make software for the robot to do all those things is the primary goal.
  • Risks/Customer Needs/Engineering Specs
* Risks
* I2C communication we’ve had a few problems with.
* We’ve had problems with internet access
* Underestimating time needed for development (mitigated with tight schedule)
* Software needs to be in tact on the robot
* Customer Needs
* Needs to stay within a certain area (GPS coordinates)
* Storing sensor input
* Watering the plant
* Make sure it doesn’t run into people
* Personalities

Discussion with people that attended meeting

* QNX is on the board
* No display, but don’t need it
* Want qconn so that remote debugging can be done through qconn
* Holdup is getting network connectivity
* Doesn’t recognize USB dongle to register it on the board
* Is there a fallback?
* Haven’t really thought about it
* Major fallback is to do it through Angstrom instead of QNX
* If everything happens to break and fall apart, we have Angstrom
* Also can use GCC on QNX so there’s at least the image and run it
* Did you try the wireless adapter?
* Wired should come before wireless, trying to establish IP address

Discussion with people that attended meeting done

* Engineering specs
* List of engineering specs that correspond with customer needs (most are binary)
* Bumps into things (not people)
* Number of personality modes
* QNX loaded
* Number of personalities

Discussion with people that attended meeting

* On the bumping, are there other sensors?
* Sonars that are designed to see things far away
* Bump sensors so that it will stop
* If it’s trying to spin the wheels, and they’re not spinning, the robot will stop because it means it ran into something
* Sonar range
* 2’ diameter, 21’ range

Discussion with people that attended meeting done

  • Proposed Design
* Main will initialize the program
* Two threads spawn
* Basic care
* Update every 5-10 minutes
* Waters plant
* Determines some of the personalities (using the plant interpreter)
* Lack of sunlight =super care mode
* Plant gets stolen=angry mode
* Calculate move
* Abstract (basically the brain of the program)
* Utility class is vague
* Meant to assist in what it’s supposed to do (support classes)
* Once move has been calculated, movement gets drawn from movement library, and robot will move

Discussion with people that attended meeting

* “Move” sensors?
* Mechanical parts are what’s being included
* Where’s the interface to the motors?
* Under moveinterpreter
* Boxes are meant to be the actual hardware, and what’s above them is what pulls from the registers
* Calculate move will decide what it wants to do, then calls actual movement command, then the box represents the actual hardware and the motors are told what to do
* What’s the different between things that are primarily input of data, and things that are output of data?
* Alarm and sprinkler are output
* Move, motor control input and output
* Might want to better distinguish
* Move class is the same for all personalities, but the amount depends on the personality
* Might want to put that move abstract (that’s distinguished by personality) into the “personality” box
* “Move” is the actual movement library; it’s the same for all personalities
* Is it on/off, or are there speed personalities
* Right now, the mode is continuously variable (on the controller)
* Will make it stopped and moving
* Might include speed
* “Personality” just tells “move” what it wants to do
* Include more descriptions as to what each of the classes is
* Where are the following personality/movement aspects?
* Navigation
* In movement
* Sensor fusion
* IR
* Sonar
* GPS
* Encoders
* “World Model”
* Where/how to get water?
* How will it get water?
* Where is power management?
* Currently battery is large enough;
* Long range want it to use sonars
* Geo-spacial
* Sun
* Danger (i.e., steep slopes)
* Might not have enough time
* Reach/understand world
* Robot safety and health; people safety and health
* There will always be somebody near it
* Has bump sensors, emergency shut off switches
* Mechanical casing
* Safety and health watchdog
* Sensors aren’t going off for example
* Add package for safety and health
* Backup of the software (basically emergency switch)
* Include descriptions in UML chart

Discussion with people that attended meeting done

  • Use Cases
* Water the Plant
* Will know when to water plant
* Plant gets stolen
* Alarm will go off until somebody deactivates it
* Sprinkler will only go off once
* Switch personalities autonomously
* Depends on position and situations
* Switch personalities manually
* Will be able to be switched from the touch screen
* Apathetic wander
* System will randomly move about within boundaries and avoid obstacles
  • Sequence Diagrams
* Plant care
* Explained the sequence of how plant care will work
* Basic care, plant interpreter, plant sensors, personality controller, and navigation
* Navigation
* Explained how navigation will work (more in depth from previous sequence diagram)
* Personality controller, super care move, navigation interpreter, navigation sensors, move, move interpreter, motors

Discussion with people that attended meeting

* Towards the left more event driven, towards the right, cycle. Is there a response time?
* Expecting sensors will update as often as possible
* Do you know the rates or estimate?
* Depends on the MSP430 and how it’s coded
* Plant is every 20 seconds
* Navigation is every 800ms
* Motor controller hasn’t been looked at lately because it’s moving
* It’s top speed is 0.5mph
* Connection between beagleboard and MSP430 for the wheels it’s serial based, so it’ll be faster. It’s PWM with encoders.
* If the pulse width doesn’t change, it will continue to go.
* If the right side of the sequence diagram goes, will it stop? Or will it continue going (safety)?
* Needs to be getting something from the upper level every second, and if it doesn’t, it should stop
* Implement into MSP430s
* Not software controlled at the moment, so we don’t know
* Define how data flows (protocol) so that we know safety
* Need flow of timing
* Multiple processors? Is it fast enough?
* Make performance protocols
* Meet after meeting to decide

Discussion with people that attended meeting done

  • SE Tentative Schedule
* Going to redesign and finalize schedule and start the development phase this week
* Starting with basic structure, then moving into actual movements and movement patterns.
* Goal is to mostly get general framework done before the end of this quarter, that way all of next quarter can be worked on personalities
* Motors turning on is the “Interpreter/Move library” segment of schedule.
* If stuff gets completed soon, schedule will move up.
* This schedule is truncated and exam weeks/break week is not completed.
* To test, beagleboard is needed, otherwise it is not.

Discussion with people that attended meeting

* Slack would like to get board on robot, and set up with the joystick so that ME’s can get working on that.
* Doesn’t impact SE at all

Discussion with people that attended meeting done

* Testing starts with initial development. As it’s being developed, it’s being tested.
* On robot it will probably start next quarter. It will be local testing for now.
* Simulation environment will probably be built so that robot is not always needed

Discussion with people that attended meeting

*How much can you simulate?
* A chunk. In SE viewpoint, all they’re working with is data, so if they have data, they can simulate it.
* All done on the PC

Discussion with people that attended meeting done

  • Personality Framework
* There were no new personalities, we did some within-team generation, but mostly took ideas from design review last week and tried to implement it.
* Going to add colors somehow to each mood
* First mode is diagnostic mode, then apathetic, and finally angry and all of the other ones.

Discussion with people that attended meeting

* 4 places/coordinates were picked before by team P10218
* Those might need to be redefined now so that it can be confined to a location to observe it better
* GPS has a 2m accuracy
* Maybe let robot remember where it’s been and where it should travel and remember where there was sunlight.
* Was decided that there’s not really a point to have this, except for remembering where home is and maybe some waypoints on the way there.
* GPS coordinates
* Will they be selectable?
* On LCD?
* We want to avoid people randomly coming up and inputting GPS coordinates
* Password protect
* Original thinking would be for simplicity keep it to one set of GPS coordinates. However, it would be very nice to see the robot move with software; that’s the primary task, more complicated things can come later.

Discussion with people that attended meeting done

  • Sonar Placement
* Discussed current design and field of view
* Sonars have a 2’ diameter cone. Takes 2’ to get to it’s full width, and then kind of tapers.
* Current placement doesn’t take advantage of that full beam
* Discussed idea
* Would allow it to see above and below, and to the sides
* Sonar 1 scans in just the front on the bottom
* Sonars 2 and 3 are on corners also scanning up towards the top
* Sonar 4 sweeping in the back (was on a servo always)
* Currently there’s going to be a slight gap between the two, but if we can get a 3’ diameter sonar it would be better.

Discussion with people that attended meeting

* The current sonars are waterproofed, which is why a 2’ diameter one is used
* Would need two more servos to implement this, looking for approval
* They work currently (the servos)
* Software
* As long as it’s giving information, it would be simple
* Wants protocol document (who’s commanding what, who’s receiving)<--Ken
* What it will probably be is using I2C, and giving it number of degrees to move to, and have the MSP430 move it. Ken, define what that is, what data are you sending from a software point. (what’s the MSP430 receiving)
* Mechanically Anna and Nick are doing this if it’s going to be implemented.

Discussion with people that attended meeting done

  • EE/CE status (not part of design review meeting, but still talked about)
* Explained what was working and what wasn’t.
* Servos and Sonars work with some coding still needed

Discussion with people that attended meeting

* Relationship for servos was found by P11215

Discussion with people that attended meeting done

* IR sensors aren’t done yet

Discussion with people that attended meeting

* Do we have enough IR sensors?
* There are 3
* Spare in the bag
* 1 where the pin broke off(is it reparable)
* Order some more
* Dr. Sahin mentioned getting a moving average loop for P11215 so that it can avoid falling off of cliffs

Discussion with people that attended meeting done

* Accelerometer is low priority (don’t know if it’s needed b/c of other stuff)
* Compass is working
* Bump sensors are new, need coding

Discussion with people that attended meeting

* Electrical circuit is all set.
* Needs a place to connect to MSP430s
* Figure out which pin will be used, and let John know.

Discussion with people that attended meeting done

* Battery sensor needs to be double checked
* Water sensor is the water level in the tank;

Discussion with people that attended meeting

* Was removed.
* Last time it sat in water tank and could register water level but didn’t work too well;
* Decided it wasn’t needed because you can see where the level is

Discussion with people that attended meeting done

* Moisture sensor needs coding
* Temperature sensor

Discussion with people that attended meeting

* Has code, ADC values are all wrong
* Tries to convert to actual temperature, but actual values are wrong;
* ADC is working
* Where is it mounted?
* Not sure yet, find a spot and work up harness

Discussion with people that attended meeting done

* Light sensor

Discussion with people that attended meeting

* Doesn’t work too well
* Same state as temperature
* The conversion values of the ADC values are wrong
* Needs a place to be mounted

Discussion with people that attended meeting done

* Alarm is Indiana Jones switch

Discussion with people that attended meeting

  • Other (pre-review)
* Concerned about electronics and that Rui isn’t as involved as she can be
* Need a test plan for EE/Software side
* Going back and using Angstrom?
* Problem with I2C is still a hardware issue
* Work on QNX, but if not, go back to Angstrom
* There’s a UR to USB converter on the board
* If I2C doesn’t work, there’s another backdoor (maybe a frontdoor)
* UR to USB to hub to Beagleboard
* How SE’s get information, it doesn’t matter, as long as information is there.?
* If things don’t happen today, need to start looking at alternatives
* Been in contact with QNX representative. We have functionality, but nothing going to display
* Trying to set up internet(wireless and wired);according to representative, it should just plug in and just work
* Motors on Wandering Ambassador

===1/28/2011 Software Detailed Design Review Meeting===

  • Project Description
* Skipped
  • Sensor Information
* Moisture to
* Water level is no longer used
* Solar/Light (both are being used) to
* Temperature to
* Alarm from
* Sprinkler from
* Water Pump from
* Sonar to
* GPS to
* Infrared Sensor to
* Compass to
* Accelerometer no longer used
* Stop Buttons to
* Bump sensors to
* Indiana Jones switch to
* Sensor servos from
* Motors from
  • Safety Concerns
*Looked into watchdog pattern and updated UML to get separate safety system
* Going to have watchdog pattern, class, or package that will receive heartbeat pulses from threads to either reset the thread, or overwrite what it was supposed to do and tell the robot to stop

Discussion with people that attended meeting

* Does that carry through down to MSP430s?
* Yes. At the moment there’s one class, but there will be more
* There’s one class that’s just for internal software at the moment, but that will change so that it incorporates with MSP430’s as well

Discussion with people that attended meeting done

  • Updated UML Design
* Red lines are for internal software use
* Blue line is for output
* Actual input class will be implementing its own watchdog. We can check to see if the data has changed. It’s almost built into the register to check the heartbeat. The register/thread can be and is reset each time
* Updated to separate out emergency outputs into a separate box and included red and blue lines for safety (watchdog).
* Every sensor will update within 600ms. At top speed, the robot will move 8.8 inches within one second
* Try to get movement sensors to update more regularly
* Stop buttons are strictly hardware
* Bump sensors should go to MSP430s (need software integration)
* If bump sensor gets tripped, or Indiana Jones switch is activated, robot should stop
* Black arrows aren’t implying a data flow, they’re location of dependency. Any time an arrow is located, it represents where things came from

Discussion with people that attended meeting

* Motor as lower level code is okay?
* Yes.
* Is that already implemented?
* Yes. It’s part of the controller code
* How do you do turns?
* 1 forward and 1 backward, or slow one down and keep the other moving, or stop one and keep the other moving.
* Run by PWM
* Needs to be documented as to how to get from code already written for this, to the software engineers
* Wheels moving forward at same speed, but then getting adjusted based on encoder input. You might not be getting the same speed on each encoder. Is there a guarantee that the wheels will move forward at the same speed? And if it’s not, give the SEs a value/difference that they can characterize. We either have to adjust the control algorithms, or fix it at the lower level so that they spin the same.
* Maybe implement a PID controller.
* At the moment, there has been identification that the encoder code needs changing.
* Leaving team should carefully demonstrate that protocol document is true to current team
* CalculateMove is starting to get complicated. Have you started to think about what that looks like architecturally?
* The idea is that it’s in the util class or method. So that if we wanted to do a specific angle, it’s in the util class or method.
* Or have a look-up table. Professor Hawker would recommend getting started on that soon
* What is the relationship between the beagleboard and MSP430s. Haven’t seen that system level diagram

Discussion with people that attended meeting done

* Logic Classes and Sensors Input/ Output is in pre-read but was not discussed
  • Updated Sequence Diagrams
* Heartbeats aren’t incorporated into these diagrams
* Plant Care

Discussion with people that attended meeting

* There’s a 10-20 minute loop because that specific one is checking soil moisture, plant life because they’re not necessary to be checked all the time.
* The exception should be the sunlight, it should be checked more often than every 10-20 minutes (maybe every 1-3 minutes), but the soil moisture is fine at about 20 minutes.
* These are just early guesses, and there is room for modification

Discussion with people that attended meeting done

* If conditions are less than optimal, plant will go into super-care mode
* Navigation
* Starts with the switch to super-care
* Will eventually get to the movement library and updating sensor values.

Discussion with people that attended meeting

* Where do the encoders for the motor fit in?

Discussion with people that attended meeting done

* Triggering the Angry Personality
* Start off with emergency input switches and if they’ve been triggered or not.
* Will then alarm activated or sprinklers activated

Discussion with people that attended meeting

* Who is responsible for the plant being down and getting out of angry mode?
* Probably manual, maybe another trigger which would be the exact opposite of the angry personality trigger.
* Needs to be determined if that’s a manual reset, or on software, maybe have a timer on it?
* Vote is to let it be software (if anything gets put back down, the alarm system turns off)

Discussion with people that attended meeting done


===1/28/2011===

  • Weekly Schedule
* Thorough BOM is for week 9
  • Water Deterrence System—explained what we were thinking for:
* Sprayers
* Pump
* Reservoir
* Before it was a security system that ran off of what we had, but now we’re getting into buying new things completely…
* See how much valves are, that might be better.
  • Adjustable Plant Holder—explained what we’re thinking for:
* Holder
* Additional Plants
* Pot Sizes
  • Sensor status updates
* Not much done, because we’ve been focusing on I2C
* Comes down to level translator circuits not working perfectly
* Beagleboard issue is where the rest of the time has been spent
  • Plant Moisture Sensor and alarm system circuit design were explained
* Make the circuit design so that the schematic matches the layout on the board.
  • For week 9 review
* BOM
* Drawings/Schematics
* SE pictures and images (detailed)
* ME CAD drawings
* CE/EE circuit drawings/schematics
* Feasibility assessment/Risk
* If you can’t do it, say you can’t.
* This is your opportunity to do so
* This project is complex
* Organizational
* Just a complex project
* Get rid of dumb risks
* Testing
* List of major subsystems
* Look at specifications
* Can you measure it or not, and how

===2/4/2011===

  • Discussed DDR and people to invite and meeting times
* If a professor can’t show up to the meeting time, we can reschedule the meeting time and location or do a 1-on-1
  • Discussed what needed to be done for the Detailed design review (Look at samples on MyCourses with a grain of salt)
* Don’t copy and specifications in full, just pick out the key-factors
* Print out and highlight main customer needs and engineering specifications
* Followed by Mechanical drawings (usually best if mechanical information is first, it gets everybody oriented)
* CAD drawings
* Assembly, then parts
* Followed by electrical, computer, software information
* Schematics
* Text
* Updated risks. (keep them technical)
* Appendix
* Things that may come up during the discussion that we don’t want to talk about
* Water squirter
* Feasibility Analysis
* Roll under knowledge and understanding segment
  • Budget
* Not sure how much we have left, need to talk to Chris about that
  • Weekly Status was discussed
* I2C works
* It’s getting hooked up to the board today.
* Power module will be here soon
  • Discussion (Software)
* New castors in back make it harder to rotate the robot
* SEs will need to figure out how well it turns
* Testing to see how well it turns
* Might need to either be redesigned mechanically, or changed in SE to turn it really slowly
* What happens when the robot runs out of water?
* Assume that situation will never occur
* How often do we need to be checking sunlight more than everything else?
* If it’s moving, yes
* If it’s not moving, no
* Actual values currently get updated every 20 seconds
* What are we doing with the data?
* Go into super-care mode
* Map out sequence diagrams for every part for DDR
* Historical sensors are required only for the plant sensors
* By next Friday, all behavior and architecture should be nailed down.
* Probably not going to be challenged, so pick a time
* Big thing is to get data to persist and keep a history
* If robot can stay within at least 1 GPS location, then good.
* Hopefully getting it within four or five
* QNX
* Hasn’t been focused on because there’s no board
* If there’s a way to get the software on the board, there’s no problem no matter what the OS
* Preferable is getting QNX working with the internet
* QNX has nice libraries and is what’s used more often. (more access to assembly languages)
* Not having QNX is not a show-stopper, though it would be nicer if QNX was used instead of something else
  • Discussion (Mechanical)
* Showed adjustable plant holder
* Additional plants
* Use the Plexiglass on the wheels (on the top of that)
* Make sure that the design/technology of the robot can be seen
* Attach chicken wire and use Impatiens as the plants on the chicken wire
* Pump/reservoir
* Valves are expensive
* 2-pump design is better
* Going to look at Pep-Boys for reservoirs/pumps
  • Discussion (Electrical)
* Encoders
* Sonar/Servos
* Need 2 more servo motors
* Sonars are not yet mounted to servos
* Servo-sonars are not on robot (waiting for P11216 to modify them)
* Values from sensors stored in registers
* Demo by P11215 week 10.

===2/11/2011 Detailed Design Review===

  • Project Description Overview
* Majority is to develop software to have it navigate autonomously
* Complete work that P11215 does not complete
* Also adding a few features
* Goal is to have it done by ImagineRIT
  • Mechanical Engineering Aspects
* Customer Needs
* Described our customer needs
* Engineering Specifications
* Described our engineering specifications
* Risk Assessment
* Described our engineering specifications
* CAD Assembly
* Showed CAD
* Also have actual robot
* Sonar layout
* Tried to improve the sonar range
* Explained layout both before and after. (i.e. what was going on before, and what we’re going to do now
* They’re physically the same sensors
* Height changed for the sensors
* Before it was a 3-tier system; now it’s able to see better
* CAD has been changed, but the mounts have not been built yet.

Discussion with people that attended meeting

* Concerns
* Vibrations
* Is there any kind of bearing or something, because it’s going to shake?
* Can make a bracket to hold center of gravity over the robot
* Bearing is built into the servo-board, but it’s a plastic one
* Going to be scanning constantly, is the ribbon cable hanging down again with vibrations; will the cable will be able to take that kind of stress?
* See if there are specifications about the fatigue of the ribbon cable.
* Mechanically it might have to be “beefed” up a little bit.
* Make it, and see how much wiggle there is; and then modify if necessary.
* Might be okay

Discussion with people that attended meeting done

* Water Deterrence System
* Three components
* Sprayers
* Have red LED’s built into them
* Can show that the robot is “angry” or “upset”
* Will also warn visitors.
* Pump
* Using a windshield washer pump
* Reservoir
* Going to have a separate reservoir for the system. So that it can take care of the plant separately from taking care of the plant
* Going to mount below or above

Discussion with people that attended meeting

* Concerns:
* Will it be possible to fill easily?
* Will be mounted so that both can be filled easily
* Size of tank
* Just a car windshield reservoir

Discussion with people that attended meeting done

* Adjustable Plant Holder
* Explained design

Discussion with people that attended meeting

* Concerns
* Vibration
* Use wingnuts or lock washers
* If you had a series of holes, you could put a counterpin through instead.
* Instead of having it threaded, you could just put pins in.
* How is it holding?
* It’s a cantilever beam
* Might not be able to hold up to vibrations and mass of plant when the robot is moving. Make sure to count in to see that it works
* Spacing of the 2-rod side might not be large enough.
* How much does the plant weigh?
* Determine maximum mass of plant and statics of the plant and if the plant holder
* Then determine the dynamics when the robot is moving and vibrating and what that’s going to do.
* Then count in factor of safety of a child hanging off of the front of the robot

Discussion with people that attended meeting done

* Additional Plants
* Described the design and idea
* Nylon webbing
* Better than chicken wire, because of sharp edges cutting into the electrical or injuring people.
* Test Plan
* Described test plan
  • Electrical and Computer Engineering Aspects
* Customer Needs
* Described electrical customer needs;
* Engineering Specifications
* Described engineering specifications
* Risk Assessment
* Described risks
* Are there any heat generation issues that we have to worry about?
* Voltage regulation was an issue; stepping it down was an issue
* Solution was found, is now working okay
* Heat issue in the box is not an issue
* What happens if the fan should fail?
* Not yet; Need to look into it
* More of an issue because the WA is going to be in direct sunlight
* The sun is going to heat up the robot, and things are going to stop working
* Might need to get a temperature sensor to monitor the temperature of the robot itself when it’s out under the sun
* Add three more temperature sensors to monitor the temperature (look into to see if we need to add it)
* Shouldn’t be too difficult to implement.
* Are the bearings sealed?
* The motor definitely is, not certain about the bearings
* The wheels are getting ventilation.

Discussion with people that attended meeting done

* Sonar Servos
* Explained the sonar system and circuit
* Hasn’t actually been implemented; Should be done next week
* Bump Sensor
* Described bump sensor system and circuit

Discussion with people that attended meeting

* Initially were planning to have two bump sensors, decided to get rid of the sensor in the back because of cost.
* Generates a risk
* What’s the isolator on the on board system.
* Principally they’re the on board and the circuit diagram are the same, they just look smaller

Discussion with people that attended meeting

* Moisture Sensor
* Described moisture sensor

Discussion with people that attended meeting

* Looking at the data; range should be from 3V down to 0 V…it seems to saturate at 1.5V, why doesn’t it go up all the way?
* Rui thinks it’s because that means for pure water
*Look at the specification sheet
* Doesn’t look linear
* Put into pure water to test. (hopefully that’s the reason)
* Put a volt-meter right across the moisture sensor as well to see if maybe the ADC isn’t working
* Weren’t using an ADC when measuring

Discussion with people that attended meeting done

* Solar Panel
* Described solar panel circuit

Discussion with people that attended meeting

* What’s the voltage specification?
* Worried that if it’s putting out any voltage, it will pop the LEDs
* Was tested using maximum current and maximum voltage
* Hunch is that the LEDs won’t hold up to the voltage of the sunlight
* Put resistors in line with all of the LEDs
* Put a zener where the resistor currently is (or a diode)
* Get bigger LEDs so that they light up
* Get book and see what’s recommended for the circuitry for the solar panels and LEDs to make sure that the LEDs will not break
* Throw away the on-board diagram; because it looks like a schematic, but it’s not. Fix it so that we know it’s not a schematic and it’s how things are soldered.

Discussion with people that attended meeting done

* “Indiana Jones” Switch
* Described “Indiana Jones” switch circuit panel.
* Emergency Stop Buttons
* Described the emergency stop buttons
* Beagleboard/MSP430 Communication
* Explained the beagleboard/MSP430 communication
* Beagleboard can get data whenever it wants
* When the flag gets set, beagleboard knows that it has to pull the data
* Time is still TBD regarding the heartbeat; will probably be a second or two
* Need to wait until the software is done before setting the time for the heartbeat
* Test Plan
* Described test plan
* Only thing that’s changed since the last group is the sonars

Discussion with people that attended meeting

* How long does the sonar have to be set in one spot before it can take an image, or does it happen instantaneously?
* Pretty much instantaneously
* Will move in sequence with the robot so that they move not simultaneously
* Sit down and test the sonar/servos to see what data we’re getting at the moment.
* Analog side was working well; Which was the plan all along
* Make sure all 4 sonars are functioning properly and the range that you can get accurately
* Before, as long as it was larger than 1ft, and less than 20ft it was okay.
* Determine what happens if somebody or something is near it
* Test all four again.
* Why does only one turn on at a time?
* Worried about mix-of communication when multiple are on
* Other Comments/Questions
* Rui: Look at the sonar, and gain familiarity with it
* Find out how they work
* Were having problems with the analog, but now everything works. (Ken looked at it) and will own it.
* GPS owned by SEs
* Electronic Compass is owned by Ken as well
* Rui or Ken need to own Battery; might be the responsibilities of SEs
* LCD might be getting used? Responsibility of the SEs if it is. Would be nice because it would allow us to know if the robot needs to be charged at the end of the day without hooking it up to a voltmeter each time.

Discussion with people that attended meeting done

  • Software Engineering Aspects
* Customer Needs
* Described customer needs (QNX, Navigation, Personality specifically)
* QNX will probably not work out; going to use Angstrom
* Same functionality, but will just be a little bit harder to transfer the programs.

Discussion with people that attended meeting

* What happens if device is travelling on terrain, (concave down and concave up)? What will happen with the robot due to that little bit of a dip?
* Bump sensors are height adjustable
* Their specific height was picked because you don’t want the robot to run over people’s feet.
* Also, robot is going to be in a static terrain that will be picked specifically so that this situation does not occur.

Discussion with people that attended meeting

* Engineering Specifications
* Described engineering specifications (personalities, not bumping into people, not falling off ledges specifically)
* Risk Assessment
* Described risk assessment
* Two of them are based on QNX. It was decided today that QNX isn’t going to be used, so those are no longer risks
* I2C is working, so that is no longer a risk
* Design
* Described design and a few small changed
* Labeled what’s going to be serial communication versus registers.
* Made it more detailed
* Class Descriptions
* Were not really described since they can be read.
* Pseudo-code Examples
* Described pseudo code
* Movement library
* Described what the movement library is and does

Discussion with people that attended meeting

* What if you wanted it to go slower or faster?
* If you wanted to go slower, there are three methods that would allow the speed to be changed and adjusted accordingly.
* There’s direction, speed, and encoders. Do the encoders fit in?
* Not into the movement library, they go into “calculate move”
* When pseudocode was made, it was assumed that when you send the wheels a value, they will both be using the same one
* What does the course correction?
* Mostly sonar and IR, and the bump sensor
* Do you know what the delay is for the right wheel and left wheel and how long it will take to actually make the turn?
* Has not been thought about yet.
* Maybe possible to set it together for both wheels, instead of separating them to hopefully move both wheels together
* Code was based off of the protocol

Discussion with people that attended meeting done

* Apathetic Wander
* Described how apathetic wander works
* Where is decision making made?
* At the end of the loop. There’s going to be a randomness code at the end of it.
* It will obviously stop and turn if it runs into the “GPS corral”
* Do a use case of the robot just wandering
* The sequence events are interesting
* Imagine you were in a room and had to figure out where to go; then put a blindfold on; you’ll become very aware of your senses and where you have to go.
* This will hopefully help you get the wandering and movement of the robot better.
* Movement of the robot has to be very methodical
* How much of personalities do you actually need to start programming?
* Not much. We can start programming now; getting it detailed and broken down will be done later.
* For schedule during week 10;
* Parse out who’s doing what, when
* Also determine the “methodical” movement that Dr. Kempski mentioned above. (Maybe, move a foot. Stop. Look around. Move another foot, repeat. Or something like that)
* If the robot can walk forward one foot on its own, we’re all going out to drink.

Discussion with people that attended meeting done

* Important Board Specifications
* Were not discussed
* Data Persistence
* Discussed data persistence

Discussion with people that attended meeting

* It’s a good addition.
* Play the depth by ear
* What about uploading the data to the web?
* The most important factor right now is to get the data. After that we can focus on uploading it to the web

Discussion with people that attended meeting done

* Polling (Hardware/Software Interaction)
* Discussed polling
* Want to move as much decision making as we can to leave the beagleboard.
* At the moment just saying what we want, when we get to the point will make it more detailed
* There’s a watchdog heartbeat and a hardware/software interaction heartbeat.

Discussion with people that attended meeting

* Other Comments/Questions
* Ken, when you pick up the MSP430s, what are you expecting to see if you want the robot to move straight (move both motors ahead at ½ speed)
* Shouldn’t be too difficult to control the two motors together.
* Are you guys using the encoders?
* That’s the plan for now
* The MSP430s would handle the encoders and then send it out.
* How long can the battery last?
* More than 8 hrs
* MSP430s have a low power mode that they automatically go into.
* Draws a constant 500mA; in pulse mode hasn’t been measured
* Measure the mAH that are drawn from the battery when the robot is moving
* Were the encoders looked at?
* Yes.
* Inverted value of RPM would be sent to the beagleboard;
* At MSP430 level, the time between each rotation will be clocked and stored in registers (series or one that gets refreshed every time?)
* Something to think about
* Is distance traveled that critical? You’re assuming that you’re rolling without slipping. Do you really want to keep track of the linear distance traveled?
* More important is the speed, and not displacement.
* How accurate is the GPS? Because you’re working within the resolution of the GPS.
* Work out a few scenarios and test them
* Encoders: At the wheels, what’s being measured?
* Voltage at degree of rotation
* What’s being done with the voltage?
* Detect the time it takes between taking 5 volts and the next time it reaches 5 volts.
* So you’re constantly doing ADD conversions?
* No, you can set an interrupt so that when it reaches 5 Volts, it can stop and start going up to 5 Volts again
* That’s a problem, because you might not reach that interrupt again and then the values you’re getting are incorrect.
* You might not even need the encoders, because the gear down is just so large that they might not be required. You have too much torque.
* One of the points of the encoders is to time the safety system if it’s not stopping. In case something fails.
* Especially because there’s no bumper on the back. (it’s too expensive)
* Is it ever going to happen that the wheels will be not moving when they should?
* No
* Is there a chance of something coming across and getting stuck in the robot?
* Yes, but, it’s not large, and even if the “halo” gets completed there’s always a chance of something getting stuck under the robot
* With the no bump sensor in the back, there’s a huge safety concern.
* You don’t necessarily need a bump sensor like that, there are other methods of getting bump sensors that will retain the safety

Discussion with people that attended meeting done

  • Bill of Materials
* Discussed BOM

Discussion with people that attended meeting

* Instead of the stock aluminum,
* P11215 has a 12” by 12” by 1” piece of ABS that we can use
* Get two pumps and reservoirs instead of one, and just replace the one that’s currently in the robot.
* Is better because there is more variation and opening for the amount of space available.
* Make sure the nozzles are being regulated, because they have a lot of pressure and distance on them.

===2/21/2010===
  • Weekly plan breakdown (last quarter)
* Reviewed what we did this past quarter
* Plant holder is going to be cut because of budget concerns
* But will still do the work
* Want to get everything done by early April
* Talked about what’s currently happening to get data to SEs
* SEs might be able to get robot to move forward 1 foot
* LCD works with an image. It registers as a touch panel and reacts to touches. But it’s not calibrated yet. (need to find the right driver)
* Relatively lower priority; because navigation is a higher priority (planned for week 5 or 6 next quarter)
* Only concerns with integration: files at P11215 page and other pages access to their EDGE pages
  • Reviewed current MSD2 plans
* Nick and Anna-more fabrication
* Nick and Anna-work with Terra regarding growth of additional plants
* Rui-taking charge of electrical stuff; sensors; wiring; testing; etc
* Meeting for electrical on Tuesday 1130-1230;
* Meeting for software on Friday 1230-130
* Ken-working on finishing up loose ends and testing
* SE guys-”Do everything.”
* Internal goals are in Joe’s notebook
* Got a table/booth at ImagineRIT
* Decide what we want to do. (might be day-of decision)
* Live feed if it’s outside
  • Risks
* All risks still valid
* Add risk for P11215 not completing their deliverables
  • Action Item list from DDR
* Everybody has ownership of action items

Home | Project Summary | Team Values and Norms | Engineering Specifications | Weekly Status Report | Milestone Chart | Plan Breakdown Structure | Risk Management | Mechanical Engineering Concept Selection | Customer Needs