Team Three/Journal/Jan5

Today we discussed our approach to the game at a high level, decided deadlines, assigned subgroups. We also mocked up some ideas we had using cardboard, pencils, and tape to get an idea of what's easy to do and what's not so easy to do.

Contents 1 Planning Meeting 1.1 HARD DEADLINES 1.2 Approach to game: 1.3 How to complete the task: 1.4 Divide up robot building: 1.4.1 Prototype design 1.4.2 Electrical / mechanical / CAD 1.4.3 Software 1.5 Software notes: 1.5.1 Coding workflow notes: 1.6 Electrical 2 Mock-up report

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.
• probably won't be using to "spear" the cubes. too hard.
• will use pancake method, probably

what sensors are we using (IR for color and sonar for distance?

• IR for both? Let's have at least 2-3x for redundancy)
  • IR doesn't do color, it does distance - EM

Divide up robot building:

Prototype design

• All

Electrical / mechanical / CAD

• EM
• LAZ

Software

• PS
• GW
• SCF
• 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)

Mock-up report

We made some mock-ups of ideas that we had for picking up the cubes. We used pencils to simulate "spears" that could pick up cubes via the holes. We found that it takes too much accuracy to correctly thread the pencils through the hole. We made a "pancake" mechanism with cardboard (two pieces of cardboard pivoted at one end) and found that it worked pretty well.