https://wiki.robojackets.org/api.php?action=feedcontributions&feedformat=atom&user=MarkspRoboJackets Wiki - User contributions [en]2026-04-09T15:36:41ZUser contributionsMediaWiki 1.32.0https://wiki.robojackets.org/index.php?title=User:Marksp&diff=8309User:Marksp2009-09-09T02:17:17Z<p>Marksp: </p>
<hr />
<div>{| id="go" style="color: #ffffff; width:12em; margin:0 0 0.5em 1em; float: right;"<br />
!align="center" bgcolor="#808080" colspan="3"|[[image:phillip.jpg]]<br />
|}<br />
====Phillip Marks====<br />
*Phone: 770-315-8653<br />
*Email: phillip.marks@gatech.edu<br />
*Location: Los Angeles<br />
*Projects: Working for JPL helping to put craters on other planets</div>Marksphttps://wiki.robojackets.org/index.php?title=User:Marksp&diff=8308User:Marksp2009-09-09T02:15:49Z<p>Marksp: </p>
<hr />
<div>{| id="go" style="color: #ffffff; width:12em; margin:0 0 0.5em 1em; float: right;"<br />
!align="center" bgcolor="#808080" colspan="3"|[[image:phillip.jpg]]<br />
|}<br />
====Phillip Marks====<br />
*Phone: 770-315-8653<br />
*Email: phillip.marks@gatech.edu<br />
*Projects: Putting craters on other planets</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8167Proposals2009-07-28T20:55:26Z<p>Marksp: /* Changes, Deadlines, and Penalties */</p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
A preliminary proposal may be asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project. Clear, concise objectives help keep a team focused without pulling the development in too many directions at once. Abstract, far reaching objectives are discouraged as they are hard to fully satisfy and give the team no clear direction. The best objectives focus in on each aspect of the project, and provide detail about what the expectations, such as performance and ease of use, will be for those aspects. Finally, the objectives shouldn't enumerate specific tasks. There should be at least 1 primary objective and 2 secondary objectives. Secondary objectives are defined as something that if not met will not prevent the project from failing to compete.<br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them.<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
##"Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
## "Design a manipulator that penetrate six inches of earth for the science task and has minimal size and power requirements" - Much better. Everything is spelled out and the objectives for the manipulator, though general are given. One can use this objective to really guide a design.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
====Milestones Example====<br />
* Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* After fall break - Demo at least 2 new prototype drive-trains<br />
* Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, <br />
* Feb 1st - Demo new manipulator using individual joint control<br />
* March 1st - Extended range driving<br />
* Spring Break - Demo some of the competition tasks using the manipulator<br />
* April 30th - Finalize travel plans, demo robot performing some competition objectives<br />
<br />
===Resources===<br />
Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br />
<br />
====Monetary====<br />
This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br />
<br />
====Personnel====<br />
Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br />
<br />
====Capital Outlays/Tooling====<br />
While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources that will be needed to manufacture parts and should list those resources here.<br />
<br />
====Travel/Registration====<br />
In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following<br />
<br />
* Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.<br />
* Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos<br />
* Luggage for the robot<br />
* Shipping for the robot<br />
* Fees - Excess baggage, duties, <br />
<br />
In addition the proposal should state the anticipated cost for travel per member. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees.<br />
===Schedule===<br />
The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one. <br />
<br />
There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here:http://live.gnome.org/Planner)<br />
===Budget===<br />
The budget contains details on the cost to build the robot and should provide sufficient detail. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go along way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. For an example budget see the 2009-2010 SGA budget. Capital outlays (items that can reasonably get more than a year of use) shouldn't be on the budget. <br />
<br />
===Supplemental Documentation===<br />
Any documentation that the team leader feels is required in addition to the above<br />
<br />
==How funding works==<br />
==='''Important'''===<br />
=== Overview ===<br />
In the past project budgets were set at the beginning of the year with the entire budget for each team be allocated in one step. This year teams will have their budgets allocated in phases based on development the milestones they have specified. Not all milestones define a separate phase though but all phases will culminate with some milestone. It is '''required''' that teams at least have a '''design and and build phase''' with the milestone for the design phase being a successful design review. The design review shall be arranged by the team leader, the officers, and interested parties. Interested parties shall include all parties recognized by the officers and team leaders. <br />
<br />
===Milestones and Partial Completion===<br />
Milestones for projects are the milestones and the final travel deadline. Completion of a milestone will be defined by the milestone itself. Partial completion of milestones will be defined by the officers and other interested parties with the input of the team leader. The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only. <br />
<br />
=== Penalities ===<br />
Failure to meet a milestone will result in the team losing out on additional funding until they have either completed the milestone or made satisfactory progress towards the milestone. Satisfactory progress will be defined by the officers and other parties in with input from the team leader and will take into account external factors such as vendor related issues.<br />
<br />
===Changes===<br />
Changes can be made to any deadline pending officer approval. The criteria for approval are:<br />
<br />
* Time till deadline in question<br />
* Progress made<br />
* External factors<br />
<br />
Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests. <br />
<br />
=== Changes vs. Partial Completion ===<br />
It is understood that problems will arise along the way (Robotics is still very much a research field). As such team leaders have several options when their projects come into unexpected problems. Change request are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu no additional stress is placed on the members by having to continue to work to meet a new deadline.<br />
<br />
=== Authority ===<br />
The authority to approve funding rest solely with the officers. Team leaders, and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br />
<br />
In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. In no instance can an officer create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable event in which an officer can have any leadership of a team is if appointed by a team leader or if there are no members to take lead of project.<br />
<br />
==Procedure for Submission==<br />
The proposals are due at 11:59 on the 8/1. They should contain all the sections mention above be in 12pt font, double-spaced, and printed on one side only. The budget should be submitted electronically as a separate excel spreadsheet. It should also be attached to the hard copy. Once all the proposals are in the budget can be made up and then disbursed along with recommendations from the officers and the advisers.</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8166Proposals2009-07-28T20:38:40Z<p>Marksp: /* Project Description */</p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
A preliminary proposal may be asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project. Clear, concise objectives help keep a team focused without pulling the development in too many directions at once. Abstract, far reaching objectives are discouraged as they are hard to fully satisfy and give the team no clear direction. The best objectives focus in on each aspect of the project, and provide detail about what the expectations, such as performance and ease of use, will be for those aspects. Finally, the objectives shouldn't enumerate specific tasks. There should be at least 1 primary objective and 2 secondary objectives. Secondary objectives are defined as something that if not met will not prevent the project from failing to compete.<br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them.<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
##"Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
## "Design a manipulator that penetrate six inches of earth for the science task and has minimal size and power requirements" - Much better. Everything is spelled out and the objectives for the manipulator, though general are given. One can use this objective to really guide a design.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
====Milestones Example====<br />
* Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* After fall break - Demo at least 2 new prototype drive-trains<br />
* Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, <br />
* Feb 1st - Demo new manipulator using individual joint control<br />
* March 1st - Extended range driving<br />
* Spring Break - Demo some of the competition tasks using the manipulator<br />
* April 30th - Finalize travel plans, demo robot performing some competition objectives<br />
<br />
===Resources===<br />
Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br />
<br />
====Monetary====<br />
This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br />
<br />
====Personnel====<br />
Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br />
<br />
====Capital Outlays/Tooling====<br />
While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources that will be needed to manufacture parts and should list those resources here.<br />
<br />
====Travel/Registration====<br />
In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following<br />
<br />
* Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.<br />
* Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos<br />
* Luggage for the robot<br />
* Shipping for the robot<br />
* Fees - Excess baggage, duties, <br />
<br />
In addition the proposal should state the anticipated cost for travel per member. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees.<br />
===Schedule===<br />
The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one. <br />
<br />
There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here:http://live.gnome.org/Planner)<br />
===Budget===<br />
The budget contains details on the cost to build the robot and should provide sufficient detail. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go along way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. For an example budget see the 2009-2010 SGA budget. Capital outlays (items that can reasonably get more than a year of use) shouldn't be on the budget. <br />
<br />
===Supplemental Documentation===<br />
Any documentation that the team leader feels is required in addition to the above<br />
<br />
==Changes, Deadlines, and Penalties==<br />
=== Proposed ===<br />
In years past teams have found it hard to meet self imposed deadlines, resulting in lopsided development schedules. In addition, member retention has been an issue as new members often leave during lulls in the development, indicating that 'not much was going on'. To address these concerns and to help the club be more successful in its endeavors, there are new rules regarding milestones. <br />
<br />
<br />
====Applicable deadlines====<br />
Deadlines for projects are the milestone deadlines and the final travel deadline. For milestone deadlines even partial completion is okay as long as prior notice is given. Partial completion though means significant progress has been made towards completing the milestone. For example if the milestone is to demonstrate tele-op driving, but the wheels haven't come in by the deadline then even showing that the motors turn in response to tele-op commands is sufficient. On the other hand passing a frame off as completion of the deadline is unacceptable unless all the other components are being shipped/made and haven't arrived. <br />
<br />
The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only. <br />
<br />
====Changes====<br />
Changes can be made to any deadline pending officer approval. The criteria for approval are:<br />
<br />
* Time till deadline in question<br />
* Progress made<br />
* External factors<br />
<br />
Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests. <br />
==== Penalties ====<br />
If a team misses a milestone that team's leader must be prepared to meet with the officers and the team's adviser to discuss plans moving forward. Those plans should include a new schedule, milestones, and objectives if necessary. The deadline for arranging this meeting is 7 days after the deadline. If a team leader fails or objects to attending such a meeting, their budget will be frozen until such a meeting takes place. Furthermore, any travel arrangements will be effectively put on hold and no new travel plans can be made. If a team remains in this state of limbo for significant time the officers will taken further action including but not limited to the removal of the team leader per policy and possibly the disbandment of the team per the constitution.<br />
<br />
==== Changes vs. Partial Completion ====<br />
It is understood that problems will arise along the way (Robotics is still very much a research field). As such team leaders have several options when their projects come into unexpected problems. Change request are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu no additional stress is placed on the members by having to continue to work to meet a new deadline.<br />
<br />
==== A note on authority ====<br />
In general the officers can only ''enforce'' the deadlines and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders come up with. In no instance can an officer create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable event in which an officer can have any leadership of a team is if appointed by a team leader or if there are no members to take lead of project.<br />
==Procedure for Submission==<br />
The proposals are due at 11:59 on the 8/1. They should contain all the sections mention above be in 12pt font, double-spaced, and printed on one side only. The budget should be submitted electronically as a separate excel spreadsheet. It should also be attached to the hard copy. Once all the proposals are in the budget can be made up and then disbursed along with recommendations from the officers and the advisers.</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8165Proposals2009-07-28T20:38:10Z<p>Marksp: /* Procedure for Submission */</p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
A preliminary proposal may be asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those objectives, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project. Clear, concise objectives help keep a team focused without pulling the development in too many directions at once. Abstract, far reaching objectives are discouraged as they are hard to fully satisfy and give the team no clear direction. The best objectives focus in on each aspect of the project, and provide detail about what the expectations, such as performance and ease of use, will be for those aspects. Finally, the objectives shouldn't enumerate specific tasks. There should be at least 1 primary objective and 2 secondary objectives. Secondary objectives are defined as something that if not met will not prevent the project from failing to compete.<br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them.<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
##"Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
## "Design a manipulator that penetrate six inches of earth for the science task and has minimal size and power requirements" - Much better. Everything is spelled out and the objectives for the manipulator, though general are given. One can use this objective to really guide a design.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
====Milestones Example====<br />
* Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* After fall break - Demo at least 2 new prototype drive-trains<br />
* Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, <br />
* Feb 1st - Demo new manipulator using individual joint control<br />
* March 1st - Extended range driving<br />
* Spring Break - Demo some of the competition tasks using the manipulator<br />
* April 30th - Finalize travel plans, demo robot performing some competition objectives<br />
<br />
===Resources===<br />
Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br />
<br />
====Monetary====<br />
This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br />
<br />
====Personnel====<br />
Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br />
<br />
====Capital Outlays/Tooling====<br />
While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources that will be needed to manufacture parts and should list those resources here.<br />
<br />
====Travel/Registration====<br />
In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following<br />
<br />
* Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.<br />
* Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos<br />
* Luggage for the robot<br />
* Shipping for the robot<br />
* Fees - Excess baggage, duties, <br />
<br />
In addition the proposal should state the anticipated cost for travel per member. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees.<br />
===Schedule===<br />
The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one. <br />
<br />
There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here:http://live.gnome.org/Planner)<br />
===Budget===<br />
The budget contains details on the cost to build the robot and should provide sufficient detail. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go along way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. For an example budget see the 2009-2010 SGA budget. Capital outlays (items that can reasonably get more than a year of use) shouldn't be on the budget. <br />
<br />
===Supplemental Documentation===<br />
Any documentation that the team leader feels is required in addition to the above<br />
==Changes, Deadlines, and Penalties==<br />
=== Proposed ===<br />
In years past teams have found it hard to meet self imposed deadlines, resulting in lopsided development schedules. In addition, member retention has been an issue as new members often leave during lulls in the development, indicating that 'not much was going on'. To address these concerns and to help the club be more successful in its endeavors, there are new rules regarding milestones. <br />
<br />
<br />
====Applicable deadlines====<br />
Deadlines for projects are the milestone deadlines and the final travel deadline. For milestone deadlines even partial completion is okay as long as prior notice is given. Partial completion though means significant progress has been made towards completing the milestone. For example if the milestone is to demonstrate tele-op driving, but the wheels haven't come in by the deadline then even showing that the motors turn in response to tele-op commands is sufficient. On the other hand passing a frame off as completion of the deadline is unacceptable unless all the other components are being shipped/made and haven't arrived. <br />
<br />
The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only. <br />
<br />
====Changes====<br />
Changes can be made to any deadline pending officer approval. The criteria for approval are:<br />
<br />
* Time till deadline in question<br />
* Progress made<br />
* External factors<br />
<br />
Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests. <br />
==== Penalties ====<br />
If a team misses a milestone that team's leader must be prepared to meet with the officers and the team's adviser to discuss plans moving forward. Those plans should include a new schedule, milestones, and objectives if necessary. The deadline for arranging this meeting is 7 days after the deadline. If a team leader fails or objects to attending such a meeting, their budget will be frozen until such a meeting takes place. Furthermore, any travel arrangements will be effectively put on hold and no new travel plans can be made. If a team remains in this state of limbo for significant time the officers will taken further action including but not limited to the removal of the team leader per policy and possibly the disbandment of the team per the constitution.<br />
<br />
==== Changes vs. Partial Completion ====<br />
It is understood that problems will arise along the way (Robotics is still very much a research field). As such team leaders have several options when their projects come into unexpected problems. Change request are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu no additional stress is placed on the members by having to continue to work to meet a new deadline.<br />
<br />
==== A note on authority ====<br />
In general the officers can only ''enforce'' the deadlines and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders come up with. In no instance can an officer create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable event in which an officer can have any leadership of a team is if appointed by a team leader or if there are no members to take lead of project.<br />
==Procedure for Submission==<br />
The proposals are due at 11:59 on the 8/1. They should contain all the sections mention above be in 12pt font, double-spaced, and printed on one side only. The budget should be submitted electronically as a separate excel spreadsheet. It should also be attached to the hard copy. Once all the proposals are in the budget can be made up and then disbursed along with recommendations from the officers and the advisers.</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8025Proposals2009-06-30T17:59:11Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
A preliminary proposal may be asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those objectives, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project. Clear, concise objectives help keep a team focused without pulling the development in too many directions at once. Abstract, far reaching objectives are discouraged as they are hard to fully satisfy and give the team no clear direction. The best objectives focus in on each aspect of the project, and provide detail about what the expectations, such as performance and ease of use, will be for those aspects. Finally, the objectives shouldn't enumerate specific tasks.<br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them.<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
##"Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
## "Design a manipulator that penetrate six inches of earth for the science task and has minimal size and power requirements" - Much better. Everything is spelled out and the objectives for the manipulator, though general are given. One can use this objective to really guide a design.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
====Milestones Example====<br />
* Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* After fall break - Demo at least 2 new prototype drive-trains<br />
* Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, <br />
* Feb 1st - Demo new manipulator using individual joint control<br />
* March 1st - Extended range driving<br />
* Spring Break - Demo some of the competition tasks using the manipulator<br />
* April 30th - Finalize travel plans, demo robot performing some competition objectives<br />
<br />
===Resources===<br />
Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br />
<br />
====Monetary====<br />
This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br />
<br />
====Personnel====<br />
Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br />
<br />
====Capital Outlays/Tooling====<br />
While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources that will be needed to manufacture parts and should list those resources here.<br />
<br />
====Travel/Registration====<br />
In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following<br />
<br />
* Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.<br />
* Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos<br />
* Luggage for the robot<br />
* Shipping for the robot<br />
* Fees - Excess baggage, duties, <br />
<br />
In addition the proposal should state the anticipated cost for travel per member. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees.<br />
===Schedule===<br />
The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one. <br />
<br />
There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here:http://live.gnome.org/Planner)<br />
===Budget===<br />
The budget contains details on the cost to build the robot and should provide sufficient detail. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go along way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. For an example budget see the 2009-2010 SGA budget. Capital outlays (items that can reasonably get more than a year of use) shouldn't be on the budget. <br />
<br />
===Supplemental Documentation===<br />
Any documentation that the team leader feels is required in addition to the above<br />
==Changes, Deadlines, and Penalties==<br />
=== Proposed ===<br />
In years past teams have found it hard to meet self imposed deadlines, resulting in lopsided development schedules. In addition, member retention has been an issue as new members often leave during lulls in the development, indicating that 'not much was going on'. To address these concerns and to help the club be more successful in its endeavors, there are new rules regarding milestones. <br />
<br />
<br />
====Applicable deadlines====<br />
Deadlines for projects are the milestone deadlines and the final travel deadline. For milestone deadlines even partial completion is okay as long as prior notice is given. Partial completion though means significant progress has been made towards completing the milestone. For example if the milestone is to demonstrate tele-op driving, but the wheels haven't come in by the deadline then even showing that the motors turn in response to tele-op commands is sufficient. On the other hand passing a frame off as completion of the deadline is unacceptable unless all the other components are being shipped/made and haven't arrived. <br />
<br />
The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only. <br />
<br />
====Changes====<br />
Changes can be made to any deadline pending officer approval. The criteria for approval are:<br />
<br />
* Time till deadline in question<br />
* Progress made<br />
* External factors<br />
<br />
Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests. <br />
==== Penalties ====<br />
If a team misses a milestone that team's leader must be prepared to meet with the officers and the team's adviser to discuss plans moving forward. Those plans should include a new schedule, milestones, and objectives if necessary. The deadline for arranging this meeting is 7 days after the deadline. If a team leader fails or objects to attending such a meeting, their budget will be frozen until such a meeting takes place. Furthermore, any travel arrangements will be effectively put on hold and no new travel plans can be made. If a team remains in this state of limbo for significant time the officers will taken further action including but not limited to the removal of the team leader per policy and possibly the disbandment of the team per the constitution.<br />
<br />
==== Changes vs. Partial Completion ====<br />
It is understood that problems will arise along the way (Robotics is still very much a research field). As such team leaders have several options when their projects come into unexpected problems. Change request are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu no additional stress is placed on the members by having to continue to work to meet a new deadline.<br />
<br />
==== A note on authority ====<br />
In general the officers can only ''enforce'' the deadlines and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders come up with. In no instance can an officer create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable event in which an officer can have any leadership of a team is if appointed by a team leader or if there are no members to take lead of project.<br />
==Procedure for Submission==<br />
The proposals are due at 11:59 on the night of 1st general meeting in hard copy and in e-mail to the officers. They should contain all the sections mention above be in 12pt font, double-spaced, and printed on one side only. The budget should be submitted electronically as a separate excel spreadsheet. It should also be attached to the hard copy. Once all the proposals are in the budget can be made up and then disbursed along with recommendations from the officers and the advisers.</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8024Proposals2009-06-30T17:02:36Z<p>Marksp: /* Good Examples: */</p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those objectives, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives. <br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them. Without that how does one go about implementing it?<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
##"Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
## "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
====Milestones Example====<br />
* Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* After fall break - Demo at least 2 new prototype drive-trains<br />
* Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, <br />
* Feb 1st - Demo new manipulator using individual joint control<br />
* March 1st - Extended range driving<br />
* Spring Break - Demo some of the competition tasks using the manipulator<br />
* April 30th - Finalize travel plans, demo robot performing some competition objectives<br />
<br />
===Resources===<br />
Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br />
<br />
====Monetary====<br />
This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br />
<br />
====Personnel====<br />
Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads skill sets roughly means interest.<br />
<br />
====Capital Outlays/Tooling====<br />
While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br />
<br />
====Travel/Registration====<br />
In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following<br />
<br />
* Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.<br />
* Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos<br />
* Luggage for the robot<br />
* Shipping for the robot<br />
* Fees - Excess baggage, duties, <br />
<br />
In addition the proposal should state the anticipated cost for travel. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees.<br />
===Schedule===<br />
The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one. If at all possible teams should be involved in multiple task according to subsystem and personnel. For example a software team could be working re-building the system architecture while a mechanical team builds a simple base.<br />
<br />
There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here:http://live.gnome.org/Planner)<br />
===Budget===<br />
The budget contains details on the cost to build the robot and should provide sufficient detail. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final desing will look like (for example which motor they will go with). Carefully study the market and the competition then, to determine what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. For an example see the 2009-2010 SGA budget. Capital outlays (items that can reasonably get more than a year of use) shouldn't be on the budget. <br />
<br />
===Supplemental Documentation===<br />
Any documentation that the team leader feels is required in addition to the above<br />
==Changes, Deadlines, and Penalties==<br />
=== Proposed ===<br />
In years past teams have found it hard to meet self imposed deadlines, resulting in lopsided development schedules. In addition, member retention has been an issue as new members often leave during lulls in the development, indicating that 'not much was going'. To address these concerns and to help the club be more successful in its endeavors, there are new rules regarding milestones. <br />
<br />
<br />
====Applicable deadlines====<br />
Deadlines for projects are the milestone deadlines and the final travel deadline. For milestone deadlines even partial completion is okay as long as prior notice is given. Partial completion though means significant progress has been made towards completing the milestone. For example if the milestone is to demonstrate tele-op driving, but the wheels don't come in by the deadline then even showing that the motors turn in response to tele-op commands is sufficient. On the other hand passing a frame off as completion of the deadline is unacceptable unless all the other components are being shipped/made and haven't arrived. <br />
<br />
The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only. <br />
<br />
====Changes====<br />
Changes can be made to any deadline pending officer approval. The criteria for approval are:<br />
<br />
* Time till deadline in question<br />
* Progress made<br />
* External factors<br />
<br />
Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests. <br />
==== Penalties ====<br />
If a team misses a milestone that team's leader must be prepared to meet with the officers and the team's adviser to discuss plans moving forward. Those plans should include a new schedule, milestones, and objectives if necessary. The deadline for arranging this meeting is 7 days after the deadline. If a team leader fails or objects to attending such a meeting, their budget will be frozen until such a meeting takes place. Furthermore, any travel arrangements will be effectively put on hold and no new travel plans can be made. If a team remains in this state of limbo for significant time the officers will taken further action including but not limited to the removal of the team leader per policy and possibly the disbandment of the team per the constitution.<br />
<br />
==== Changes vs. Partial Completion ====<br />
It is understood that problems will arise along the way (Robotics is still very much a research field). As such team leaders have several options when their projects come into unexpected problems. Change request are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu no additional stress is placed on the members by having to continue to work to meet a new deadline.<br />
==Procedure for Submittal==<br />
The proposals are due at 11:59 on the night of 1st general meeting in hard copy and in e-mail to the officers. They should contain all the sections mention above be in 12pt font, double-spaced, and printed on one side only. The budget should be submitted electronically as a separate excel spreadsheet. It should also be attached to the hard copy. Once all the proposals are in the budget can be made up and then disbursed along with recommendations from the officers and the advisers.</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8023Proposals2009-06-30T17:00:13Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those objectives, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives. <br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them. Without that how does one go about implementing it?<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
* "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
* "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
====Milestones Example====<br />
* Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* After fall break - Demo at least 2 new prototype drive-trains<br />
* Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, <br />
* Feb 1st - Demo new manipulator using individual joint control<br />
* March 1st - Extended range driving<br />
* Spring Break - Demo some of the competition tasks using the manipulator<br />
* April 30th - Finalize travel plans, demo robot performing some competition objectives<br />
<br />
===Resources===<br />
Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br />
<br />
====Monetary====<br />
This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br />
<br />
====Personnel====<br />
Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads skill sets roughly means interest.<br />
<br />
====Capital Outlays/Tooling====<br />
While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br />
<br />
====Travel/Registration====<br />
In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following<br />
<br />
* Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.<br />
* Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos<br />
* Luggage for the robot<br />
* Shipping for the robot<br />
* Fees - Excess baggage, duties, <br />
<br />
In addition the proposal should state the anticipated cost for travel. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees.<br />
===Schedule===<br />
The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one. If at all possible teams should be involved in multiple task according to subsystem and personnel. For example a software team could be working re-building the system architecture while a mechanical team builds a simple base.<br />
<br />
There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here:http://live.gnome.org/Planner)<br />
===Budget===<br />
The budget contains details on the cost to build the robot and should provide sufficient detail. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final desing will look like (for example which motor they will go with). Carefully study the market and the competition then, to determine what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. For an example see the 2009-2010 SGA budget. Capital outlays (items that can reasonably get more than a year of use) shouldn't be on the budget. <br />
<br />
===Supplemental Documentation===<br />
Any documentation that the team leader feels is required in addition to the above<br />
==Changes, Deadlines, and Penalties==<br />
=== Proposed ===<br />
In years past teams have found it hard to meet self imposed deadlines, resulting in lopsided development schedules. In addition, member retention has been an issue as new members often leave during lulls in the development, indicating that 'not much was going'. To address these concerns and to help the club be more successful in its endeavors, there are new rules regarding milestones. <br />
<br />
<br />
====Applicable deadlines====<br />
Deadlines for projects are the milestone deadlines and the final travel deadline. For milestone deadlines even partial completion is okay as long as prior notice is given. Partial completion though means significant progress has been made towards completing the milestone. For example if the milestone is to demonstrate tele-op driving, but the wheels don't come in by the deadline then even showing that the motors turn in response to tele-op commands is sufficient. On the other hand passing a frame off as completion of the deadline is unacceptable unless all the other components are being shipped/made and haven't arrived. <br />
<br />
The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only. <br />
<br />
====Changes====<br />
Changes can be made to any deadline pending officer approval. The criteria for approval are:<br />
<br />
* Time till deadline in question<br />
* Progress made<br />
* External factors<br />
<br />
Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests. <br />
==== Penalties ====<br />
If a team misses a milestone that team's leader must be prepared to meet with the officers and the team's adviser to discuss plans moving forward. Those plans should include a new schedule, milestones, and objectives if necessary. The deadline for arranging this meeting is 7 days after the deadline. If a team leader fails or objects to attending such a meeting, their budget will be frozen until such a meeting takes place. Furthermore, any travel arrangements will be effectively put on hold and no new travel plans can be made. If a team remains in this state of limbo for significant time the officers will taken further action including but not limited to the removal of the team leader per policy and possibly the disbandment of the team per the constitution.<br />
<br />
==== Changes vs. Partial Completion ====<br />
It is understood that problems will arise along the way (Robotics is still very much a research field). As such team leaders have several options when their projects come into unexpected problems. Change request are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu no additional stress is placed on the members by having to continue to work to meet a new deadline.<br />
==Procedure for Submittal==<br />
The proposals are due at 11:59 on the night of 1st general meeting in hard copy and in e-mail to the officers. They should contain all the sections mention above be in 12pt font, double-spaced, and printed on one side only. The budget should be submitted electronically as a separate excel spreadsheet. It should also be attached to the hard copy. Once all the proposals are in the budget can be made up and then disbursed along with recommendations from the officers and the advisers.</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8022Proposals2009-06-30T15:24:28Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those objectives, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives. <br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them. Without that how does one go about implementing it?<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
* "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
* "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
====Milestones Example====<br />
* Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* After fall break - Demo at least 2 new prototype drive-trains<br />
* Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, <br />
* Feb 1st - Demo new manipulator using individual joint control<br />
* March 1st - Extended range driving<br />
* Spring Break - Demo some of the competition tasks using the manipulator<br />
* April 30th - Finalize travel plans, demo robot performing some competition objectives<br />
<br />
===Resources===<br />
Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br />
<br />
====Monetary====<br />
This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br />
<br />
====Personnel====<br />
Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads skill sets roughly means interest.<br />
<br />
====Capital Outlays/Tooling====<br />
While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br />
<br />
====Travel/Registration====<br />
In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following<br />
<br />
* Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.<br />
* Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos<br />
* Luggage for the robot<br />
* Shipping for the robot<br />
* Fees - Excess baggage, duties, <br />
<br />
In addition the proposal should state the anticipated cost for travel. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees.<br />
===Schedule===<br />
The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one. If at all possible teams should be involved in multiple task according to subsystem and personnel. For example a software team could be working re-building the system architecture while a mechanical team builds a simple base.<br />
<br />
There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here:http://live.gnome.org/Planner)<br />
===Budget===<br />
The budget contains details on the cost to build the robot and should provide sufficient detail. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final desing will look like (for example which motor they will go with). Carefully study the market and the competition then, to determine what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. For an example see the 2009-2010 SGA budget. Capital outlays (items that can reasonably get more than a year of use) shouldn't be on the budget. <br />
<br />
===Supplemental Documentation===<br />
Any documentation that the team leader feels is required in addition to the above<br />
==Deadlines and Penalties==<br />
==== Proposed ====<br />
In years past teams have found it hard to meet self imposed deadlines, resulting in lopsided development schedules. In addition, member retention has been an issue as new members often leave during lulls in the development, indicating that 'not much was going'. To address these concerns and to help the club be more successful in its endeavors, there are new rules regarding milestones. If a team misses a milestone that team's leader must be prepared to meet with the officers and the team's adviser to discuss plans moving forward. If a team leader fails or objects to attending such a meeting, their budget will be frozen until such a meeting takes place. Furthermore, any travel arrangements will be effectively put on hold and no new travel plans can be made. If a team remains in this state of limbo for significant time the officers will taken further action including but not limited to the removal of the team leader per policy and possibly the disbandment of the team per the constitution.<br />
==Changes==<br />
==Travel==<br />
Final travel plans include all members paid, all paperwork filled out. hotels and flights booked, and preliminary iternaries are up. Any no competition plans don't need to be ready at that time.<br />
*'Final travel plans for summer competitions' - 1 week before the end of the spring semester<br />
*'Final travel plans for any other competition or event' - One month out<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)<br />
==Changes==</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8021Proposals2009-06-30T15:09:59Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those objectives, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives. <br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them. Without that how does one go about implementing it?<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
* "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
* "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
====Milestones Example====<br />
* Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* After fall break - Demo at least 2 new prototype drive-trains<br />
* Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, <br />
* Feb 1st - Demo new manipulator using individual joint control<br />
* March 1st - Extended range driving<br />
* Spring Break - Demo some of the competition tasks using the manipulator<br />
* April 30th - Finalize travel plans, demo robot performing some competition objectives<br />
<br />
===Resources===<br />
Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br />
<br />
====Monetary====<br />
This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br />
<br />
====Personnel====<br />
Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads skill sets roughly means interest.<br />
<br />
====Capital Outlays/Tooling====<br />
While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br />
<br />
===Travel/Registration===<br />
In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following<br />
<br />
* Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.<br />
* Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos<br />
* Luggage for the robot<br />
* Shipping for the robot<br />
* Fees - Excess baggage, duties, <br />
<br />
In addition the proposal should state the anticipated cost for travel. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees.<br />
===Schedule===<br />
The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one. If at all possible teams should be involved in multiple task according to subsystem and personnel. For example a software team could be working re-building the system architecture while a mechanical team builds a simple base.<br />
<br />
There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here:http://live.gnome.org/Planner)<br />
===Budget===<br />
The budget contains details on the cost to build the robot and should provide sufficient detail. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final desing will look like (for example which motor they will go with). Carefully study the market and the competition then, to determine what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. For an example see the 2009-2010 SGA budget. Capital outlays (items that can reasonably get more than a year of use) shouldn't be on the budget. <br />
<br />
===Supplemental Documentation===<br />
Any documentation that the team leader feels is required in addition to the above<br />
==Deadlines and Penalties==<br />
==Changes==<br />
==Travel==<br />
Final travel plans include all members paid, all paperwork filled out. hotels and flights booked, and preliminary iternaries are up. Any no competition plans don't need to be ready at that time.<br />
*'Final travel plans for summer competitions' - 1 week before the end of the spring semester<br />
*'Final travel plans for any other competition or event' - One month out<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)<br />
==Changes==</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8020Proposals2009-06-30T14:31:06Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those objectives, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives. <br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them. Without that how does one go about implementing it?<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
* "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
* "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
* Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* After fall break - Demo at least 2 new prototype drive-trains<br />
* Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, <br />
* Feb 1st - Demo new manipulator using individual joint control<br />
* March 1st - Extended range driving<br />
* Spring Break - Demo some of the competition tasks using the manipulator<br />
* April 30th - Finalize travel plans, demo robot performing some competition objectives<br />
<br />
===Resources===<br />
Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br />
<br />
====Monetary====<br />
This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br />
<br />
====Personnel====<br />
Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads skill sets roughly means interest.<br />
<br />
====Capital Outlays/Tooling====<br />
While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br />
<br />
===Travel/Registration===<br />
In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following<br />
<br />
* Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.<br />
* Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos<br />
* Luggage for the robot<br />
* Shipping for the robot<br />
* Fees - Excess baggage, duties, <br />
<br />
In addition the proposal should state the anticipated cost for travel. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendance.<br />
===Schedule===<br />
<br />
===Budget===<br />
===Supplemental Documentation===<br />
==Deadlines==<br />
===Travel===<br />
Final travel plans include all members paid, all paperwork filled out. hotels and flights booked, and preliminary iternaries are up. Any no competition plans don't need to be ready at that time.<br />
*'Final travel plans for summer competitions' - 1 week before the end of the spring semester<br />
*'Final travel plans for any other competition or event' - One month out<br />
<br />
==Penalties==<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)<br />
==Changes==</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8019Proposals2009-06-30T13:56:44Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those objectives, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives. <br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them. Without that how does one go about implementing it?<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
* "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
* "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br />
<br />
* Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br />
* Demo at least 2 new prototype drive-trains<br />
* Prototype - Demo new drive-train in a tele-op driving. Successfully, acquire data from <br />
<br />
Notice that in the above milestones there is no design milestone.<br />
<br />
===Resources===<br />
** Can be changed up until the milestone deadline pending officer approval<br />
** Approval will be granted based on proximity to existing deadline, outside circumstances (ex:issues with vendor, or personel) and if the deadline is achievable<br />
** If changes are not approved then the original deadline stands along with penalties for missing it.<br />
** Team advisors will have say in milestones and are expected to attend all demonstrations<br />
* Resources<br />
** Indicate what resources will be needed<br />
*** Monetary - overview of the attached budget <br />
*** Personnel - Skills needed (ex: ME with CAD experience, CS with interest in vision, Mgmt to organize)<br />
*** Capital Outlays/Tools - Describe what tools you'd like and why. Anything that last more than a year <br />
* Travel/Registration<br />
** Registration cost<br />
** Preliminary travel plan<br />
*** Full plans will be submitted before the end of the spring semester<br />
** Location<br />
** Expected cost<br />
** Hotel, food, sigh-seeing, anything not for the project are not covered! See travel policy<br />
** Will cover transportation, gas, materials (Luggage, travel tools and kits), and fees (Luggage fees, shipping, customs)<br />
** Will also cover any incidentals needed for the robot, First Aid, <br />
** Would also like anticipated cost per member to travel (Hotel, food, etc) This is based on an expected number of attendance<br />
** Travel plans can change<br />
** Major penalties for not turning in full travel plans by end of spring semester<br />
<br />
===Schedule===<br />
===Budget===<br />
===Supplemental Documentation===<br />
==Deadlines==<br />
===Travel===<br />
Final travel plans include all members paid, all paperwork filled out. hotels and flights booked, and preliminary iternaries are up. Any no competition plans don't need to be ready at that time.<br />
*'Final travel plans for summer competitions' - 1 week before the end of the spring semester<br />
*'Final travel plans for any other competition or event' - One month out<br />
<br />
==Penalties==<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)<br />
==Changes==</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8018Proposals2009-06-28T21:37:46Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those goals, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives. <br />
<br />
====Bad Examples:====<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them. Without that how does one go about implementing it?<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
====Good Examples:====<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
* "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
* "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisors, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should also be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of to-do list type of task such as repairing the robot. Milestones shouldn't be simple objectives like working robots and should show that some thought and planning has gone into the process.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. More are encouraged.<br />
<br />
===Resources===<br />
** Can be changed up until the milestone deadline pending officer approval<br />
** Approval will be granted based on proximity to existing deadline, outside circumstances (ex:issues with vendor, or personel) and if the deadline is achievable<br />
** If changes are not approved then the original deadline stands along with penalties for missing it.<br />
** Team advisors will have say in milestones and are expected to attend all demonstrations<br />
* Resources<br />
** Indicate what resources will be needed<br />
*** Monetary - overview of the attached budget <br />
*** Personnel - Skills needed (ex: ME with CAD experience, CS with interest in vision, Mgmt to organize)<br />
*** Capital Outlays/Tools - Describe what tools you'd like and why. Anything that last more than a year <br />
* Travel/Registration<br />
** Registration cost<br />
** Preliminary travel plan<br />
*** Full plans will be submitted before the end of the spring semester<br />
** Location<br />
** Expected cost<br />
** Hotel, food, sigh-seeing, anything not for the project are not covered! See travel policy<br />
** Will cover transportation, gas, materials (Luggage, travel tools and kits), and fees (Luggage fees, shipping, customs)<br />
** Will also cover any incidentals needed for the robot, First Aid, <br />
** Would also like anticipated cost per member to travel (Hotel, food, etc) This is based on an expected number of attendance<br />
** Travel plans can change<br />
** Major penalties for not turning in full travel plans by end of spring semester<br />
<br />
===Schedule===<br />
===Budget===<br />
===Supplemental Documentation===<br />
==Deadlines==<br />
===Travel===<br />
Final travel plans include all members paid, all paperwork filled out. hotels and flights booked, and preliminary iternaries are up. Any no competition plans don't need to be ready at that time.<br />
*'Final travel plans for summer competitions' - 1 week before the end of the spring semester<br />
*'Final travel plans for any other competition or event' - One month out<br />
<br />
==Penalties==<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)<br />
==Changes==</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8017Proposals2009-06-28T21:36:30Z<p>Marksp: /* Travel */</p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those goals, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives. <br />
<br />
Bad Examples:<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them. Without that how does one go about implementing it?<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
Good Examples:<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
** "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
** "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisors, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should also be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of to-do list type of task such as repairing the robot. Milestones shouldn't be simple objectives like working robots and should show that some thought and planning has gone into the process.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. More are encouraged.<br />
<br />
===Resources===<br />
** Can be changed up until the milestone deadline pending officer approval<br />
** Approval will be granted based on proximity to existing deadline, outside circumstances (ex:issues with vendor, or personel) and if the deadline is achievable<br />
** If changes are not approved then the original deadline stands along with penalties for missing it.<br />
** Team advisors will have say in milestones and are expected to attend all demonstrations<br />
* Resources<br />
** Indicate what resources will be needed<br />
*** Monetary - overview of the attached budget <br />
*** Personnel - Skills needed (ex: ME with CAD experience, CS with interest in vision, Mgmt to organize)<br />
*** Capital Outlays/Tools - Describe what tools you'd like and why. Anything that last more than a year <br />
* Travel/Registration<br />
** Registration cost<br />
** Preliminary travel plan<br />
*** Full plans will be submitted before the end of the spring semester<br />
** Location<br />
** Expected cost<br />
** Hotel, food, sigh-seeing, anything not for the project are not covered! See travel policy<br />
** Will cover transportation, gas, materials (Luggage, travel tools and kits), and fees (Luggage fees, shipping, customs)<br />
** Will also cover any incidentals needed for the robot, First Aid, <br />
** Would also like anticipated cost per member to travel (Hotel, food, etc) This is based on an expected number of attendance<br />
** Travel plans can change<br />
** Major penalties for not turning in full travel plans by end of spring semester<br />
<br />
===Schedule===<br />
===Budget===<br />
===Supplemental Documentation===<br />
==Deadlines==<br />
===Travel===<br />
Final travel plans include all members paid, all paperwork filled out. hotels and flights booked, and preliminary iternaries are up. Any no competition plans don't need to be ready at that time.<br />
*'Final travel plans for summer competitions' - 1 week before the end of the spring semester<br />
*'Final travel plans for any other competition or event' - One month out<br />
<br />
==Penalties==<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)<br />
==Changes==</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8016Proposals2009-06-28T21:35:49Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those goals, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives. <br />
<br />
Bad Examples:<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them. Without that how does one go about implementing it?<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
Good Examples:<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
** "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
** "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
===Milestones===<br />
The milestones are a means of demonstrating progress to the officers, the advisors, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should also be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br />
<br />
The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of to-do list type of task such as repairing the robot. Milestones shouldn't be simple objectives like working robots and should show that some thought and planning has gone into the process.<br />
<br />
At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. More are encouraged.<br />
<br />
===Resources===<br />
** Can be changed up until the milestone deadline pending officer approval<br />
** Approval will be granted based on proximity to existing deadline, outside circumstances (ex:issues with vendor, or personel) and if the deadline is achievable<br />
** If changes are not approved then the original deadline stands along with penalties for missing it.<br />
** Team advisors will have say in milestones and are expected to attend all demonstrations<br />
* Resources<br />
** Indicate what resources will be needed<br />
*** Monetary - overview of the attached budget <br />
*** Personnel - Skills needed (ex: ME with CAD experience, CS with interest in vision, Mgmt to organize)<br />
*** Capital Outlays/Tools - Describe what tools you'd like and why. Anything that last more than a year <br />
* Travel/Registration<br />
** Registration cost<br />
** Preliminary travel plan<br />
*** Full plans will be submitted before the end of the spring semester<br />
** Location<br />
** Expected cost<br />
** Hotel, food, sigh-seeing, anything not for the project are not covered! See travel policy<br />
** Will cover transportation, gas, materials (Luggage, travel tools and kits), and fees (Luggage fees, shipping, customs)<br />
** Will also cover any incidentals needed for the robot, First Aid, <br />
** Would also like anticipated cost per member to travel (Hotel, food, etc) This is based on an expected number of attendance<br />
** Travel plans can change<br />
** Major penalties for not turning in full travel plans by end of spring semester<br />
<br />
===Schedule===<br />
===Budget===<br />
===Supplemental Documentation===<br />
==Deadlines==<br />
===Travel===<br />
Final travel plans include all members paid, all paperwork filled out. hotels and flights booked, and preliminary iternaries are up. Any no competition plans don't need to be ready at that time.<br />
Final travel plans for summer sompetitions - 1 week before the end of the spring semester<br />
Final travel plans for any other competition or event - One month out<br />
==Penalties==<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)<br />
==Changes==</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8015Proposals2009-06-28T21:11:09Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those goals, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. These sort of decisions actually<br />
<br />
Bad Examples:<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them.<br />
# "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. <br />
<br />
Good Examples:<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
# This one can go two ways:<br />
** "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.<br />
** "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.<br />
<br />
Descibes:<br />
*Goals and Objectives<br />
** Attempts should be made to limit the goals in scope and number<br />
** The officers will look to see that the project is possible and make recommendations<br />
** Team leader and officers sign-off on goals and objectives<br />
** Team leaders should inform officers of any new changes, such as reducing or removing a goal, or adding a new one at the officer meetings<br />
** Officers should be expected to give feedback on any changes and make further recommendations<br />
** Team advisors will also have a say in objectives and goals<br />
* Milestones<br />
** Project milestones are required for all projects<br />
** This section should contain a description of each milestone<br />
** Milestone scope should be appropriate for amount of time; this means accounting for build and debug time<br />
** Milestone should be easily demonstrable.<br />
** At the very least there must be a milestone for prototype or first revision by the end of fall semester, and the start of testing by the end of spring semester. The reason is for demo days<br />
** Additional milestones are heavily encouraged<br />
** Penalties for missing milestones<br />
** Can be changed up until the milestone deadline pending officer approval<br />
** Approval will be granted based on proximity to existing deadline, outside circumstances (ex:issues with vendor, or personel) and if the deadline is achievable<br />
** If changes are not approved then the original deadline stands along with penalties for missing it.<br />
** Team advisors will have say in milestones and are expected to attend all demonstrations<br />
* Resources<br />
** Indicate what resources will be needed<br />
*** Monetary - overview of the attached budget <br />
*** Personnel - Skills needed (ex: ME with CAD experience, CS with interest in vision, Mgmt to organize)<br />
*** Capital Outlays/Tools - Describe what tools you'd like and why. Anything that last more than a year <br />
* Travel/Registration<br />
** Registration cost<br />
** Preliminary travel plan<br />
*** Full plans will be submitted before the end of the spring semester<br />
** Location<br />
** Expected cost<br />
** Hotel, food, sigh-seeing, anything not for the project are not covered! See travel policy<br />
** Will cover transportation, gas, materials (Luggage, travel tools and kits), and fees (Luggage fees, shipping, customs)<br />
** Will also cover any incidentals needed for the robot, First Aid, <br />
** Would also like anticipated cost per member to travel (Hotel, food, etc) This is based on an expected number of attendance<br />
** Travel plans can change<br />
** Major penalties for not turning in full travel plans by end of spring semester<br />
<br />
===Schedule===<br />
===Budget===<br />
===Supplemental Documentation===<br />
==Deadlines==<br />
==Penalties==<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8014Proposals2009-06-28T20:51:26Z<p>Marksp: </p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
<br />
==Prior Results==<br />
A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to proposal.<br />
==Project Description==<br />
The project description is the heart of the proposal and contains the objectives, the milestones for reaching those goals, the resources that will be needed, and any travel plans. <br />
===Objectives===<br />
The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. Concise, well defined objectives that<br />
<br />
Bad Examples:<br />
# "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them.<br />
# "Fix code for estimating position" - This sounds more like a bug fix than an objective and is too narrow. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.<br />
# "Design a manipulator for the science task" - While this is specific it leavs<br />
<br />
Good Examples:<br />
# "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate. <br />
# "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.<br />
<br />
Descibes:<br />
*Goals and Objectives<br />
** Attempts should be made to limit the goals in scope and number<br />
** The officers will look to see that the project is possible and make recommendations<br />
** Team leader and officers sign-off on goals and objectives<br />
** Team leaders should inform officers of any new changes, such as reducing or removing a goal, or adding a new one at the officer meetings<br />
** Officers should be expected to give feedback on any changes and make further recommendations<br />
** Team advisors will also have a say in objectives and goals<br />
* Milestones<br />
** Project milestones are required for all projects<br />
** This section should contain a description of each milestone<br />
** Milestone scope should be appropriate for amount of time; this means accounting for build and debug time<br />
** Milestone should be easily demonstrable.<br />
** At the very least there must be a milestone for prototype or first revision by the end of fall semester, and the start of testing by the end of spring semester. The reason is for demo days<br />
** Additional milestones are heavily encouraged<br />
** Penalties for missing milestones<br />
** Can be changed up until the milestone deadline pending officer approval<br />
** Approval will be granted based on proximity to existing deadline, outside circumstances (ex:issues with vendor, or personel) and if the deadline is achievable<br />
** If changes are not approved then the original deadline stands along with penalties for missing it.<br />
** Team advisors will have say in milestones and are expected to attend all demonstrations<br />
* Resources<br />
** Indicate what resources will be needed<br />
*** Monetary - overview of the attached budget <br />
*** Personnel - Skills needed (ex: ME with CAD experience, CS with interest in vision, Mgmt to organize)<br />
*** Capital Outlays/Tools - Describe what tools you'd like and why. Anything that last more than a year <br />
* Travel/Registration<br />
** Registration cost<br />
** Preliminary travel plan<br />
*** Full plans will be submitted before the end of the spring semester<br />
** Location<br />
** Expected cost<br />
** Hotel, food, sigh-seeing, anything not for the project are not covered! See travel policy<br />
** Will cover transportation, gas, materials (Luggage, travel tools and kits), and fees (Luggage fees, shipping, customs)<br />
** Will also cover any incidentals needed for the robot, First Aid, <br />
** Would also like anticipated cost per member to travel (Hotel, food, etc) This is based on an expected number of attendance<br />
** Travel plans can change<br />
** Major penalties for not turning in full travel plans by end of spring semester<br />
<br />
===Schedule===<br />
===Budget===<br />
===Supplemental Documentation===<br />
==Deadlines==<br />
==Penalties==<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)</div>Marksphttps://wiki.robojackets.org/index.php?title=Proposals&diff=8013Proposals2009-06-28T19:50:46Z<p>Marksp: Created page with 'Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a descri...'</p>
<hr />
<div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br />
<br />
==Preliminary Proposal==<br />
An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.<br />
==Sections==<br />
===Project Description===<br />
Descibes:<br />
*Goals and Objectives<br />
** Attempts should be made to limit the goals in scope and number<br />
** The officers will look to see that the project is possible and make recommendations<br />
** Team leader and officers sign-off on goals and objectives<br />
** Team leaders should inform officers of any new changes, such as reducing or removing a goal, or adding a new one at the officer meetings<br />
** Officers should be expected to give feedback on any changes and make further recommendations<br />
** Team advisors will also have a say in objectives and goals<br />
* Milestones<br />
** Project milestones are required for all projects<br />
** This section should contain a description of each milestone<br />
** Milestone scope should be appropriate for amount of time; this means accounting for build and debug time<br />
** Milestone should be easily demonstrable.<br />
** At the very least there must be a milestone for prototype or first revision by the end of fall semester, and the start of testing by the end of spring semester. The reason is for demo days<br />
** Additional milestones are heavily encouraged<br />
** Penalties for missing milestones<br />
** Can be changed up until the milestone deadline pending officer approval<br />
** Approval will be granted based on proximity to existing deadline, outside circumstances (ex:issues with vendor, or personel) and if the deadline is achievable<br />
** If changes are not approved then the original deadline stands along with penalties for missing it.<br />
** Team advisors will have say in milestones and are expected to attend all demonstrations<br />
* Resources<br />
** Indicate what resources will be needed<br />
*** Monetary - overview of the attached budget <br />
*** Personnel - Skills needed (ex: ME with CAD experience, CS with interest in vision, Mgmt to organize)<br />
*** Capital Outlays/Tools - Describe what tools you'd like and why. Anything that last more than a year <br />
* Travel/Registration<br />
** Registration cost<br />
** Preliminary travel plan<br />
*** Full plans will be submitted before the end of the spring semester<br />
** Location<br />
** Expected cost<br />
** Hotel, food, sigh-seeing, anything not for the project are not covered! See travel policy<br />
** Will cover transportation, gas, materials (Luggage, travel tools and kits), and fees (Luggage fees, shipping, customs)<br />
** Will also cover any incidentals needed for the robot, First Aid, <br />
** Would also like anticipated cost per member to travel (Hotel, food, etc) This is based on an expected number of attendance<br />
** Travel plans can change<br />
** Major penalties for not turning in full travel plans by end of spring semester<br />
<br />
===Schedule===<br />
===Budget===<br />
===Supplemental Documentation===<br />
==Deadlines==<br />
==Penalties==<br />
==Procedure for Submittal==<br />
What is the procedure<br />
* Contains<br />
** Four sections detailed above<br />
** Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one<br />
** Preliminary proposal worksheets due by the 1st week of school<br />
** Full proposals due on the date of the 1st general meeting at 11:59pm<br />
** E-mailed to President and hard copies submitted to President<br />
** No spending on new budgets until budget is approved by the officers<br />
** Penalties for missing deadlines<br />
** Formating Guidelines<br />
*** 12pt Font, double spaced, one side only<br />
*** Sections clearly indicated<br />
*** Budget must be in excel format<br />
*** Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)<br />
*** Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.<br />
*** Once proposals are all in the budget process can begin<br />
*** Officers will also review each proposal with the Team leader and provide feedback or request clarification<br />
*** Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)</div>Marksphttps://wiki.robojackets.org/index.php?title=Main_Page&diff=8011Main Page2009-06-28T17:50:47Z<p>Marksp: </p>
<hr />
<div>__NOTOC__<br />
{|<br />
! colspan="2" valign="bottom" | <br />
<br />
'''''RoboJackets Wiki'''''<br />
! width="20%" rowspan="6" valign="top" | <br />
[[Image:Robojackets.jpg|200px|center]]<br/><br />
'''The Georgia Tech RoboJackets'''<br/><br />
'''http://www.robojackets.org'''<br/><br />
<br />
|- <br />
| colspan="2" | Welcome to the '''[http://www.gatech.edu/ Georgia Tech]''' '''[http://www.robojackets.org/ RoboJackets]''' wiki! We are currently looking for both volunteers and sponsors. More info can be found on the [[How you can help]] page. Feel free to contact an [[Admins | admin]] if you have any questions about this site. <br />
<br />
<br />
|- <br />
! width="40%" valign="top" | Teams & Projects<br />
! width="40%" valign="top" | Resources<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[FIRST]]<br />
* [[IGVC]]<br />
* [[RoboCup]]<br />
* [[BattleBots]]<br />
* [[TE Sessions|Technology Enrichment (TE) Sessions]]<br />
---<br />
* [[HexaPod]]<br />
* [[IKArm|Inverse Kinematic (IK) Arm]]<br />
* [[Downhill Car]]<br/><br />
<br />
| width="40%" valign="top" | <br />
* ''[[New Users]]'' <br />
* [[How to Guides]]<br />
* [[Help:Editing|Editing Help]]<br />
* [[Resources for Learning]]<br />
* [[Training Sessions]]<br />
* [[Project Ideas]]<br />
* [[Research]]<br />
* ''[[Current events|Current Events]]''<br />
<br />
<br />
|- <br />
! width="40%" | Internal RJ Info<br />
! width="40%" | Current Important - WIP Pages<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* ''[[Meeting Minutes]]''<br />
* ''[[List_of_People|List of people]]''<br />
* ''[[Policies and Best Practices]]''<br />
* [[Yearly Housekeeping]]<br />
* [[Records]]<br />
* [[Public_Relations|Public Relations]]<br />
* [[Promotional Media]]<br />
* [[Server]]<br />
* [[Contact List]]<br />
* [[Events]]<br />
<br />
| width="40%" valign="top"| <br />
* ''[[How to Guides]]''<br />
* [[Subversion]]<br />
* [[Wtodo|Wiki and Server TODO]] Wiki and server feature requests<br />
* [[Info|RoboJackets Information]]<br />
|}</div>Marksphttps://wiki.robojackets.org/index.php?title=Main_Page&diff=8010Main Page2009-06-28T17:46:19Z<p>Marksp: </p>
<hr />
<div>__NOTOC__<br />
{|<br />
! colspan="2" valign="bottom" | <br />
<br />
'''''RoboJackets Wiki'''''<br />
! width="20%" rowspan="6" valign="top" | <br />
[[Image:Robojackets.jpg|200px|center]]<br/><br />
'''The Georgia Tech RoboJackets'''<br/><br />
'''http://www.robojackets.org'''<br/><br />
<br />
|- <br />
| colspan="2" | Welcome to the '''[http://www.gatech.edu/ Georgia Tech]''' '''[http://www.robojackets.org/ RoboJackets]''' wiki! We are currently looking for both volunteers and sponsors. More info can be found on the [[How you can help]] page. Feel free to contact an [[Admins | admin]] if you have any questions about this site. <br />
<br />
<br />
|- <br />
! width="40%" valign="top" | Teams & Projects<br />
! width="40%" valign="top" | Resources<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[FIRST]]<br />
* [[IGVC]]<br />
* [[RoboCup]]<br />
* [[BattleBots]]<br />
* [[TE Sessions|Technology Enrichment (TE) Sessions]]<br />
---<br />
* [[HexaPod]]<br />
* [[IKArm|Inverse Kinematic (IK) Arm]]<br />
* [[Downhill Car]]<br/><br />
<br />
| width="40%" valign="top" | <br />
* ''[[New Users]]'' <br />
* [[How to Guides]]<br />
* [[Help:Editing|Editing Help]]<br />
* [[Resources for Learning]]<br />
* [[Training Sessions]]<br />
* [[Project Ideas]]<br />
* [[Research]]<br />
* ''[[Current events|Current Events]]''<br />
<br />
<br />
|- <br />
! width="40%" | Internal RJ Info<br />
! width="40%" | Current Important - WIP Pages<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* ''[[Meeting Minutes]]''<br />
* ''[[List_of_People|List of people]]''<br />
* [[Yearly Housekeeping]]<br />
* [[Records]]<br />
* [[Public_Relations|Public Relations]]<br />
* [[Promotional Media]]<br />
* [[Server]]<br />
* [[Contact List]]<br />
* [[Events]]<br />
<br />
| width="40%" valign="top"| <br />
* ''[[How to Guides]]''<br />
* [[Subversion]]<br />
* [[Wtodo|Wiki and Server TODO]] Wiki and server feature requests<br />
* [[Info|RoboJackets Information]]<br />
|}</div>Marksphttps://wiki.robojackets.org/index.php?title=User:Marksp&diff=7955User:Marksp2009-04-30T18:29:41Z<p>Marksp: </p>
<hr />
<div>{| id="go" style="color: #ffffff; width:12em; margin:0 0 0.5em 1em; float: right;"<br />
!align="center" bgcolor="#808080" colspan="3"|[[image:phillip.jpg]]<br />
|}<br />
====Phillip Marks====<br />
*Phone: 770-315-8653<br />
*Email: phillip.marks@gatech.edu<br />
*Projects: RoboCup, World Domination</div>Marksphttps://wiki.robojackets.org/index.php?title=User:Marksp&diff=7954User:Marksp2009-04-30T18:29:13Z<p>Marksp: </p>
<hr />
<div>{| id="go" style="color: #ffffff; width:12em; margin:0 0 0.5em 1em; float: right;"<br />
!align="center" bgcolor="#808080" colspan="3"|[[image:phillip2.jpg]]<br />
|}<br />
====Phillip Marks====<br />
*Phone: 770-315-8653<br />
*Email: phillip.marks@gatech.edu<br />
*Projects: RoboCup, World Domination</div>Marksphttps://wiki.robojackets.org/index.php?title=Main_Page&diff=7822Main Page2009-03-20T15:57:12Z<p>Marksp: </p>
<hr />
<div>__NOTOC__<br />
{|<br />
! colspan="2" valign="bottom" | <br />
<br />
'''''RoboJackets Wiki'''''<br />
! width="20%" rowspan="6" valign="top" | <br />
[[Image:Robojackets.jpg|200px|center]]<br/><br />
'''The Georgia Tech RoboJackets'''<br/><br />
'''http://www.robojackets.org'''<br/><br />
<br />
|- <br />
| colspan="2" | Welcome to the '''[http://www.gatech.edu/ Georgia Tech]''' '''[http://www.robojackets.org/ RoboJackets]''' wiki! We are currently looking for both volunteers and sponsors. More info can be found on the [[How you can help]] page. Feel free to contact an [[Admins | admin]] if you have any questions about this site. <br />
<br />
<br />
|- <br />
! width="40%" valign="top" | Teams & Projects<br />
! width="40%" valign="top" | Resources<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[FIRST]]<br />
* [[IGVC]]<br />
* [[RoboCup]]<br />
* [[BattleBots]]<br />
* [[TE Sessions|Technology Enrichment (TE) Sessions]]<br />
---<br />
* [[HexaPod]]<br />
* [[IKArm|Inverse Kinematic (IK) Arm]]<br />
* [[Downhill Car]]<br/><br />
<br />
| width="40%" valign="top" | <br />
* ''[[New Users]]'' <br />
* [[How to Guides]]<br />
* [[Help:Editing|Editing Help]]<br />
* [[Resources for Learning]]<br />
* [[Training Sessions]]<br />
* [[Project Ideas]]<br />
* [[Research]]<br />
* ''[[Current events|Current Events]]''<br />
<br />
<br />
|- <br />
! width="40%" | Internal RJ Info<br />
! width="40%" | Current Important - WIP Pages<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[Officer Candidate Platforms]]<br />
* ''[[Meeting Minutes]]''<br />
* ''[[List_of_People|List of people]]''<br />
* [[Yearly Housekeeping]]<br />
* [[Records]]<br />
* [[Public_Relations|Public Relations]]<br />
* [[Promotional Media]]<br />
* [[Server]]<br />
* [[Contact List]]<br />
* [[Sponsor List]]<br />
* [[Equipment List]]<br />
* [[Events]]<br />
<br />
| width="40%" valign="top"| <br />
* ''[[How to Guides]]''<br />
* [[Subversion]]<br />
* [[Wtodo|Wiki and Server TODO]] Wiki and server feature requests<br />
* [[Info|RoboJackets Information]]<br />
|}</div>Marksphttps://wiki.robojackets.org/index.php?title=Main_Page&diff=7820Main Page2009-03-20T15:54:59Z<p>Marksp: </p>
<hr />
<div>__NOTOC__<br />
{|<br />
! colspan="2" valign="bottom" | <br />
<br />
'''''RoboJackets Wiki'''''<br />
! width="20%" rowspan="6" valign="top" | <br />
[[Image:Robojackets.jpg|200px|center]]<br/><br />
'''The Georgia Tech RoboJackets'''<br/><br />
'''http://www.robojackets.org'''<br/><br />
<br />
|- <br />
| colspan="2" | Welcome to the '''[http://www.gatech.edu/ Georgia Tech]''' '''[http://www.robojackets.org/ RoboJackets]''' wiki! We are currently looking for both volunteers and sponsors. More info can be found on the [[How you can help]] page. Feel free to contact an [[Admins | admin]] if you have any questions about this site. <br />
<br />
<br />
|- <br />
! width="40%" valign="top" | Teams & Projects<br />
! width="40%" valign="top" | Resources<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[FIRST]]<br />
* [[IGVC]]<br />
* [[RoboCup]]<br />
* [[BattleBots]]<br />
* [[TE Sessions|Technology Enrichment (TE) Sessions]]<br />
---<br />
* [[HexaPod]]<br />
* [[IKArm|Inverse Kinematic (IK) Arm]]<br />
* [[Downhill Car]]<br/><br />
<br />
| width="40%" valign="top" | <br />
* ''[[New Users]]'' <br />
* [[How to Guides]]<br />
* [[Help:Editing|Editing Help]]<br />
* [[Resources for Learning]]<br />
* [[Training Sessions]]<br />
* [[Project Ideas]]<br />
* [[Research]]<br />
* ''[[Current events|Current Events]]''<br />
<br />
<br />
|- <br />
! width="40%" | Internal RJ Info<br />
! width="40%" | Current Important - WIP Pages<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[09 Leadership Mini-Retreat]]<br />
* ''[[Meeting Minutes]]''<br />
* ''[[List_of_People|List of people]]''<br />
* [[Yearly Housekeeping]]<br />
* [[Records]]<br />
* [[Public_Relations|Public Relations]]<br />
* [[Promotional Media]]<br />
* [[Server]]<br />
* [[Contact List]]<br />
* [[Sponsor List]]<br />
* [[Equipment List]]<br />
* [[Events]]<br />
<br />
| width="40%" valign="top"| <br />
* ''[[How to Guides]]''<br />
* [[Subversion]]<br />
* [[Wtodo|Wiki and Server TODO]] Wiki and server feature requests<br />
* [[Info|RoboJackets Information]]<br />
|}</div>Marksphttps://wiki.robojackets.org/index.php?title=Main_Page&diff=7819Main Page2009-03-20T15:54:38Z<p>Marksp: </p>
<hr />
<div>__NOTOC__<br />
{|<br />
! colspan="2" valign="bottom" | <br />
<br />
'''''RoboJackets Wiki'''''<br />
! width="20%" rowspan="6" valign="top" | <br />
[[Image:Robojackets.jpg|200px|center]]<br/><br />
'''The Georgia Tech RoboJackets'''<br/><br />
'''http://www.robojackets.org'''<br/><br />
<br />
|- <br />
| colspan="2" | Welcome to the '''[http://www.gatech.edu/ Georgia Tech]''' '''[http://www.robojackets.org/ RoboJackets]''' wiki! We are currently looking for both volunteers and sponsors. More info can be found on the [[How you can help]] page. Feel free to contact an [[Admins | admin]] if you have any questions about this site. <br />
<br />
<br />
|- <br />
! width="40%" valign="top" | Teams & Projects<br />
! width="40%" valign="top" | Resources<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[FIRST]]<br />
* [[IGVC]]<br />
* [[RoboCup]]<br />
* [[BattleBots]]<br />
* [[TE Sessions|Technology Enrichment (TE) Sessions]]<br />
---<br />
* [[HexaPod]]<br />
* [[IKArm|Inverse Kinematic (IK) Arm]]<br />
* [[Downhill Car]]<br/><br />
<br />
| width="40%" valign="top" | <br />
* ''[[New Users]]'' <br />
* [[How to Guides]]<br />
* [[Help:Editing|Editing Help]]<br />
* [[Resources for Learning]]<br />
* [[Training Sessions]]<br />
* [[Project Ideas]]<br />
* [[Research]]<br />
* ''[[Current events|Current Events]]''<br />
<br />
<br />
|- <br />
! width="40%" | Internal RJ Info<br />
! width="40%" | Current Important - WIP Pages<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[09 Leadership Mini-Retreat]]<br />
* ''[[Meeting Minutes]]''<br />
* ''[[List_of_People|List of people]]''<br />
* [[Yearly Housekeeping]]<br />
* [[Club TODO List]]<br />
* [[Records]]<br />
* [[Public_Relations|Public Relations]]<br />
* [[Promotional Media]]<br />
* [[Server]]<br />
* [[Contact List]]<br />
* [[Sponsor List]]<br />
* [[Equipment List]]<br />
* [[Events]]<br />
<br />
| width="40%" valign="top"| <br />
* ''[[How to Guides]]''<br />
* [[Subversion]]<br />
* [[Wtodo|Wiki and Server TODO]] Wiki and server feature requests<br />
* [[Info|RoboJackets Information]]<br />
|}</div>Marksphttps://wiki.robojackets.org/index.php?title=Main_Page&diff=7728Main Page2009-02-14T00:18:48Z<p>Marksp: </p>
<hr />
<div>__NOTOC__<br />
{|<br />
! colspan="2" valign="bottom" | <br />
<br />
'''''RoboJackets Wiki'''''<br />
! width="20%" rowspan="6" valign="top" | <br />
[[Image:Robojackets.jpg|200px|center]]<br/><br />
'''The Georgia Tech RoboJackets'''<br/><br />
'''http://www.robojackets.org'''<br/><br />
<br />
|- <br />
| colspan="2" | Welcome to the '''[http://www.gatech.edu/ Georgia Tech]''' '''[http://www.robojackets.org/ RoboJackets]''' wiki! We are currently looking for both volunteers and sponsors. More info can be found on the [[How you can help]] page. Feel free to contact an [[Admins | admin]] if you have any questions about this site. <br />
<br />
<br />
|- <br />
! width="40%" valign="top" | Teams & Projects<br />
! width="40%" valign="top" | Resources<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[FIRST]]<br />
* [[IGVC]]<br />
* [[RoboCup]]<br />
* [[BattleBots]]<br />
* [[TE Sessions|Technology Enrichment (TE) Sessions]]<br />
---<br />
* [[HexaPod]]<br />
* [[IKArm|Inverse Kinematic (IK) Arm]]<br />
* [[Downhill Car]]<br/><br />
<br />
| width="40%" valign="top" | <br />
* ''[[New Users]]'' <br />
* [[How to Guides]]<br />
* [[Help:Editing|Editing Help]]<br />
* [[Resources for Learning]]<br />
* [[Training Sessions]]<br />
* [[Project Ideas]]<br />
* [[Research]]<br />
* ''[[Current events|Current Events]]''<br />
<br />
<br />
|- <br />
! width="40%" | Internal RJ Info<br />
! width="40%" | Current Important - WIP Pages<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[09 Leadership Mini-Retreat]]<br />
* ''[[Meeting Minutes]]''<br />
* ''[[List_of_People|List of people]]''<br />
* ''[[Spring_Cleaning | Spring Cleaning]]''<br />
* [[Yearly Housekeeping]]<br />
* [[Club TODO List]]<br />
* [[Records]]<br />
* [[Public_Relations|Public Relations]]<br />
* [[Promotional Media]]<br />
* [[Server]]<br />
* [[Contact List]]<br />
* [[Sponsor List]]<br />
* [[Equipment List]]<br />
* [[Events]]<br />
<br />
| width="40%" valign="top"| <br />
* ''[[How to Guides]]''<br />
* [[Subversion]]<br />
* [[Wtodo|Wiki and Server TODO]] Wiki and server feature requests<br />
* [[Info|RoboJackets Information]]<br />
|}</div>Marksphttps://wiki.robojackets.org/index.php?title=Special:Badtitle/NS100:Equipment_List&diff=7681Special:Badtitle/NS100:Equipment List2009-01-26T18:23:26Z<p>Marksp: </p>
<hr />
<div>===Equipment On Loan===<br />
<br />
====5 Vex Kits 01/7/2009====<br />
* Given to Vinton Wolfe<br />
* Address: Henry W. Grady High School 929 Charles Allen Drive NE Atlanta, Ga 30309<br />
* Phone (Cell) : 404-695-4804<br />
* SN RJ 1001-5<br />
<br />
====1 PUMA Robot Arm 01/16/2009====<br />
* Donated to EE senior design<br />
* Returns in the summer<br />
* See [[User:Marksp|Phillip]] for details</div>Marksphttps://wiki.robojackets.org/index.php?title=RoboCup&diff=7639RoboCup2009-01-15T00:21:42Z<p>Marksp: /* Important Items */</p>
<hr />
<div>[[Image:Robocup.jpg|thumb|350px|right|Apologies Somethingawful.com]] <br />
<br />
==Important Items==<br />
* [[RoboCup Meeting Minutes | Meeting Minutes]]<br />
* [http://small-size.informatik.uni-bremen.de/ Small Size League Website]<br />
* [[RCResources|RoboCup Resources for Learning]]<br />
* [[Resources for Learning]]<br />
* [[RC09Brainstorm|Long Term Ideas]]<br />
* [[RCPerformanceNum | Performance Numbers]]<br />
* [[Research Papers]]<br />
* [[Work_Plan_08-09 | Work Plan for Winter Break and Beyond]]<br />
<br />
== Systems ==<br />
==== 2009 ====<br />
* [[RCMeetingMinutes | RoboCup 2009 System Outline]]<br />
* [[RoboCup_Electrical_2009|Electrical System]]<br />
* [[RoboCup_Radio_2009|Radio Communication]]<br />
* [[RoboCup_Software_2009|Software System]]<br />
* [[RoboCupMechanical|Mechanical System Information]]<br />
<br />
==== 2008 ====<br />
*[[RC08General|General System Info / Resources]]<br />
*[[RoboCupElectrical|Electrical System]]<br />
*[[RoboCupMechanical2008|Mechanical System]]<br />
*[[RoboCupSoftware|Software System]]<br />
**[[RC08SWRoadMap|Short Term Software Roadmap]]<br />
**[[Development Tools]]<br />
**[[RoboCup Coding Style|Coding Style]]<br />
**[[Code Examples]]<br />
<br />
==== 2007 ====<br />
* [[RoboCupElectrical2007|Electrical System Information]]<br />
** [[RCpartsSample|How to Sample Parts for RoboCup]]<br />
* [[RoboCupSoftware2007|Software System Information]]<br />
* [[RoboCupMechanical2007|Mechanical System Information]]<br />
* [[RobocupVision|Vision System Information]]<br />
** [[RCVisSoftware|Robocup Image Processing]]<br />
** [[RCCamera|Robocup Image Acquisition]]<br />
* [[Image:TDP.pdf]]<br />
<br />
==Travel==<br />
*[[RC08Travel|Personal Travel Costs and Info]]<br />
*[[RC08TravelLog|Team Travel Logistics and Costs]]</div>Marksphttps://wiki.robojackets.org/index.php?title=RoboCup&diff=7638RoboCup2009-01-15T00:21:21Z<p>Marksp: /* Important Items */</p>
<hr />
<div>[[Image:Robocup.jpg|thumb|350px|right|Apologies Somethingawful.com]] <br />
<br />
==Important Items==<br />
* [[Meeting Minutes | Meeting Minutes]]<br />
* [http://small-size.informatik.uni-bremen.de/ Small Size League Website]<br />
* [[RCResources|RoboCup Resources for Learning]]<br />
* [[Resources for Learning]]<br />
* [[RC09Brainstorm|Long Term Ideas]]<br />
* [[RCPerformanceNum | Performance Numbers]]<br />
* [[Research Papers]]<br />
* [[Work_Plan_08-09 | Work Plan for Winter Break and Beyond]]<br />
<br />
== Systems ==<br />
==== 2009 ====<br />
* [[RCMeetingMinutes | RoboCup 2009 System Outline]]<br />
* [[RoboCup_Electrical_2009|Electrical System]]<br />
* [[RoboCup_Radio_2009|Radio Communication]]<br />
* [[RoboCup_Software_2009|Software System]]<br />
* [[RoboCupMechanical|Mechanical System Information]]<br />
<br />
==== 2008 ====<br />
*[[RC08General|General System Info / Resources]]<br />
*[[RoboCupElectrical|Electrical System]]<br />
*[[RoboCupMechanical2008|Mechanical System]]<br />
*[[RoboCupSoftware|Software System]]<br />
**[[RC08SWRoadMap|Short Term Software Roadmap]]<br />
**[[Development Tools]]<br />
**[[RoboCup Coding Style|Coding Style]]<br />
**[[Code Examples]]<br />
<br />
==== 2007 ====<br />
* [[RoboCupElectrical2007|Electrical System Information]]<br />
** [[RCpartsSample|How to Sample Parts for RoboCup]]<br />
* [[RoboCupSoftware2007|Software System Information]]<br />
* [[RoboCupMechanical2007|Mechanical System Information]]<br />
* [[RobocupVision|Vision System Information]]<br />
** [[RCVisSoftware|Robocup Image Processing]]<br />
** [[RCCamera|Robocup Image Acquisition]]<br />
* [[Image:TDP.pdf]]<br />
<br />
==Travel==<br />
*[[RC08Travel|Personal Travel Costs and Info]]<br />
*[[RC08TravelLog|Team Travel Logistics and Costs]]</div>Marksphttps://wiki.robojackets.org/index.php?title=RoboCup&diff=7637RoboCup2009-01-15T00:21:10Z<p>Marksp: /* Important Items */</p>
<hr />
<div>[[Image:Robocup.jpg|thumb|350px|right|Apologies Somethingawful.com]] <br />
<br />
==Important Items==<br />
* [[Meeting Minutes | Meeting Minutes<br />
* [http://small-size.informatik.uni-bremen.de/ Small Size League Website]<br />
* [[RCResources|RoboCup Resources for Learning]]<br />
* [[Resources for Learning]]<br />
* [[RC09Brainstorm|Long Term Ideas]]<br />
* [[RCPerformanceNum | Performance Numbers]]<br />
* [[Research Papers]]<br />
* [[Work_Plan_08-09 | Work Plan for Winter Break and Beyond]]<br />
<br />
== Systems ==<br />
==== 2009 ====<br />
* [[RCMeetingMinutes | RoboCup 2009 System Outline]]<br />
* [[RoboCup_Electrical_2009|Electrical System]]<br />
* [[RoboCup_Radio_2009|Radio Communication]]<br />
* [[RoboCup_Software_2009|Software System]]<br />
* [[RoboCupMechanical|Mechanical System Information]]<br />
<br />
==== 2008 ====<br />
*[[RC08General|General System Info / Resources]]<br />
*[[RoboCupElectrical|Electrical System]]<br />
*[[RoboCupMechanical2008|Mechanical System]]<br />
*[[RoboCupSoftware|Software System]]<br />
**[[RC08SWRoadMap|Short Term Software Roadmap]]<br />
**[[Development Tools]]<br />
**[[RoboCup Coding Style|Coding Style]]<br />
**[[Code Examples]]<br />
<br />
==== 2007 ====<br />
* [[RoboCupElectrical2007|Electrical System Information]]<br />
** [[RCpartsSample|How to Sample Parts for RoboCup]]<br />
* [[RoboCupSoftware2007|Software System Information]]<br />
* [[RoboCupMechanical2007|Mechanical System Information]]<br />
* [[RobocupVision|Vision System Information]]<br />
** [[RCVisSoftware|Robocup Image Processing]]<br />
** [[RCCamera|Robocup Image Acquisition]]<br />
* [[Image:TDP.pdf]]<br />
<br />
==Travel==<br />
*[[RC08Travel|Personal Travel Costs and Info]]<br />
*[[RC08TravelLog|Team Travel Logistics and Costs]]</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=761109 Leadership Mini-Retreat2009-01-12T01:57:35Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report<br />
<br />
<br />
==Notes==<br />
===Money===<br />
* Travel accounts for teams <br />
** Seperate Wachovia account<br />
===Mission Statement===<br />
* Using website to promote club more<br />
* Being spread out in mission allows to cover more ground<br />
* Less focused on competition - excuse to educate ourselves<br />
* It'd be boring to focus on one competition<br />
* People want to join each of the different groups not RoboJackets (People join to be a part of a team)<br />
* If we killed all the projects we'd lose members<br />
* Refocus on smaller projects for learning - The hobbyist group end of the spectrun<br />
* Competitions provide a set metric for impressiveness and a set goal<br />
* Personal projects on the side<br />
* We shouldn't focus hard on one thing because that limits us and new leaders may want to do other things<br />
* We are lacking in the small project category and they need to generate good demos for companies<br />
* Small projects have the light at the end of tunnel<br />
* But a deadline really motivates<br />
* We should post the constitution<br />
* Club forms around the people who are in it but mission statement is fluid enough for that<br />
===1 5 and 10 yr plan===<br />
==== 1 yr ====<br />
* More unity in the community<br />
* Better inventory<br />
==== 5 yr ====<br />
* More sponsors<br />
==== 10 yr ====<br />
* More Alumni<br />
* Better facility<br />
* New competitions<br />
* More support from the academic depts in the technical arena<br />
* We need to set-up a special problems class for RoboJackets in every dept<br />
* Class credit for RoboCup<br />
* Get set-up with RIM<br />
* Special problems is really loose. They can let anyone join<br />
* Work-in Dr. Ueda and others into group<br />
* Hobbyist and get credit<br />
* Deliverable like a paper would be good for us anyway<br />
* Kinda like research credit<br />
* RoboJackets Alumni Tailgates?<br />
* Have even a list of contact RoboJackets Alumni<br />
** Mailing list and contact info for Alumni<br />
==Project Management==<br />
* Can be solved by external powers like advisors<br />
* Crack the whip from advisors<br />
* No substitute for coming to meetings<br />
* Motivation problem - How to get people to realize that they will get something out of RoboJackets<br />
* Give people little things they can work on<br />
* If you don't know anything do the training and then come back<br />
* But some are motivated<br />
==Recruitment and member expectations and training==<br />
* Recruitment is not an issue, but more visibility on campus<br />
* We have no expectations out of members - they are expected to run away - self-fulling prophesy<br />
* Change what we do after initial recruitment<br />
* An interview (?)<br />
* New member placement<br />
* Team membership need report - split by task and complexity and task<br />
* Two ways to look at new members: Lack of confidence and lack of knowledge<br />
* Tell noobs to take courses - but not a good idea<br />
* Small projects and training<br />
* Project bank with 1 meeting goals and tangible outcomes<br />
* Pieces of large projects <br />
* Find the middle road<br />
* Using FIRST as training<br />
==Membership Retention==<br />
* Don't be ass-holes<br />
==Inventory==<br />
* A room for each tool<br />
* Paint outline of where tool goes<br />
* Numbering tools<br />
* Cut down the tool shelf for Andy cause he is too tall<br />
* Keep more mechanical tools in EE room and in designated areas<br />
* More accountability, make ppl clean up<br />
* Tool Nazi<br />
* A singular tool box <br />
* EE room pegboard is killed<br />
* Sometime in the summer in<br />
==Website==<br />
* Make website like a tech blog<br />
* Promo page <br />
* Easy to find list of meeting times<br />
* New members info page<br />
* Homepage is be more homepage<br />
* One id to rule them all<br />
* New wiki<br />
* Very short about us with links to sub groups and their pages<br />
* Pictures lots of pictures<br />
* Member resources section<br />
* Calender and news feed<br />
* Detail is in member section<br />
* Website is the main marketing<br />
* Something that we are proud enough to point future employers to</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=761009 Leadership Mini-Retreat2009-01-12T01:53:34Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report<br />
<br />
<br />
==Notes==<br />
===Money===<br />
* Travel accounts for teams <br />
** Seperate Wachovia account<br />
===Mission Statement===<br />
* Using website to promote club more<br />
* Being spread out in mission allows to cover more ground<br />
* Less focused on competition - excuse to educate ourselves<br />
* It'd be boring to focus on one competition<br />
* People want to join each of the different groups not RoboJackets (People join to be a part of a team)<br />
* If we killed all the projects we'd lose members<br />
* Refocus on smaller projects for learning - The hobbyist group end of the spectrun<br />
* Competitions provide a set metric for impressiveness and a set goal<br />
* Personal projects on the side<br />
* We shouldn't focus hard on one thing because that limits us and new leaders may want to do other things<br />
* We are lacking in the small project category and they need to generate good demos for companies<br />
* Small projects have the light at the end of tunnel<br />
* But a deadline really motivates<br />
* We should post the constitution<br />
* Club forms around the people who are in it but mission statement is fluid enough for that<br />
===1 5 and 10 yr plan===<br />
==== 1 yr ====<br />
* More unity in the community<br />
* Better inventory<br />
==== 5 yr ====<br />
* More sponsors<br />
==== 10 yr ====<br />
* More Alumni<br />
* Better facility<br />
* New competitions<br />
* More support from the academic depts in the technical arena<br />
* We need to set-up a special problems class for RoboJackets in every dept<br />
* Class credit for RoboCup<br />
* Get set-up with RIM<br />
* Special problems is really loose. They can let anyone join<br />
* Work-in Dr. Ueda and others into group<br />
* Hobbyist and get credit<br />
* Deliverable like a paper would be good for us anyway<br />
* Kinda like research credit<br />
* RoboJackets Alumni Tailgates?<br />
* Have even a list of contact RoboJackets Alumni<br />
** Mailing list and contact info for Alumni<br />
==Project Management==<br />
* Can be solved by external powers like advisors<br />
* Crack the whip from advisors<br />
* No substitute for coming to meetings<br />
* Motivation problem - How to get people to realize that they will get something out of RoboJackets<br />
* Give people little things they can work on<br />
* If you don't know anything do the training and then come back<br />
* But some are motivated<br />
==Recruitment and member expectations and training==<br />
* Recruitment is not an issue, but more visibility on campus<br />
* We have no expectations out of members - they are expected to run away - self-fulling prophesy<br />
* Change what we do after initial recruitment<br />
* An interview (?)<br />
* New member placement<br />
* Team membership need report - split by task and complexity and task<br />
* Two ways to look at new members: Lack of confidence and lack of knowledge<br />
* Tell noobs to take courses - but not a good idea<br />
* Small projects and training<br />
* Project bank with 1 meeting goals and tangible outcomes<br />
* Pieces of large projects <br />
* Find the middle road<br />
* Using FIRST as training<br />
==Membership Retention==<br />
* Don't be ass-holes<br />
==Inventory==<br />
* A room for each tool<br />
* Paint outline of where tool goes<br />
* Numbering tools<br />
* Cut down the tool shelf for Andy cause he is too tall<br />
* Keep more mechanical tools in EE room and in designated areas<br />
* More accountability, make ppl clean up<br />
* Tool Nazi<br />
* A singular tool box <br />
* EE room pegboard is killed<br />
* Sometime in the summer in<br />
==Website==<br />
* Make website like a tech blog<br />
* Promo page <br />
* Easy to find list of meeting times<br />
* New members info page<br />
* Homepage is be more homepage<br />
* One id to rule them all<br />
* New wiki<br />
* Very short about us with links to sub groups and their pages<br />
* Pictures lots of pictures<br />
* Member resources section<br />
* Calender and news feed<br />
* Detail is in member section<br />
* Website is the main marketing</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=760909 Leadership Mini-Retreat2009-01-12T01:44:20Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report<br />
<br />
<br />
==Notes==<br />
===Money===<br />
* Travel accounts for teams <br />
** Seperate Wachovia account<br />
===Mission Statement===<br />
* Using website to promote club more<br />
* Being spread out in mission allows to cover more ground<br />
* Less focused on competition - excuse to educate ourselves<br />
* It'd be boring to focus on one competition<br />
* People want to join each of the different groups not RoboJackets (People join to be a part of a team)<br />
* If we killed all the projects we'd lose members<br />
* Refocus on smaller projects for learning - The hobbyist group end of the spectrun<br />
* Competitions provide a set metric for impressiveness and a set goal<br />
* Personal projects on the side<br />
* We shouldn't focus hard on one thing because that limits us and new leaders may want to do other things<br />
* We are lacking in the small project category and they need to generate good demos for companies<br />
* Small projects have the light at the end of tunnel<br />
* But a deadline really motivates<br />
* We should post the constitution<br />
* Club forms around the people who are in it but mission statement is fluid enough for that<br />
===1 5 and 10 yr plan===<br />
==== 1 yr ====<br />
* More unity in the community<br />
* Better inventory<br />
==== 5 yr ====<br />
* More sponsors<br />
==== 10 yr ====<br />
* More Alumni<br />
* Better facility<br />
* New competitions<br />
* More support from the academic depts in the technical arena<br />
* We need to set-up a special problems class for RoboJackets in every dept<br />
* Class credit for RoboCup<br />
* Get set-up with RIM<br />
* Special problems is really loose. They can let anyone join<br />
* Work-in Dr. Ueda and others into group<br />
* Hobbyist and get credit<br />
* Deliverable like a paper would be good for us anyway<br />
* Kinda like research credit<br />
* RoboJackets Alumni Tailgates?<br />
* Have even a list of contact RoboJackets Alumni<br />
** Mailing list and contact info for Alumni<br />
==Project Management==<br />
* Can be solved by external powers like advisors<br />
* Crack the whip from advisors<br />
* No substitute for coming to meetings<br />
* Motivation problem - How to get people to realize that they will get something out of RoboJackets<br />
* Give people little things they can work on<br />
* If you don't know anything do the training and then come back<br />
* But some are motivated<br />
==Recruitment and member expectations and training==<br />
* Recruitment is not an issue, but more visibility on campus<br />
* We have no expectations out of members - they are expected to run away - self-fulling prophesy<br />
* Change what we do after initial recruitment<br />
* An interview (?)<br />
* New member placement<br />
* Team membership need report - split by task and complexity and task<br />
* Two ways to look at new members: Lack of confidence and lack of knowledge<br />
* Tell noobs to take courses - but not a good idea<br />
* Small projects and training<br />
* Project bank with 1 meeting goals and tangible outcomes<br />
* Pieces of large projects <br />
* Find the middle road<br />
* Using FIRST as training<br />
==Membership Retention==<br />
* Don't be ass-holes<br />
==Inventory==<br />
* A room for each tool<br />
* Paint outline of where tool goes<br />
* Numbering tools<br />
* Cut down the tool shelf for Andy cause he is too tall<br />
* Keep more mechanical tools in EE room and in designated areas<br />
* More accountability, make ppl clean up<br />
* Tool Nazi<br />
* A singular tool box <br />
* EE room pegboard is killed<br />
* Sometime in the summer in</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=760809 Leadership Mini-Retreat2009-01-12T01:30:58Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report<br />
<br />
<br />
==Notes==<br />
===Money===<br />
* Travel accounts for teams <br />
** Seperate Wachovia account<br />
===Mission Statement===<br />
* Using website to promote club more<br />
* Being spread out in mission allows to cover more ground<br />
* Less focused on competition - excuse to educate ourselves<br />
* It'd be boring to focus on one competition<br />
* People want to join each of the different groups not RoboJackets (People join to be a part of a team)<br />
* If we killed all the projects we'd lose members<br />
* Refocus on smaller projects for learning - The hobbyist group end of the spectrun<br />
* Competitions provide a set metric for impressiveness and a set goal<br />
* Personal projects on the side<br />
* We shouldn't focus hard on one thing because that limits us and new leaders may want to do other things<br />
* We are lacking in the small project category and they need to generate good demos for companies<br />
* Small projects have the light at the end of tunnel<br />
* But a deadline really motivates<br />
* We should post the constitution<br />
* Club forms around the people who are in it but mission statement is fluid enough for that<br />
===1 5 and 10 yr plan===<br />
==== 1 yr ====<br />
* More unity in the community<br />
* Better inventory<br />
==== 5 yr ====<br />
* More sponsors<br />
==== 10 yr ====<br />
* More Alumni<br />
* Better facility<br />
* New competitions<br />
* More support from the academic depts in the technical arena<br />
* We need to set-up a special problems class for RoboJackets in every dept<br />
* Class credit for RoboCup<br />
* Get set-up with RIM<br />
* Special problems is really loose. They can let anyone join<br />
* Work-in Dr. Ueda and others into group<br />
* Hobbyist and get credit<br />
* Deliverable like a paper would be good for us anyway<br />
* Kinda like research credit<br />
* RoboJackets Alumni Tailgates?<br />
* Have even a list of contact RoboJackets Alumni<br />
** Mailing list and contact info for Alumni<br />
==Project Management==<br />
* Can be solved by external powers like advisors<br />
* Crack the whip from advisors<br />
* No substitute for coming to meetings<br />
* Motivation problem - How to get people to realize that they will get something out of RoboJackets<br />
* Give people little things they can work on<br />
* If you don't know anything do the training and then come back<br />
* But some are motivated<br />
==Recruitment and member expectations and training==<br />
* Recruitment is not an issue, but more visibility on campus<br />
* We have no expectations out of members - they are expected to run away - self-fulling prophesy<br />
* Change what we do after initial recruitment<br />
* An interview (?)<br />
* New member placement<br />
* Team membership need report - split by task and complexity and task<br />
* Two ways to look at new members: Lack of confidence and lack of knowledge<br />
* Tell noobs to take courses - but not a good idea<br />
* Small projects and training<br />
* Project bank with 1 meeting goals and tangible outcomes<br />
* Pieces of large projects <br />
* Find the middle road<br />
* Using FIRST as training<br />
==</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=760709 Leadership Mini-Retreat2009-01-12T01:23:55Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report<br />
<br />
<br />
==Notes==<br />
===Money===<br />
* Travel accounts for teams <br />
** Seperate Wachovia account<br />
=== Mission Statement ===<br />
* Using website to promote club more<br />
* Being spread out in mission allows to cover more ground<br />
* Less focused on competition - excuse to educate ourselves<br />
* It'd be boring to focus on one competition<br />
* People want to join each of the different groups not RoboJackets (People join to be a part of a team)<br />
* If we killed all the projects we'd lose members<br />
* Refocus on smaller projects for learning - The hobbyist group end of the spectrun<br />
* Competitions provide a set metric for impressiveness and a set goal<br />
* Personal projects on the side<br />
* We shouldn't focus hard on one thing because that limits us and new leaders may want to do other things<br />
* We are lacking in the small project category and they need to generate good demos for companies<br />
* Small projects have the light at the end of tunnel<br />
* But a deadline really motivates<br />
* We should post the constitution<br />
* Club forms around the people who are in it but mission statement is fluid enough for that<br />
=== 1 5 and 10 yr plan ===<br />
==== 1 yr ====<br />
* More unity in the community<br />
* Better inventory<br />
==== 5 yr ====<br />
* More sponsors<br />
==== 10 yr ====<br />
* More Alumni<br />
* Better facility<br />
* New competitions<br />
* More support from the academic depts in the technical arena<br />
* We need to set-up a special problems class for RoboJackets in every dept<br />
* Class credit for RoboCup<br />
* Get set-up with RIM<br />
* Special problems is really loose. They can let anyone join<br />
* Work-in Dr. Ueda and others into group<br />
* Hobbyist and get credit<br />
* Deliverable like a paper would be good for us anyway<br />
* Kinda like research credit<br />
* RoboJackets Alumni Tailgates?<br />
* Have even a list of contact RoboJackets Alumni<br />
** Mailing list and contact info for Alumni<br />
== Project Management ==<br />
* Can be solved by external powers like advisors<br />
* Crack the whip from advisors<br />
* No substitute for coming to meetings<br />
* Motivation problem - How to get people to realize that they will get something out of RoboJackets<br />
* Give people little things they can work on<br />
* If you don't know anything do the training and then come back<br />
* But some are motivated<br />
== Recruitment and member expectations and training<br />
* Recruitment is not an issue, but more visibility on campus<br />
* We have no expectations out of members - they are expected to run away - self-fulling prophesy<br />
* Change what we do after initial recruitment<br />
* An interview (?)<br />
* New member placement<br />
* Team membership need report - split by task and complexity and task<br />
* Two ways to look at new members: Lack of confidence and lack of knowledge<br />
* Tell noobs to take courses - but not a good idea<br />
* Small projects and training<br />
* Project bank with 1 meeting goals and tangible outcomes<br />
* Pieces of large projects <br />
* Find the middle road</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=760609 Leadership Mini-Retreat2009-01-12T01:18:39Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report<br />
<br />
<br />
==Notes==<br />
===Money===<br />
* Travel accounts for teams <br />
** Seperate Wachovia account<br />
=== Mission Statement ===<br />
* Using website to promote club more<br />
* Being spread out in mission allows to cover more ground<br />
* Less focused on competition - excuse to educate ourselves<br />
* It'd be boring to focus on one competition<br />
* People want to join each of the different groups not RoboJackets (People join to be a part of a team)<br />
* If we killed all the projects we'd lose members<br />
* Refocus on smaller projects for learning - The hobbyist group end of the spectrun<br />
* Competitions provide a set metric for impressiveness and a set goal<br />
* Personal projects on the side<br />
* We shouldn't focus hard on one thing because that limits us and new leaders may want to do other things<br />
* We are lacking in the small project category and they need to generate good demos for companies<br />
* Small projects have the light at the end of tunnel<br />
* But a deadline really motivates<br />
* We should post the constitution<br />
* Club forms around the people who are in it but mission statement is fluid enough for that<br />
=== 1 5 and 10 yr plan ===<br />
==== 1 yr ====<br />
* More unity in the community<br />
* Better inventory<br />
==== 5 yr ====<br />
* More sponsors<br />
==== 10 yr ====<br />
* More Alumni<br />
* Better facility<br />
* New competitions<br />
* More support from the academic depts in the technical arena<br />
* We need to set-up a special problems class for RoboJackets in every dept<br />
* Class credit for RoboCup<br />
* Get set-up with RIM<br />
* Special problems is really loose. They can let anyone join<br />
* Work-in Dr. Ueda and others into group<br />
* Hobbyist and get credit<br />
* Deliverable like a paper would be good for us anyway<br />
* Kinda like research credit<br />
* RoboJackets Alumni Tailgates?<br />
* Have even a list of contact RoboJackets Alumni<br />
** Mailing list and contact info for Alumni<br />
== Project Management ==<br />
* Can be solved by external powers like advisors<br />
* Crack the whip from advisors<br />
* No substitute for coming to meetings<br />
* Motivation problem - How to get people to realize that they will get something out of RoboJackets<br />
* Give people little things they can work on<br />
* If you don't know anything do the training and then come back<br />
* But some are motivated<br />
== Recruitment and member expectations and training<br />
* Recruitment is not an issue, but more visibility on campus<br />
* We have no expectations out of members - they are expected to run away - self-fulling prophesy<br />
* Change what we do after initial recruitment<br />
* An interview (?)<br />
* New member placement<br />
* Team membership need report - split by task and complexity and task<br />
* Two ways to look at new members: Lack of confidence and lack of knowledge<br />
* Tell noobs to take courses - but not a good idea<br />
* Small projects and training<br />
* Project bank with 1 meeting goals and tangible outcomes<br />
* Pieces of large projects <br />
*</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=760509 Leadership Mini-Retreat2009-01-12T00:26:26Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report<br />
<br />
<br />
==Notes==<br />
===Money===<br />
* Travel accounts for teams <br />
** Seperate Wachovia account<br />
=== Mission Statement ===<br />
* Using website to promote club more<br />
* Being spread out in mission allows to cover more ground<br />
* Less focused on competition - excuse to educate ourselves<br />
* It'd be boring to focus on one competition<br />
* People want to join each of the different groups not RoboJackets (People join to be a part of a team)<br />
* If we killed all the projects we'd lose members<br />
* Refocus on smaller projects for learning - The hobbyist group end of the spectrun<br />
* Competitions provide a set metric for impressiveness and a set goal<br />
* Personal projects on the side<br />
* We shouldn't focus hard on one thing because that limits us and new leaders may want to do other things<br />
* We are lacking in the small project category and they need to generate good demos for companies<br />
* Small projects have the light at the end of tunnel<br />
* But a deadline really motivates<br />
* We should post the constitution<br />
* Club forms around the people who are in it but mission statement is fluid enough for that<br />
=== 1 5 and 10 yr plan ===<br />
==== 1 yr ====<br />
* More unity in the community<br />
* Better inventory<br />
==== 5 yr ====<br />
* More sponsors<br />
==== 10 yr ====<br />
* More Alumni<br />
* Better facility<br />
* New competitions<br />
* More support from the academic depts in the technical arena<br />
* We need to set-up a special problems class for RoboJackets in every dept<br />
* Class credit for RoboCup<br />
* Get set-up with RIM<br />
* Special problems is really loose. They can let anyone join<br />
* Work-in Dr. Ueda and others into group<br />
* Hobbyist and get credit<br />
* Deliverable like a paper would be good for us anyway<br />
* Kinda like research credit<br />
* RoboJackets Alumni Tailgates?<br />
* Have even a list of contact RoboJackets Alumni<br />
** Mailing list and contact info for Alumni<br />
== Project Management ==<br />
*</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=760409 Leadership Mini-Retreat2009-01-12T00:05:38Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report<br />
<br />
<br />
==Notes==<br />
===Money===<br />
* Travel accounts for teams <br />
** Seperate Wachovia account<br />
=== Mission Statement ===<br />
* Using website to promote club more<br />
* Being spread out in mission allows to cover more ground<br />
* Less focused on competition - excuse to educate ourselves<br />
* It'd be boring to focus on one competition<br />
* People want to join each of the different groups not RoboJackets (People join to be a part of a team)<br />
* If we killed all the projects we'd lose members<br />
* Refocus on smaller projects for learning - The hobbyist group end of the spectrun<br />
* Competitions provide a set metric for impressiveness and a set goal<br />
* Personal projects on the side<br />
* We shouldn't focus hard on one thing because that limits us and new leaders may want to do other things<br />
* We are lacking in the small project category and they need to generate good demos for companies<br />
* Small projects have the light at the end of tunnel<br />
* But a deadline really motivates<br />
* We should post the constitution<br />
* Club forms around the people who are in it but mission statement is fluid enough for that</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=759709 Leadership Mini-Retreat2009-01-08T21:04:31Z<p>Marksp: /* Format */</p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=759609 Leadership Mini-Retreat2009-01-08T21:04:18Z<p>Marksp: /* Introduction */</p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=759509 Leadership Mini-Retreat2009-01-08T21:03:53Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=759409 Leadership Mini-Retreat2009-01-08T21:00:52Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
*test<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=759309 Leadership Mini-Retreat2009-01-08T21:00:23Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
** Moderator: Paul V.<br />
** Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
** Mick<br />
** Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
** Janki<br />
** Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
** Phillip<br />
** Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
** Jevawn<br />
** Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
** Roman<br />
** Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
** BB's Jeremy<br />
** Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
** Jake<br />
** Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
** Stefan<br />
** Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
** Andy<br />
** Project: Wiki and website facelift<br />
* How can we build better bots?<br />
** Aakash<br />
** Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
** Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
** Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
** Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
** Phillip may take this one if not picked up<br />
** Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
** Project: Recommendation report</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=759209 Leadership Mini-Retreat2009-01-08T20:58:01Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==<br />
One of the best forums for discussing many ideas amongst several equal parties is the round-table discussion. But often these sort of discussions can drag on for hours on end, especially when several topics are brought up and the participants are highly opinionated. One way to curb this issue is to impose a time limit on each topic. And one example of this sort of time-limited round-table is the ESPN show "Pardon the Interruption." (For those who don't watch ESPN go to [http://en.wikipedia.org/wiki/Pardon_the_interruption here] and watch [http://www.youtube.com/watch?v=Td9bnXqD-UQ here]) Each of the participants has been given one of the topics below and will moderate an 8 - 10 minute discussion on that topic taking notes of what was said. A buzzer will be used to signal when its time to switch topics. <br />
<br><br />
After the retreat each participant will take their topic and turn it into a semester long project. At the end of the semester we will celebrate the successful completion of each project!<br />
<br />
==Topics==<br />
* Financial Software<br />
o Moderator: Paul V.<br />
o Project: Implement a new financial system<br />
* Who are the RoboJackets: Competitors, Volunteers/Mentors, Hobbyists, or all three? <br />
o Mick<br />
o Project: 2009 Mission statement and its promotion <br />
* Where do we see the club in 1, 5, even 10 years?<br />
o Janki<br />
o Project: 1 and 5yr plans<br />
* What are some of the best ways to manage our projects and project teams?<br />
o Phillip<br />
o Project: Team leader handbook/wiki<br />
* How can we recruit new members and what are our requirements/expectations ?<br />
o Jevawn<br />
o Project: Consult on a member handbook/wiki and recruitment<br />
* How can we make training accessible to members while keeping it easy to implement?<br />
o Roman<br />
o Project: Outline of topics for training. Training schedule and program<br />
* What keeps them coming back from more? Membership retention<br />
o BB's Jeremy<br />
o Project: New member handbook/wiki, recruitment, new member meetings<br />
* Managing our assets: Keeping track of our stuff and tool policy<br />
o Jake<br />
o Project: Asset management system<br />
* How would we spend $1,000,000,000? The RJ wishlist<br />
o Stefan<br />
o Project: Improvements to ME and EE rooms, wishlist<br />
* How can we make better use of the wiki and website<br />
o Andy<br />
o Project: Wiki and website facelift<br />
* How can we build better bots?<br />
o Aakash<br />
o Project: Report on current robots and what can be done to make them better<br />
<br />
Some other topics if you don't really like yours<br />
<br />
* Club organization and creation of new positions<br />
o Project: Org chart with listing of each positions responsibilities<br />
* How can we build better bots?<br />
o Project: Report on current robots and what can be done to make them better<br />
* What makes RoboJackets fun?<br />
o Project: Making RoboJackets even more fun for more ppl<br />
* Growing new leaders<br />
o Phillip may take this one if not picked up<br />
o Project: Leadership Dev Kit<br />
* How can we meet deadlines?<br />
o Project: Recommendation report</div>Marksphttps://wiki.robojackets.org/index.php?title=09_Leadership_Mini-Retreat&diff=759009 Leadership Mini-Retreat2009-01-08T20:31:31Z<p>Marksp: </p>
<hr />
<div>==Introduction==<br />
Over the years lots of ideas have been thrown around in club. Some are good, some needed work, and some (mainly the ones involving sex toys and babies) are hilariously absurd. Sometimes these ideas get put action, and sometimes they fall to wayside. <br />
<br><br />
For the 2009 Leadership Mini-Retreat we will discuss some ideas, some of which have been brought up before and some totally new. Then we will put those ideas to action!<br />
<br />
==Format==</div>Marksphttps://wiki.robojackets.org/index.php?title=Main_Page&diff=7589Main Page2009-01-08T20:19:06Z<p>Marksp: </p>
<hr />
<div>__NOTOC__<br />
{|<br />
! colspan="2" valign="bottom" | <br />
<br />
'''''RoboJackets Wiki'''''<br />
! width="20%" rowspan="6" valign="top" | <br />
[[Image:Robojackets.jpg|200px|center]]<br/><br />
'''The Georgia Tech RoboJackets'''<br/><br />
'''http://www.robojackets.org'''<br/><br />
<br />
|- <br />
| colspan="2" | Welcome to the '''[http://www.gatech.edu/ Georgia Tech]''' '''[http://www.robojackets.org/ RoboJackets]''' wiki! We are currently looking for both volunteers and sponsors. More info can be found on the [[How you can help]] page. Feel free to contact an [[Admins | admin]] if you have any questions about this site. <br />
<br />
<br />
|- <br />
! width="40%" valign="top" | Teams & Projects<br />
! width="40%" valign="top" | Resources<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[FIRST]]<br />
* [[IGVC]]<br />
* [[RoboCup]]<br />
* [[BattleBots]]<br />
* [[TE Sessions|Technology Enrichment (TE) Sessions]]<br />
---<br />
* [[HexaPod]]<br />
* [[IKArm|Inverse Kinematic (IK) Arm]]<br />
* [[Downhill Car]]<br/><br />
<br />
| width="40%" valign="top" | <br />
* ''[[New Users]]'' <br />
* [[How to Guides]]<br />
* [[Help:Editing|Editing Help]]<br />
* [[Resources for Learning]]<br />
* [[Training Sessions]]<br />
* [[Project Ideas]]<br />
* [[Research]]<br />
* ''[[Current events|Current Events]]''<br />
<br />
<br />
|- <br />
! width="40%" | Internal RJ Info<br />
! width="40%" | Current Important - WIP Pages<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[09 Leadership Mini-Retreat]]<br />
* ''[[Meeting Minutes]]''<br />
* ''[[List_of_People|List of people]]''<br />
* ''[[Spring_Cleaning | Spring Cleaning]]''<br />
* [[Yearly Housekeeping]]<br />
* [[Club TODO List]]<br />
* [[Records]]<br />
* [[Public_Relations|Public Relations]]<br />
* [[Promotional Media]]<br />
* [[Server]]<br />
* [[Contact List]]<br />
* [[Sponsor List]]<br />
* [[Equipment List]]<br />
<br />
| width="40%" valign="top"| <br />
* ''[[How to Guides]]''<br />
* [[Subversion]]<br />
* [[Wtodo|Wiki and Server TODO]] Wiki and server feature requests<br />
* [[Info|RoboJackets Information]]<br />
|}</div>Marksphttps://wiki.robojackets.org/index.php?title=Special:Badtitle/NS100:Equipment_List&diff=7588Special:Badtitle/NS100:Equipment List2009-01-07T21:32:26Z<p>Marksp: </p>
<hr />
<div>===Equipment On Loan===<br />
====5 Vex Kits 01/7/2008====<br />
* Given to Vinton Wolfe<br />
* Address: Henry W. Grady High School 929 Charles Allen Drive NE Atlanta, Ga 30309<br />
* Phone (Cell) : 404-695-4804<br />
* SN RJ 1001-5</div>Marksphttps://wiki.robojackets.org/index.php?title=Main_Page&diff=7587Main Page2009-01-07T21:21:57Z<p>Marksp: </p>
<hr />
<div>__NOTOC__<br />
{|<br />
! colspan="2" valign="bottom" | <br />
<br />
'''''RoboJackets Wiki'''''<br />
! width="20%" rowspan="6" valign="top" | <br />
[[Image:Robojackets.jpg|200px|center]]<br/><br />
'''The Georgia Tech RoboJackets'''<br/><br />
'''http://www.robojackets.org'''<br/><br />
<br />
|- <br />
| colspan="2" | Welcome to the '''[http://www.gatech.edu/ Georgia Tech]''' '''[http://www.robojackets.org/ RoboJackets]''' wiki! We are currently looking for both volunteers and sponsors. More info can be found on the [[How you can help]] page. Feel free to contact an [[Admins | admin]] if you have any questions about this site. <br />
<br />
<br />
|- <br />
! width="40%" valign="top" | Teams & Projects<br />
! width="40%" valign="top" | Resources<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* [[FIRST]]<br />
* [[IGVC]]<br />
* [[RoboCup]]<br />
* [[BattleBots]]<br />
* [[TE Sessions|Technology Enrichment (TE) Sessions]]<br />
---<br />
* [[HexaPod]]<br />
* [[IKArm|Inverse Kinematic (IK) Arm]]<br />
* [[Downhill Car]]<br/><br />
<br />
| width="40%" valign="top" | <br />
* ''[[New Users]]'' <br />
* [[How to Guides]]<br />
* [[Help:Editing|Editing Help]]<br />
* [[Resources for Learning]]<br />
* [[Training Sessions]]<br />
* [[Project Ideas]]<br />
* [[Research]]<br />
* ''[[Current events|Current Events]]''<br />
<br />
<br />
|- <br />
! width="40%" | Internal RJ Info<br />
! width="40%" | Current Important - WIP Pages<br />
<br />
|- <br />
| width="40%" valign="top" | <br />
* ''[[Meeting Minutes]]''<br />
* ''[[List_of_People|List of people]]''<br />
* ''[[Spring_Cleaning | Spring Cleaning]]''<br />
* [[Yearly Housekeeping]]<br />
* [[Club TODO List]]<br />
* [[Records]]<br />
* [[Public_Relations|Public Relations]]<br />
* [[Promotional Media]]<br />
* [[Server]]<br />
* [[Contact List]]<br />
* [[Sponsor List]]<br />
* [[Equipment List]]<br />
<br />
| width="40%" valign="top"| <br />
* ''[[How to Guides]]''<br />
* [[Subversion]]<br />
* [[Wtodo|Wiki and Server TODO]] Wiki and server feature requests<br />
* [[Info|RoboJackets Information]]<br />
|}</div>Marksphttps://wiki.robojackets.org/index.php?title=FIRST&diff=7580FIRST2009-01-06T23:15:41Z<p>Marksp: /* Meeting Minutes */</p>
<hr />
<div>The goal of the FIRST team is to help mentor and train k-12 students in various fields of engineering and science. We work directly with a local high school team to design and build a robot that adheres to the FIRST competition rules and then compete at regional events with it.<br />
<br />
===Team Leaders===<br />
* Jevawn Roberts<br />
* Jeremy Roberts<br />
* Mick Roper<br />
<br />
===Positions===<br />
* Mechanical Lead<br />
* Programming<br />
* Electrical<br />
* Tools/Parts/Fabrication<br />
<br />
==Resources==<br />
Need any help try glancing at these resources:<br />
* [[FIRST Resources]]<br />
* [[TE Sessions]]<br />
* [[FIRST_Kickoff]]<br />
<br />
==FIRST Pages==<br />
* [[FRC Beta | Public FRC Beta information]]<br />
* [[FRC Beta Internal | Internal FRC Beta information]]<br />
<br />
==Meeting Minutes==<br />
*[[FIRST Meeting 01-06-2008|01-06-2008]]<br />
*[[:Image:08PowerPoint.pdf|11-07-20008 PowerPoint (PDF)]]<br />
*[[FIRST Meeting 09-11-2008|09-11-2008]]</div>Marksphttps://wiki.robojackets.org/index.php?title=RoboCup_Simulator&diff=7569RoboCup Simulator2009-01-05T01:09:12Z<p>Marksp: </p>
<hr />
<div><br />
==64 bit==<br />
* perform the following actions to be able to compile for a 64bit system<br />
# ''sudo dpkg -i --force-architecture libphysx-*''<br />
# ''sudo aptitude install libc6-dev-i386''<br />
# ''sudo aptitude install g++-multilib''<br />
# ''sudo aptitude install ia32-libs''<br />
# ''if you don't have a libQtOpenGL library in /usr/lib32, get it from a 32bit deb''<br />
# make symbolic links to libraries in /usr/lib32<br />
#* ''ln -s libQtOpenGL.so.4 libQtOpenGL.so''<br />
#* ''ln -s libQtCore.so.4 libQtCore.so''<br />
#* ''ln -s libQtGui.so.4 libQtGui.so''<br />
#* ''ln -s libQtXml.so.4 libQtXml.so''<br />
#* ''ln -s libQtNetwork.so.4 libQtNetwork.so''<br />
#* ''ln -s libGLU.so.1 libGLU.so''<br />
#* ''ln -s libGL.so.1 libGL.so''<br />
#* ''ln -s libXext.so.6 libXext.so''<br />
#* ''ln -s libX11.so.6 libX11.so''<br />
<br />
==Links==<br />
[http://awakenedmmo.org/docs/physx/html/index.html PhysX Documentation]</div>Marksp