IEEERobotics / bot

Robot code for 2014.
BSD 2-Clause "Simplified" License
18 stars 11 forks source link

Developing a timeline for next year #369

Open SeanKetring opened 9 years ago

SeanKetring commented 9 years ago

We need to decide how to schedule the development of next years bot. If we decide to do a gant chart then we will need to develop this and update it periodically.

whiteskulleton commented 9 years ago

I have a few ideas on how this can be accomplished and I have done some research into this. First off: Why do we need a schedule? Scopes out tasks - A schedule outlines priorities and helps everyone understand what they are going to do and what it takes to complete a task. The first year I did robotics I honestly believed you only needed about 2 weeks to program the robot for competition. A schedule will help clear things up and prevent this from happening again. Prevent future problems - It gives us the ability to look further into the future and realize where problems can happen and it gives us time to prepare for upcoming issues. Improves communication - With a schedule we understand where we are falling short in our tasks and it indicates that we need help. It then opens up channels of communication allows us to take appropriate action before things get worse. Illustrates high risk problems - A good scope can prevent "easy tasks" from becoming more complex ones. For example, if the wheels are falling off the robot, an easy solution is to add Loctite to the set screws. However, sometimes a simple fix doesn't work and now an "easy task" has created a big problem and prevented others from getting work done. Sense of urgency - A few months before the last competition I kept hearing that we were on the "critical path" and that we really needed to get work done or we were not going to make it to competition. We had a few months before competition so I didn't believe that we were in a lot of trouble. If we had a schedule laid out, we would be able to quantify whether or not we are in trouble a lot earlier rather than realizing it at the last few weeks before competition. It then makes people realize, "hey, I need to get my task done." Looks more professional - A schedule can also be an incentive for others to join the club. It gives people experience in time management and managing projects which they can talk about for job interviews.

I love visual things and so I have created an academic calendar with Excel and highlighted some dates of importance. This calendar can be used to help guide us in making a schedule. calendar The "hard dates" indicate the beginning of each semester and the robotics competition date. They represent dates that will not change.

Here are some ideas for systems we can use Github The great thing about Github is that you can view it from anywhere and it is public and so it is convenient to use. Some of the issues with this system is that Github does not visualize the schedule and you're left with a bunch of issues that are mixed up but they can be filtered. I am afraid it won't give a clear enough picture of priorities and time management.

Another idea is a Gantt chart. This will offer a great visualization but it might be too hard to maintain.

I found this: https://github.com/neyric/gh-issues-gantt This looks very good but I have no clue how to install it. I looked at the instructions but have no idea what I am doing. Can someone please try and install this and then guide me through how to install this so I can take a look at what this is?

I have also found these things for other ideas: https://github.com/rauhryan/huboard https://waffle.io/

AhmedSamara commented 9 years ago

The first year I did robotics I honestly believed you only needed about 2 weeks to program the robot for competition. A schedule will help clear things up and prevent this from happening again.

I don't think a schedule will solve this problem.
There was never any ambiguity about how long all this would take, it was discussed at every single meeting and programmers were working on it all year. Even without paying attention to meetings (or even going to them) issues were constantly being updated and posted (this was in the golden age of the club, there was no shortage).

The bigger problem is that people don't pay attention during meetings, or post/respond to issues as they have updates or keep up with any of the others. Even the relatively low-maintenance system we have no is severely under-utilized, and introducing something where the tasks and schedule are located at a different place and requires much more active maintenance will absolutely not solve the problem.

AhmedSamara commented 9 years ago

So after all of the discussions: I think the best solution is to use more milestones. In the past we've only had a few catch-all milestones (end-of-summer, base functionality, etc), but I think we should switch to more specific ones.
For example: "Moving bot" would be a basic one. "Working localization" would be a later goal which would include Lidar, dead-mouse, and US localization, and so on.

A good start would be to continue creating issues for tasks that we know will need to be done. I am in favor of leaving 'solution specific' tasks for the fall, but writting issues with nothing but the problem statement is also acceptable (things like "find way to grip blocks") can and should be posted (this way the discussions on them can be documented for posterity).
Please follow this format when writing them. You can change it up if you want, but please provide information in your posts.

@whiteskulleton .
You can go ahead and start writing tasks and milestones first.

These can all be written seperately, but leave the milestones without due dates for now. We will add them once we meet again in the fall to discuss what needs to be in what order.

AhmedSamara commented 9 years ago

I've also created a label for "problem statement".

This can be used for things that aren't necessarily specific tasks or issues, just things that we know we'll have to solve. ie: Things like "Figure out way to play simon says" (from the 2015 competition) would be a good topic, which we can use to keep track of ideas and brain storming.

AhmedSamara commented 9 years ago

On a related note:

Here is the calendar for the club. Right now it only has meeting times, but once we have a timeline for milestones we'll add this too.

