Team Three/Journal/Jan5
From Maslab 2015
Contents |
1/5: Planning Meeting
HARD DEADLINES
- Determine specific hardware parts (motors, shields, etc) by 1/7
- Write simple-to-use-later functions for reading all sensors by 1/7
- Write simple-to-use-later functions for controlling all motors by 1/7
- CAD every part of the robot by 1/9
- Initial workingish prototype by 1/14
- Have autonomous code for the prototype by 1/16
- Finish actual robot (mechanical portion) by 1/21
- Finish debugging and testing everything by 1/28
Approach to game:
figure out the game task that maximizes points while minimizing difficulty (ie which area is best to stack in) - do ground stacks (no middle stacks) pick one task: build stacks no greater than three blocks tall?
How to complete the task:
what’s the robot’s “game plan” (what steps does it have to take to complete chosen game task) what sort of block handling mechanism (bhm) should we use - we’ll test this what sensors are we using (IR for color and sonar for distance? IR for both? Let's have at least 2-3x for redundancy)
Divide up robot building:
Electrical / mechanical - EM, LAZ Software - PS, GW, EM (I will help with embedded/microcontroller pin-based stuff (interrupts, GPIO, interfaces etc.) but won’t focus on it. Also I’m good at reading datasheets.)
Software notes:
- We should have a projected path to follow at all times. More specifically, we always need a direction, velocity, and action. By action, I mean doing anything other than picking up the blocks.
- We should have cases to handle failing sensors. We need enough sensors to back up failing ones.
- We should make the code for the sensors and stuff really modular. Sensor handling should happen in different files than path planning, for instance.
- C++ is good for this right? - EM
- Agreed -PS
Coding workflow notes:
- remember to branch from master when working on a new feature D: (“keep master clean”)
- oh man use tags
Electrical
- isolate all power supplies!! (use their DC/DC converters)
