Difference between revisions of "Stronghold Meeting - 13-Jan-2016"

Revision as of 20:18, 27 January 2016

<< PREVIOUS -- NEXT>>

Competition Season Meeting

CAD & Design

-The discussion between wheels and treads continues, as we have contacted a person in Oregon who has used a tank tread design successfully for years in FRC. He sent us his CAD for the treads, which was an excellent starting point for designing our own tread drive. Tread sourcing has also been discussed, with a few ideas for sourcing noted. One of which is a steel-reinforced rubber tread that costs ~$150, matching the cost-per-side when compared to an 8 wheel drivetrain.

-The deadline for the drivetrain Crayola CAD is here, and the geometry for the 8 wheel drive does work for all Category B and D defenses. The 6+4 drivetrain geometry also works for the defenses. Some questions still remain:

• How do the 8 wheel drive and 6+4 drivetrain fare in real life?
• Are we okay with having the four extra wheels in the 6+4 drivetrain be unpowered? And, the big one:
• Which will be our drivetrain this season: 8 wheel drive, 6+4 drive, or treads?

Mechanical

-The single-axle wheeled shooter's back plate was changed in an attempt to increase shooter performance, but failed to produce enough height and distance to reach the high goal. A double-axle shooter was brought up as an improved revision and construction began.

Programming

- A guest speaker came to speak with the Programming team. He is an expert on git.

-With the large increase in programmers this year, we were hoping to develop a better, more robust system for git to allow multiple projects to be completed at once. Branches are the perfect solution for this.

-Since we already knew the basics of git, he started by explaining branches. He went through the syntax for creating and merging branches.

-He also explained how git deals with merge conflicts, and how we can resolve them.

-Additionally, he explained two branching architectures that he has worked with. Both of them allowed for one branch to remain the "competition" branch, that holds only working code. There would then also be additional branches for features and debugging.

-The first of the architectures included merging the competition branch back onto a completed feature branch, before merging the feature onto the master. This would allow teams to work out merge conflicts on the feature branches, instead of the competition branch.

-The second architecture called for an extra branch called the integration branch that the feature branches would merge into when complete. This branch would be an exact copy of the competition branch, and any merge conflicts could be solved on this branch. Then, the integration would be merged into the master.

-We decided to use the first architecture, since it allowed for more flexibility when two projects were completed at the same time.

-He also covered how often we should commit. In a normal project, he would have advised only to commit working code. However, since our robot project has such a short timeline, and since not everyone is present at every meeting, it is most efficient for everyone to commit the code before leaving the meeting.

-This presentation was very informative and allowed us to discuss exactly how to run the programming team this year. With his ideas, we have created a much better architecture for git this year.

Strategy

Field Elements

-The rough terrain base was completed, but it still needs all of the terrain pieces.

Other

<< PREVIOUS -- NEXT>>