https://www.google.com/calendar/embed?src=bmNzdS5lZHVfazY1dm5lZTBjcHQ5cmhvbTlzOGQ4dGlna3NAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

Please bookmark this. There is also a link at the top of the readme.

AhmedSamara commented 8 years ago

Everyone, especially veteran members, it's time to start coming up with milestones.
It's important to remember that these milestones should be things that are specific enough to have goals, but vague enough to not be making design decisions.

Examples of things I think we should have as milestones:

SeanKetring commented 8 years ago

Tentative time line and task list:

Jan 1st milestone Base Functionality -Deliverables: 1)Drivable chassis 2)Bot power system in place 3)Data collection from all sensors/mounted to the bot 4)Able to grab one block

Task breakdown

1)Drivable Chassis 1.a)Development and improvement of drive train 1.a.1)Selection of motors and mounting hardware (see google drive document 'motors') 1.a.1.i)Final decision on whether or not to use mechanin wheels 1.a.1.ii)Finding motors with working encoders 1.b) Building a CAD model of lower & upper bot 1.c)Building chassis from open beam to meet competition specs 1.c.1)Connecting the pieces of open beam together to form the bot skeleton 1.c.2) Mounting the drive train to open beam platform 1.c.3) Mounting wheels to drive train 1.d)Mounting of bare bones electronics 1.d.1)Mounting of microsctack including bone, and motor capes 1.d.2)Mounting crude power system 1.d.2.i)Mounting battery holder 1.d.2.ii)Mounting switch panel & power pcb 1.d.2.iii)Making wire 1.d.2.iv)Routing connections 1.d.2.v)Documentation and uploading of said documentation to wiki 1.d.3)Mounting wireless communications systems

Task one deadline: Middle of October

2) Bot Power 2.a)Completing dark power 2.a.1)Possible Board Revision 2.a.2)Board population 2.a.3)Design verification 2.a.3.i) Development of comprehensive testing scheme 2.a.3.ii) Testing of circuit 2.a.4)User friendly Interface diagram 2.b)Completing servo cape 2.b.1)Possible board revision 2.b.2)Board population 2.b.3)Design verification 2.b.3.i)Development of comprehensive testing scheme 2.b.3.ii)Testing of circuit 2.b.4)User friendly Interface diagram 2.c)Calculate power load of a fully functioning bot, as a precaution 2.c.1) Literature review on how to do calculation 2.c.2)Documenting calculations on github wiki 2.d)Wiring of bot and development of bot diagrams 2.d.1)Making wires 2.d.2)Routing connections 2.d.3)Documenting and creating a wiring diagram 2.d.4)Uploading the documentation to the github wiki

Task 2 Deadline: End of Thanksgiving break

3) Sensor functionality and data collection 3.a)Locallization w/ Lidar 3.a.1)Testing of LIDAR functionality 3.a.1.i)Analyzing/observation of data stream 3.a.1.ii)Deconstruction of packet 3.a.1.iii)Parsing of data on beagle bone platform 3.b)QR Reading 3.b.1) Literature review of sensor options 3.b.2) Selection of sensor and ordering hardware 3.b.3) Bench of QR reader 3.b.4) Parsing of data from QR reader on Beagle bone platform 3.c)Detection of start signal 3.c.1)Literature review of start signal specs 3.c.2)Literature of hardware for signal detection 3.c.3)Selection and Ordering of hardware 3.c.4)Bench test of start signal detection 3.c.4.i)Development of test rig to be added to the course model 3.c.4.ii)Bench test of start signal detecting mechanism 3.d)Mounting of all sensors onto the chassis 3.d.1) Final Decision of mounting placement 3.d.2) Selection of mounting hardware 3.d.3) Mounting sensors to bot 3.d.3.i)Power connections to all sensors 3.d.3.ii)Logic connections to all sensors 3.d.4) Verification of functionality and design review 3.d.4.i)Individual verification of all sensor functionality 3.d.4.ii)Parsing of data from all sensors on the beagle bone platform 3.d.5) Updating of diagrams to include all components of bot

Task 3 deadline: Dec 31st

4)Able to grab one block (using the DAGU Arm solution) 4.a) Development of control system for DAGU arm 4.a.1)Development of control scheme for DAGU arm 4.a.1.i)Development of beagle bone based higher level control scheme 4.a.1.ii)Development of firmware between beagle bone and servo cape 4.a.1.iii)Development of lower level servo cape to DAGU arm control system 4.b) Redesign of the gripping apparatus 4.b.1)CAD model of current gripper 4.b.2)Bench test of gripper to confirm need for redesign
4.b.3)Brainstorming of gripper ideas 4.b.4)Prototyping and testing of design ideas 4.b.4.i) CAD model of proposed designs 4.b.5)Design reviews and final selection 4.b.6)Implementation of design onto the DAGU arm 4.c)Bench test/verification of gripper design

Task 4 deadline: December 31st